Opened 7 years ago

Closed 7 years ago

#1249 closed defect (fixed)

IRC tunnel filters numeric 251

Reported by: Eche|on Owned by:
Priority: minor Milestone: 0.9.13
Component: apps/i2ptunnel Version: 0.9.12
Keywords: easy Cc:
Parent Tickets: Sensitive: no



got from IRC:
<dbanet> It is related to the thing that processes connection to IRC network
<dbanet> not sure which part is it, but here it is: During connection, many IRC clients expect certain IRC numeric to be sent to it to trigger various behaviours. The numeric 251 ("users") is used to trigger joining of channels, among other behaviours, but it does not appear to be sent by I2P.
<dbanet> I've found that Chatzilla does not do the needed actions (that it should do and does) on server connect in the Irc2P network, while it does on others (efnet, freenode).
<dbanet> I've consulted with a Chatzilla developer on #chatzilla on moznet, and he/she found that the numeric is not sent


Change History (2)

comment:1 Changed 7 years ago by zzz

Keywords: easy added

We block by command name, not number. Verified in that we block outbound "USERS" (RFC sec. 5.5) in the client proxy. We don't block "LUSERS".

The RFC says that server support is optional but it must return a numeric code if disabled. By blocking the outbound, the client gets no response at all.

Any security issues with USERS appear to be on the server side, not the client side. I don't see any issue with unblocking it at the client.

Version 0, edited 7 years ago by zzz (next)

comment:2 Changed 7 years ago by killyourtv

Resolution: fixed
Status: newclosed

Agreed. I'm unblocking USERS and inspircd commands in rev 0e86002b5b7f68414fd8fabc8565dddcabaf8dab.

Note: See TracTickets for help on using tickets.