Opened 14 months ago

Last modified 14 months ago

#18141 new enhancement

Tame "reading from ORPort" error logs in meek-server

Reported by: dcf Owned by: dcf
Priority: Medium Milestone:
Component: Obfuscation/meek Version:
Severity: Normal Keywords:
Cc: tor-admin@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

meek-server operators have asked to disable this error message:

reading from ORPort: read tcp 127.0.0.1:YYYY->127.0.0.1:ZZZZ: read: connection reset by peer

It occurs whenever tor closes the TCP connection between meek-server and itself. This happens very frequently when you restart the meek-server process, because it loses its cache of current session-IDs. When clients connect using their formerly valid session-IDs, meek-server treats them as new connections and opens new ORPort connections. The clients push TLS application data over the new connection, which doesn't match what tor expects from a new connection, so it shuts it down. Right after restarting you get a ton of these messages for a while (can be more than 10 per second).

Child Tickets

Change History (4)

comment:1 follow-up: Changed 14 months ago by dcf

One possible approach: have client indicate in their HTTP requests whether they intend to start a new session with a new session ID. meek-server would drop requests with an unknown session ID that don't have this bit set, and would request the bit to be not set for any existing session ID. That way we would drop the client connection before it gets passed through to tor.

comment:2 Changed 14 months ago by torland

  • Cc tor-admin@… added

comment:3 in reply to: ↑ 1 ; follow-up: Changed 14 months ago by yawning

Replying to dcf:

One possible approach: have client indicate in their HTTP requests whether they intend to start a new session with a new session ID. meek-server would drop requests with an unknown session ID that don't have this bit set, and would request the bit to be not set for any existing session ID. That way we would drop the client connection before it gets passed through to tor.

Hm. Won't this break backwards compatibility?

comment:4 in reply to: ↑ 3 Changed 14 months ago by dcf

Replying to yawning:

Replying to dcf:

One possible approach: have client indicate in their HTTP requests whether they intend to start a new session with a new session ID. meek-server would drop requests with an unknown session ID that don't have this bit set, and would request the bit to be not set for any existing session ID. That way we would drop the client connection before it gets passed through to tor.

Hm. Won't this break backwards compatibility?

No; we'll fall back to the previous behavior if clients don't send whatever header has the flag in it (treat it as true/false/null). I think we're going to have to add a header with flags for #12857 anyway.

Note: See TracTickets for help on using tickets.