usually dircproxy (both bersions in portage) ignore irc numeric 005, which contains capabilities and network name. this privents clients from knowing the network name which will break some scripts. with the patch, 005 is forwarded and requested when re-attaching Reproducible: Always Steps to Reproduce:
Created attachment 47717 [details, diff] remove 005 ignore from dircproxy 1.1.0 can be applied though epatch
Thanks, in CVS!
This patch seems to have introduced a bug on some networks, atleast on FreeNode. Don't have time to track it down now, but all PRIVMSG on FreeNode gets a + or - appended to the start. Doesn't seem to affect other networks like IRCNet or NetGamers. Atleast that's what I'm seeing after upgrading to 1.1.0-r1.
Hm, I'm not experiencing the +/- PRIVMSG problem. Morten, if you have more information please post.
Since my patch only removes an ignore and adds a command sent to the user on reattach, I doubt it can cause such a behaviour.
I've been told the +/- at the start of the lines could be the indicators of registered vs. non-registered users on the net, interpreted by my client as being part of the line, and not having any special meaning. If I use the same client and connect directly to the network without using dircproxy, I don't see the +/-, so it's definatly dircproxy related, and I didn't see this behaviour before upgrading from 1.1.0 to 1.1.0-r1. This is all happening on irc.freenode.org, so it could be something about that network that doesn't agree with the handling of the 005?
005 is standardized and only sent on connect and after a VERSION from the user
Screenshot of dircproxy and direct connection side-by-side: http://ibidem.homeip.net/dircproxy.png As you can see, my own lines (I'm Epcylon) are not affected. On the direct connection, all is fine, on the connection through dircproxy there's the problem. And again, this was not there when using 1.1.0. I'm looking at the response from the server when doing VERSION, and it doesn't seem to give a 005 response to that atleast. Could that be the cause of this somehow? Btw, has this patch been submitted upstream (to the dircproxy team)?
OK, I'm now able to reproduce this, currently trying to find the reason.
-- Btw, has this patch been submitted upstream (to the dircproxy team)? -- in their subversion version, they have more complex code which detects also redirects in 005.
believe it or not, the +/- thingy gets send to us from the freenode server :\ 22:27:21.635592 IP niven.freenode.osuosl.org.ircd > luna.wegener.lan.stealer.net.8283: P 133519:133781(262) ack 208 win 5840 0x0000: 4500 012e f9e0 4000 3506 6bfc 8cd3 a604 E.....@.5.k..... 0x0010: ac10 0005 1a0b 205b 2950 130b 82d6 1595 .......[)P...... 0x0020: 5018 16d0 a6a7 0000 3a4c 6574 6861 6c5f P.......:Lethal_ 0x0030: 5065 7465 217e 726f 6f74 4069 7035 3033 Pete!~root@ip503 0x0040: 6362 3963 632e 7370 6565 642e 706c 616e cb9cc.speed.plan 0x0050: 6574 2e6e 6c20 5052 4956 4d53 4720 2367 et.nl.PRIVMSG.#g 0x0060: 656e 746f 6f20 3a2d 6d6f 6f6d 696e 2d70 entoo.:-moomin-p 0x0070: 6170 613a 2062 7262 2c20 666f 7267 6f74 apa:.brb,.forgot 0x0080: 2074 6f20 7365 7420 7061 7373 7764 2c20 .to.set.passwd,. 0x0090: 626c 6568 0d0a 3a6f 7a62 6f72 6e5f 217e bleh..:ozborn_!~ 0x00a0: 6f7a 626f 726e 4031 322d 3231 382d 3131 ozborn@12-218-11 0x00b0: 312d 3134 352e 636c 6965 6e74 2e6d 6368 1-145.client.mch 0x00c0: 7369 2e63 6f6d 2050 5249 564d 5347 2023 si.com.PRIVMSG.# 0x00d0: 6765 6e74 6f6f 203a 2d61 6e64 2067 6f74 gentoo.:-and.got 0x00e0: 3a20 6368 6f77 6e3a 2063 6861 6e67 696e :.chown:.changin 0x00f0: 6720 6f77 6e65 7273 6869 7020 6f66 2060 g.ownership.of.` 0x0100: 2f6d 6e74 2f6e 7466 732f 6566 6178 2e74 /mnt/ntfs/efax.t 0x0110: 7874 273a 204f 7065 7261 7469 6f6e 206e xt':.Operation.n 0x0120: 6f74 2073 7570 706f 7274 6564 0d0a ot.supported..
OK, tracked it down. The 005 numeric on freenode includes CAPAB support. The client receives it and send a CAPAB IDENTIFY-MSG in response which causes the behvaiour that PRIVMSGs gets prefixed with + for identified and - for non-identified users. If we patch dircproxy to not ignore the 005 numeric and we connect through dircproxy for the first time, dircproxy connects to the server and the client receives the 005 numeric with the CAPAB support. It sends CAPAB IDENTIFY-MSG and everything is fine, the client knows that it is using IDENTIFY-MSG. When we disconnect now and reconnect, the clients receives no 005 numeric and it thinks that no IDENTIY-MSG support is active, but apparently it is still active and it prints that +/- as part of the PRIVMSG.
This is a bug in the ircd then - a VERSION should make the ircd re-send their capabs.
No, RFC1459 only states that a VERSION command should give the following response: > 351 RPL_VERSION > "<version>.<debuglevel> <server> :<comments>" > > - Reply by the server showing its version details. > The <version> is the version of the software being > used (including any patchlevel revisions) and the > <debuglevel> is used to indicate if the server is > running in "debug mode". > > The "comments" field may contain any comments about > the version or further version details. dancer-ircd only sends the 005 on client connect. There's no command available to specifically re-request the info from numeric 005.
Adrian, you want to further improve your patch? If not, I'm going to remove it from our ircproxy ebuild, because IMO it breaks more than we gain from it.
Well, I currently don't have much time to improve the patch. But in the current dev. version of dircproxy it also forwards 005 to the client. Since most major networks (tested: GameSurge, QuakeNet, Undernet, EFNet, DALNet) sends 005 on VERSION, I would call this problem a bug in dancer-ircd.
Yes, I know, I've tested it with QuakeNet too, but RFC doesn't require the ircd to advertise their CAPABs upon VERSION request. And having something in our tree that doesn't work well on freenode (the IRC network Gentoo uses for developer and user communication) is somewhat counterproductive. For the time being I'm going to remove the patch from the ebuild later today. Feel free to reopen this bug with a new patch attached.
