unknown channel modes in DCC incremental status

[ZvOO]

My question is about the channel modes appearing in the following auto-status line for the bot's console channel:

Code: Select all

[19:00:00] <FlezFlip> [21:00] @#channel (+ismctrDunl 18) : [m/13 o/8 h/0 v/5 n/0 b/4 e/0 I/-]

I know what channel modes i s m t r n and l are. But only modes t and n have been set for this channel on the bot with the .chanset <#channel> chanmode <modes> command and they are the only two modes listed when the .status command is used in a DCC session. Here's a paste of that output line:

Code: Select all

#channel             :  13 members, enforcing "+tn" (greet)

Additionally, the IRC network shows that there are no other modes besides Bmnrtl set for this particular channel, which are exactly the modes intended and set for it by the channel's founder:

Code: Select all

#channel +mntrlB 18 #idle[security]

Mode B is for the IRCd's "banlink" module that's installed on the network and enabled for the channel and #idle[security] is the redirect channel.

So why are modes i s c D and u showing up in the bot's auto-status lines every 5 minutes? It seems to me that the bot shouldn't be seeing these strange modes since they were never set.

Since mode B doesn't show at all in the DCC session outputs, could it be that the eggdrop is just interpreting mode B in a strange way and thus showing the extra modes?

Thoughts and guesses about this are welcome.

Thanks

[ZvOO]

Is this just a hard question? Or did I post in the wrong category? Anyone?

[nml375]

ZvOO:
The statuslog modes are retrieved from getchanmodes() within the irc-module. This function takes eggdrop's view of the channelmode (as a bit-register), and converts it to a string of the known flags. B is not a known flag, and is thus not supported.

The opposite is done whenever channel mode(s) get published to your eggdrop (through the 324 numeric response), where it scans the modechange for known flags, and sets (or clears) the corresponding bit in the registry. This is handled by got324() in src/irc.mod/chan.c:905. Since both limits (+l) and keys (+k) are included in the mode-string recieved from the server, these are handled specially in order to separate these from the modes. Should the +B be reported in a similar fashion, this would most certainly cause the behavior you describe.

[ZvOO]

nml375, thanks for the reply and explanation.

So in essence, my guess was right that the cause is an incorrect interpretation of the server's mode B. I've noticed mode a show up in the statuslog output of other eggs and wondered why it's there when seemingly not set. However, this is the first time I've seen such a group of nonexistent modes at once. In fact, the mode a I just mentioned has just popped into the status log output of my bot since yesterday (along with the rest of the modes). To wit:

Code: Select all

[16:00] @#channel (+ismctrDunal 18) : [m/13 o/8 h/0 v/5 n/0 b/4 e/0 I/-]

Now that's a string of channel modes!

Last question: Am I correct in surmising that these erroneous statuslog modes will not affect bot functionality?

Thanks

[nml375]

Well, they will affect in such, that your eggdrop will believe they're set even if they aren't.
If you change your enforced channel modes in the future to prevent one of these modes (.chanset #channel -ism+nt), your eggdrop will repeatedly try to remove these modes whenever it sees them as active.

Further, any script that uses the getchanmode command will also see these modes as active, and depending on how these are coded, will act upon them.

Even further, it will be unable to enforce any of these modes, as it will be unaware of any of them not being set. It will not remove them, but it will not be able to see if they're missing.

[ZvOO]

Well, that's not quite the answer I'd hoped for.

To complicate the matter further, one of the scripts loaded in the bot is AllProtection4.5. I haven't yet checked, but it's probably using getchanmode. I suppose that could be creating functionality flaws I've not yet noticed.

Thanks for the info. It's much appreciated.