#i2p-dev (irc2p) | 2.10.0-3 | See important notes on zzz.i2p before updating

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 -i -x localhost:8888 privacy2zbidut4m4jyj3ksdqidzkw3uoip2vhvhbvwxbqux5xy5obyd.onion

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?