Opened 5 years ago

Closed 5 years ago

#1141 closed defect (fixed)

Ping cookies filtered by I2PTunnel

Reported by: dg Owned by:
Priority: major Milestone: 0.9.10
Component: apps/i2ptunnel Version: 0.9.8.1
Keywords: Cc:
Parent Tickets:

Description

In Unreal3.2.10.1 build 3.2.10.1 (and InspIRCD, from my experience with rootd.it's network), by default, IRC type I2PTunnels are unable to connect.

This is because of a feature "ping cookies". Ping cookies are nonces sent by the server to the client.

INFO [Client 20 in] p.i2ptunnel.I2PTunnelIRCClient: inbound: ERROR :Closing Link: ircc[10.0.0.1] (Ping timeout: 39 seconds)
DEBUG [Client 20 in] p.i2ptunnel.I2PTunnelIRCClient: in: [ERROR :Closing Link: ircc[10.0.0.1] (Ping timeout: 39 seconds)]
WARN [lient 20 out] p.i2ptunnel.I2PTunnelIRCClient: - outbound was: PONG :127.0.0.1
WARN [lient 20 out] p.i2ptunnel.I2PTunnelIRCClient: outbound FILTERED: PONG 127.0.0.1
DEBUG [lient 20 out] p.i2ptunnel.I2PTunnelIRCClient: out: [PONG :127.0.0.1]
WARN [Client 20 in] p.i2ptunnel.I2PTunnelIRCClient: - inbound was: PING :94287D6E
WARN [Client 20 in] p.i2ptunnel.I2PTunnelIRCClient: inbound FILTERED: PING 127.0.0.1

This occurs in irssi (irssi 0.8.15), sometimes Xchat and znc. I2PTunnel is mangling the cookie and not sending it to the server. This breaks connectivity to most modern IRCds. Disabling ping cookies can pose a security risk (bot flooding).

Subtickets

Change History (6)

comment:1 Changed 5 years ago by zzz

ping/pong are filtered to strip IP addresses for privacy. We do support passing thru the cookies; your speculation that we don't do it at all is wrong. However different clients and servers use different formats. It's somewhat of a heuristic to get it right.

It appears that your issue is due to the server PING, on a server that's different from that used in the common IRC servers in I2P. It's getting filtered at the client tunnel.

comment:2 Changed 5 years ago by zzz

Looked at this further. For client-originated pings, we have the filtering and heuristics described above.

However for server-originated pings (and client-originated pongs) it is quite different. We convert all server pings to PING 127.0.0.1 and all client pongs to PONG 127.0.0.1. Period end of story. The comment in the code is "no way to know what the ircd to i2ptunnel server con is, so localhost works".

It's not clear why there is filtering for server ping / client pong on the client side. Note that there is no filtering in the IRC server tunnel, any security issues are the responsibility of the server op. Are there any security / anonymity issues? It's straightforward just to remove the filtering on the client side if needed. How do clients interpret the PING?

comment:3 Changed 5 years ago by zzz

  • Status changed from new to testing

Fixed in i2p.i2p.zzz.test2 cd7e44a439509fd56144abc262f61e1572ad3aa0 to be propped for 0.9.10

comment:4 Changed 5 years ago by zzz

Above fix removes filtering completely for server PING and client PONG. Will need to test several clients to see if they append the apparent server IP to the PONG. If so, will need to implement filtering for the PONG.

comment:5 Changed 5 years ago by zzz

Propped as 0.9.9-1

<dg> only client which should be fixed in 0.9.9-1 (zzz2 is propped now)
<dg> i haven't tested the fix yet
<dg> i'll do it now
...
<dg> fix seems to work
<dg> thanks zzz

comment:6 Changed 5 years ago by dg

  • Resolution set to fixed
  • Status changed from testing to closed

Confirmed, this is fixed. Just tested ahead of the IRC2P migration.

Note: See TracTickets for help on using tickets.