Channel prefixes not updating on mode change InspIRCd v3 #897

New Issue

2026-10-05T04:51:26+02:00

adam commented

2026-10-05 04:51:26 +02:00

In InspIRCd, the mode change message may appear in the form MODE #channel +ooo nick nick1 :nick2, which is valid according to RFC1459, but ZNC does not seem to update the channel prefix for nick2 properly, leading to an inconsistent state when reconnecting a client to ZNC. After running /NAMES manually, the prefixes show correctly.

In InspIRCd, the mode change message may appear in the form `MODE #channel +ooo nick nick1 :nick2`, which is valid according to RFC1459, but ZNC does not seem to update the channel prefix for `nick2` properly, leading to an inconsistent state when reconnecting a client to ZNC. After running /NAMES manually, the prefixes show correctly.

adam closed this issue

2026-10-05 04:51:27 +02:00

adam commented

2026-10-05 04:51:27 +02:00

ZNC version?

ZNC version?

adam commented

2026-10-05 04:51:28 +02:00

Occurs on both 1.7.1 and 1.7.2

Occurs on both 1.7.1 and 1.7.2

adam commented

2026-10-05 04:51:29 +02:00

can confirm that this happens, I am having the same issue.

can confirm that this happens, I am having the same issue.

adam commented

2026-10-05 04:51:30 +02:00

The issue appears to be affecting RPL_CHANNELMODEIS as well, leading to channel modes appearing as +:nt

The issue appears to be affecting RPL_CHANNELMODEIS as well, leading to channel modes appearing as `+:nt`

adam commented

2026-10-05 04:51:31 +02:00

MODE #channel +ooo nick nick1 :nick2

Heh. CMessage::Parse handles this correctly. However, it remembers that there was a colon (sets m_bColon = true). Thus, CModeMessage::GetModes() calling GetParamsColon(1) reconstructs the argument correctly to contain :nick2.

It is kind of pointless to first parse the message and then to stitch it together into a single string only to parse that again. I'd suggest an API change, making CModeMessage::GetModes() return a VCString instead of a CString that needs to be parsed again. Similarly, all other uses of GetParamsColon() should be reviewed by someone.

From a quick look, there do not seem to be many calls. We seem to have hit all important ones on the receiving side already (and I'm too lazy to look at modules and src/Client.cpp right now, sorry).

> MODE #channel +ooo nick nick1 :nick2 Heh. `CMessage::Parse` handles this correctly. However, it remembers that there was a colon (sets `m_bColon = true`). Thus, `CModeMessage::GetModes()` calling `GetParamsColon(1)` reconstructs the argument correctly to contain `:nick2`. It is kind of pointless to first parse the message and then to stitch it together into a single string only to parse that again. I'd suggest an API change, making `CModeMessage::GetModes()` return a `VCString` instead of a `CString` that needs to be parsed again. Similarly, all other uses of `GetParamsColon()` should be reviewed by someone. From a quick look, there do not seem to be many calls. We seem to have hit all important ones on the receiving side already (and I'm too lazy to look at modules and `src/Client.cpp` right now, sorry).

adam commented

2026-10-05 04:51:31 +02:00

Any progress on a fix for this?

Any progress on a fix for this?

adam commented

2026-10-05 04:51:32 +02:00

No.

No.

adam commented

2026-10-05 04:51:33 +02:00

@linuxdaemon as soon as you write a patch for this :)

@linuxdaemon as soon as you write a patch for this :)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#897