InspIRCd-3 and synchro pb

[rxtxfr]

Hello,

europnet recently upgraded to InspIRCd-3 and sometime when someone joins the room I have the +v notification but not join msg and the userlist doesn't updates. and sometime when trying to join a room I got this msg : [Server parser]: encountered problems while parsing the following message: [Analyseur du serveur] : [[email protected]][MODE] #ROOM +o :NICK [Analyseur du serveur] : Réception d'un changement de mode pour un salon inconnu, probable désynchronisation

I'm running kvirc 5.0.0 from debian repo buster wuth andariscript behind nft. the help room told me there was modifications in irc protocol

thanks

[IceN9ne]

What IRC protocol are they using that uses a : in a channel mode message?

[Dessa]

this has a bit more context: https://github.com/hexchat/hexchat/issues/2271

[IceN9ne]

That's unfortunate they've decided to go this route. I suppose this means they're going to want us to support mode parameters with spaces in them as well, like a space in a channel key for +k.

I tried their test server, but this doesn't work...

MODE #channel +k :key with spaces

Looks like someone wrote a fun new response builder that assumes all final parameters are now trailing.

[DarthGandalf]

Mode parameters with spaces won't work, because you can pass several modes in one line: +kb key :newban!@ (I think that would be the syntax, but need to check RFCs). But we should be handling colon on the trailing param anyway

вс, 27 дек. 2020 г., 02:22 IceN9ne [email protected]:

That's unfortunate they've decided to go this route. I suppose this means they're going to want us to support mode parameters with spaces in them as well, like a space in a channel key for +k.

I tried their test server, but this doesn't work...

MODE #channel +k :key with spaces

Looks like someone wrote a fun new command builder that assumes all final parameters are now trailing.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kvirc/KVIrc/issues/2491#issuecomment-751417378, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACPLZGRAR2A7QUL7ZLI4RDSW2K7BANCNFSM4UZWYP4A .

[IceN9ne]

I realize that you'd only get to use 1 param with spaces per command, but per the RFC, that's really the only reason to use trailing in a command:

After extracting the parameter list, all parameters are equal whether matched by <middle> or <trailing>. <trailing> is just a syntactic trick to allow SPACE within the parameter.

[coldacid]

More details for InspIRCd-3 changes with regard to userlist issues: https://docs.inspircd.org/faq/#why-does-my-client-not-show-mode-changesopped-users-on-joinetc-correctly-when-using-inspircd-v3

According to the InspIRCd developers, what they're doing is technically to spec in RFC 1459.

[IceN9ne]

While technically valid, my interpretation of the standard says to only use trailing when your output could contain a space, but the MODE command cannot contain spaces in a parameter, so the usage of a trailing is surprising, as can be seen by the large number of clients that broke.

I have changed my opinion and agree that parsing it into a generic list of parameters and forgetting trailing is even a thing makes things more convenient, but this change is non-trivial for KVIrc. I'm curious if we could leverage <string_view> to keep efficiency.

[coldacid]

Yeah it's definitely an abuse of the RFC by my reading as well. Gotta love these letter-but-not-the-spirit type things. ¯\_(ツ)_/¯

[DarthGandalf]

That's not an abuse. That's a valid message. Yes, they could remove : if there are no spaces, but that would probably break other broken clients which do expect : for certain messages even when the last param has no space.

[DarthGandalf]

parsing it into a generic list of parameters and forgetting trailing is even a thing makes things more convenient, but this change is non-trivial for KVIrc

Yep.

I'm curious if we could leverage <string_view> to keep efficiency.

That's definitely an option

[ctrlaltca]

Looking at the way KviIrcMessage parser works, it looks to me like any message received can safely contain a ":" before the trailing parameter, that will get correctly discarded. I've tried to connect to both europnet and testnet.inspircd.org, and I've not been able to detect any badly parsed message.

[DarthGandalf]

@ctrlaltca I would agree, but KviIrcMessage code which does that predates opening this bug by several years...

But I've just tried to /inject such MODE line, and it've set +o mode correctly

[DarthGandalf]

Is it possible that in somewhere KviIrcMessage is skipped, and something tries to parse the raw line again independently from KviIrcMessage?

[ctrlaltca]

The server parser always use KviIrcMessage to parse an incoming line. The only things that can happen before that is the use of server-specific link filters (modules that nobody ever used, they were created as a way to translates incoming messages from a different protocol to IRC)

Reading again the original issue it seems the problem is about receiving MODE messages for an unknown user or channel. This could be caused by not receiving/parsing JOIN messages correctly.

Option 1: a bug in our extended-join capability handling; many other networks use this cap and they work fine; also, i see that staticfox's implementation predates this bug, too.

Option 2: network desync (would explain the "sometimes" in OP's report)

Option 3: a script halting the onJoin event handler; in theory it should only halt the message output Btw what is a andariscript behind nft?

[ctrlaltca]

We are about to release a new version, please try https://github.com/kvirc/KVIrc/releases/tag/5.2.0-beta1-fix and report if this issue is still present. Thank you