zzz
dr|z3d, re: outproxy not found
zzz
dr|z3d, re: outproxy not found
zzz
my guess is the outproxy is not responding before things timeout locally
dr|z3d
not responding in what sense, zzz?
zzz
did it send a 5xx? or what?
zzz
or nothing?
dr|z3d
let me remind myself, one moment...
dr|z3d
we're seeing a 504.
dr|z3d
aka gateway timeout.
zzz
if we get a 504 we should just pass that through to the browser, not throw up our own error message
dr|z3d
sure, works for me.
zzz
or are you talking the standard 504 "outproxy not found"
zzz
?
zzz
I want to know what the outproxy sent, not what the browser got
dr|z3d
it appears that the outproxy is sending a 504.
zzz
huh?
zzz
if outproxy sends a 504 and we get it before the timeout, we should display what the outproxy sends
dr|z3d
"outproxy not found" with a 504 response from upstream or the outproxy. hard to know exactly where the 504's coming from.
dr|z3d
the response is instant, there is no timeout as such.
zzz
hmm
dr|z3d
test case on the bug report still works fine.
zzz
our 504 is from dnfp-header.ht, starting with HTTP/1.1 504 Gateway Timeout and contains "Outproxy Not Found"
zzz
whatever purokishi sends is presumably different
zzz
if it's instant, perhaps something on the outproxy side isn't flushing or closing the socket properly, preventing the error message from getting through
dr|z3d
the response headers indicate the error's being sent by our proxy
zzz
client-side proxy, right?
dr|z3d
right
dr|z3d
firefox's network tab isn't being very helpful, notwithstanding.
dr|z3d
this is start of the raw response:
dr|z3d
HTTP/1.1 504 Gateway Timeout
dr|z3d
Content-Type: text/html; charset=UTF-8
dr|z3d
Connection: close
dr|z3d
Proxy-Connection: close
dr|z3d
so it looks like that's an i2p proxy response.
zzz
apps/i2ptunnel/resources/proxy/dnfp-header.ht
dr|z3d
yup, identical.
zzz
which had to come from a socket error. If we got an error page we would have passed it through
zzz
so my guess is that the problem is with your outproxy not flushing/closing the socket or sending an error message at all
dr|z3d
yeah, it's curious, because feed the outproxy a non-existent non .onion address, it responds as you'd expect, with an outproxy-sent error page.
zzz
you could set INFO or DEBUG logging on your client side i2ptunnel to see the exception
zzz
or you could test with a different outproxy, if any are up
dr|z3d
> [HTTPClient] Request via outproxy [purokishi.i2p] ➜ Success? [✘]
zzz
summary: we'll pass through an error page if we get it from the outproxy; if the socket just gets closed or reset out from under us, all we can do is spit out that dnfp-header.ht page
dr|z3d
what about a separate error page for .onion *04 errors, on the assumption the socket gets closed?
dr|z3d
"either the outproxy is not available, or the requested .onion site is not responding" or somesuch. or not worth the hassle?
zzz
I don't think so. Somewhere in your outproxy's http-socks-tor plumbing, you need to turn a socks error into a nice http error response page
zzz
either you're not doing that or it's broken
dr|z3d
possible it's broken/buggy.
zzz
that's my guess from here. have not tried to reproduce
dr|z3d
ok, not to worry, I'll chase up the dev, see if he has any ideas.
dr|z3d
the other possible is that tor itself isn't sending anything useful on 404s.
dr|z3d
ok, direct via Tor gives a standard browser 404 error, which is what you'd expect.
zzz
it's a socks proxy, so it's likely sending a socks error, unless they have some built-in http error stuff
dr|z3d
doesn't appear to be sending anything, so I guess the resolve times out and the client browser takes over.
zzz
but if immediate, the socket got closed or reset without any response
dr|z3d
it's immediate via outproxy, takes a couple of seconds direct over Tor.
zzz
I'd get on the purkishi box, take i2p out of the picture, and just see what you get on the http side of the http/socks conversion
dr|z3d
already been all over that. nothing helpful there.
dr|z3d
I'll talk to the proxy dev, he may have some ideas.
zzz
well, you either see the http error page you expect, or you don't. Then proceed from there
dr|z3d
curl -x socks5h://localhost:9050 privacy2zbidut4m4jyj3ksdqidzkw3uoip2vhvhbvwxbqux5xy5obyd.onion
dr|z3d
curl: (97) Can't complete SOCKS5 connection to privacy2zbidut4m4jyj3ksdqidzkw3uoip2vhvhbvwxbqux5xy5obyd.onion. (4)
dr|z3d
not sure what can't complete translates into, error-wise.
dr|z3d
let's see if I can turn on extended headers.
zzz
that's not testing your outproxy's http-to-socks conversion
zzz
or is it...
dr|z3d
no, that's testing Tor directly, to get a baseline. no response headers I'm seeing via curl -> tor.
zzz
got it
zzz
and (4) is host unreachable socks error
dr|z3d
curl: (52) Empty reply from server
zzz
bingo
dr|z3d
so the proxy should be responding with an error code, but isn't, I guess.
zzz
yes, s/error code/well formed http error response/
dr|z3d
but apparently it _is_ responding, albeit with an empty reply, whatever that is.
zzz
yup. and we're not as smart as curl, so we don't have a separate error page for "empty reply"
dr|z3d
ok, anyways, thanks for the help isolating the issue, I'll get onto the relevant dev.
zzz
while you're at it, you probably want to test and fix the https flavor
dr|z3d
is there any point having an empty reply page, notwithstanding? to differentiate between "outproxy not found" and "upstream responded with an empy document" or whatever?
dr|z3d
I do? what's the issue with https?
zzz
outproxies aren't easy, and testing errors is a big part of the work
zzz
https errors are different
zzz
because the request is just CONNECT
dr|z3d
ok, but where's the issue manifesting?
zzz
https should be part of your test suite/checklist
dr|z3d
I'm trying to understand what the issue is :)
zzz
I'm just proposing that when you do get http resolved, next test https, haven't tested anything
dr|z3d
the issue is mostly with .onion addresses. everything else appears to be working as intended.
zzz
re: empty reply page, probably not worth coding/testing/translating, we have 21 error pages already.
zzz
sure, but have you tested https onions and verified they work as expected? was that part of your test process?
dr|z3d
https onions work fine over the outproxy, if that's what you're asking. fixed a while back.
zzz
and errors https onions that are not up?
dr|z3d
apparently we get a better deal with those, no local i2p proxy error, just a straighforward browser connection timeout error.
dr|z3d
(which is what you'd expect)
zzz
I guess that's better, sure
zzz
perhaps we could/should treat empty reply the same as a socket reset and use resetp-header.ht instead
dr|z3d
yeah, possible, though the error text is equally misleading for the context we're discussing: "The proxy could be temporarily unavailable, too busy, or it has blocked your access."
zzz
is purokishi http or standard tunnel?
dr|z3d
http
dr|z3d
I'd have preferred a standard tunnel, but there's no header filtering on the server-side of things which leaves things more exposed than I'd like.
zzz
yup
dr|z3d
standard tunnel == less logging of requests.
zzz
I was just looking at our server-side response handling
zzz
we aren't very fancy on that side of things
zzz
we don't convert malformed or empty responses into a server-side error page
dr|z3d
you think there might be value in handling those better?
zzz
perhaps
zzz
eyedeekay1, git.idk.i2p is semi-hosed, on the issue summary page, all the links to individual issues are to the b32
zzz
which wants its own login
zzz
but rejects my pw
zzz
manually changing the url back to git.idk.i2p works
dr|z3d
sounds like he's forgotten to set the hostname in the tunnel manager.
dr|z3d
aka spoofed address.
zzz
not really helpful for you to guess. he's got some complex setup with reverse proxies and rewriting and stuff
eyedeekay
Looks fixed from my side, problem was that I had the reverse proxy configured to answer for both git.idk.i2p and the base32, but I was only rewriting the hostname to the base32, underlying problem is that gitlab doesn't honor one of it's settings to I have to do a complicated workaround or only host on one network at a time
dr|z3d
sub_filter and proxy_redirect may help, eyedeekay
dr|z3d
that is, assuming you're using nginx underneath.
eyedeekay
Yeah I'm using sub_filter to do the rewrites
dr|z3d
unfortunately sub_filter doesn't support regex, but subs_filter does.
dr|z3d
you can upgrade nginx fairly painlessly to a version with more module support via the sury (php main dev) repo.
dr|z3d
as for proxy_redirect, you'd want something like: proxy_redirect b32goeshere.b32 git.idk.i2p;
eyedeekay
If it seems to be necessary I will but for now what I'm going with is a server block that answers for the b32 and a server block that answers for the hostname and rewrites/redirects in favor of the server name it answers to
dr|z3d
whatever works for you.. complex beast, nginx, many ways to achieve the same goal :)
zzz
thx eyedeekay
eyedeekay
np zzz
eche|on
eyedeekay: did you already update the news entry?
eyedeekay
Yeah I updated the entry itself and my feed a couple days ago
SilicaRice
is it okay to flood i2p with mobile peers?
eche|on
not really
eche|on
i2p depends on active tunnels through reachable nodes
eche|on
most mobile networks are NAT
eche|on
also tend to be short lifetime
eche|on
i2p tunnel lifetime is 10/11 min fixed.
eche|on
if connectin breaks during that time, tunnel keeps being alive on server/client, but cannot transfer data, aka connection gone until new tunnel is built after lifetime of broke tunnel is ended
SilicaRice
ah, so it doesn't have mechanisms to benefit from mobile peers
SilicaRice
if it becomes an issue you'll come up with a way to deal with it?