Opened 17 months ago
Last modified 11 months ago
#2122 open defect
eepsite fails to load after 200 OK in jetty logs
| Reported by: | zab | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | undecided |
| Component: | router/general | Version: | 0.9.32 |
| Keywords: | Cc: | ||
| Parent Tickets: |
Description
This does not happen every time, but it does happen frequently enough to point to something being wrong. To reproduce (sometimes) :
==========
On router A, set up a simple eepsite in jetty with default tunnel length. Start server tunnel. Wait a minute for leaseset to be stored in netdb.
On router B, issue a request for the eepsite .b32 via shared clients, again default tunnel length.
Back on router A, a few seconds later (after the !NetDB lookup) observe in the jetty logs that the site was hit with a GET and jetty responded with 200 OK.
Back on router B, after about a minute (as per configuration) the error page is displayed.
=======
This could be a flaw on any layer (I2NP, Streaming, ?) but at least the NetDb lookup and the request are working. I will be updating this ticket as I experiment more.
Subtickets (add)
Change History (3)
comment:1 Changed 17 months ago by zzz
- Component changed from unspecified to router/general
- Status changed from new to open
comment:2 Changed 11 months ago by zab
Another symptom of the same issue is that when hitting "retry" the eepsite loads almost immediately.
To me that hints that OBEP-IBGW tunnel was fully built by the time the "retry" button was hit, yet for whatever reason the original payload was lost
comment:3 Changed 11 months ago by obscuratus
I've been attempting to replicate this behavior on my testing network (running 0.9.35 and I2PD 2.19.0), but have been unsuccessful.
Let me know if you have any suggestions for coaxing this issue to surface.
So the response didn't make it back, but Jetty doesn't know that, because there's a proxy in the middle, and it's presumably a small response. If it were a huge response, it would stall, and Jetty would know it failed.
Since we have unidirectional tunnels, this is, as you say, way too common. A connects to B but B can't respond to A, probably due to the OBEP-IBGW connection failing in the reverse direction.
The problem, therefore, is not that Jetty is logging it, but that the response doesn't get there.
At a possible cost in anonymity or security, we could consider a 'paired tunnel' strategy as psi was investigating, or other routing and tunnel building strategies either on the client or server side, to increase the chances of a response making it back.