View Issue Details

IDProjectCategoryView StatusLast Update
0005070unrealircdpublic2019-02-06 12:26
ReporterGottem Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version4.0.17 
Fixed in Version4.2.2-rc1 
Summary0005070: Multiple channels/targets in KICK doesn't work properly
DescriptionIt seems that multikick is restricted to servers/U:Lines to begin with, so chanops/etc can't use it regardless of what I'm describing below.

At first I thought maybe my client was screwing up the /kick command, so I tried "/raw KICK #chan1,#chan2 nick1,nick2 :test" too but it still only kicks nick1 from #chan1. When I use a leaf simulator thing to send "KICK #chan1,#chan2 nick1,nick2 :test", Unreal only kicks both nicks from #chan1.

I'm fairly certain it stops after the first channel (at least for servers/etc) because of this:
    for (; (name = strtoken(&p, parv[1], ",")); parv[1] = NULL)
        chptr = get_channel(sptr, name, !CREATE);
        {snip}
        for (; (user = strtoken(&p2, parv[2], ",")); parv[2] = NULL)

While processing users for #chan1 parv[2] is set to NULL so everything falls upon the p2 buffer. But, as soon as all users are parsed once p2 is now empty. Then when the outer loop gets to #chan2, there are no users left to parse and nothing happens. =]
TagsNo tags attached.
3rd party modulesN/A, tested without any

Activities

syzop

2018-03-25 14:15

administrator   ~0020072

Last edited: 2018-03-25 14:18

This seems to come up every now and then - see 0003258 0002394 0003474 0001082
Basically it is or was a decision to keep it at 1.

syzop

2018-03-25 14:19

administrator   ~0020073

I should add that nowadays there's a proper way to communicate the limit/availability of this to clients, through TARGMAX= in 005.

Gottem

2018-03-29 17:21

developer   ~0020077

I did come across those but since they were about the 3.x branch, I figured it may have changed with 4.x so I reinvestigated it. :>

But if I understand you correctly, the limit of _channels_ in a /kick command is always 1, but for _nicks_ it's TARGMAX (think it's actually called MAXTARGETS tho :D)? This in reference to my opening sentence in the OP, since chanops are limited to 1 regardless while servers/U:Lines can kick multiple people at once. You did mention that in 0001082 but perhaps it could be changed to allow chanops to do it too (or a configurable for minimum access required).

I don't see a multi-channel/multi-nick kick being used much, but multi-nick/single-channel might be useful so the above paragraph would be a nice compromise. =]

PeGaSuS

2018-06-21 09:39

reporter   ~0020176

+1 for the single channel but multi user. that would help to ban a few spam bots that usually shares the same host after setting the +b in the host.

syzop

2018-07-14 16:43

administrator   ~0020201

Fine be me to implement something to allow kicking multiple users in one channel (and as said, communicate through TARGMAX)
Not a "must be in 4.0.19", though.

syzop

2019-02-06 12:26

administrator   ~0020482

You can now kick 4 people in 1 command.

commit 1e1f750b443c802b4ef10a774c6fa3d61bfdbc1e
Author: Bram Matthys <[email protected]>
Date: Mon Feb 4 17:51:09 2019 +0100

    New set::max-targets-per-command which configures the maximum number
    of targets accepted for a command, eg /MSG nick1,nick2,nick3,nick4 hi.
    Also changed the following defaults (previously hardcoded):
    * PRIVMSG from 20 to 4 targets, to counter /amsg spam
    * NOTICE from 20 to 1 target, to counter /anotice spam
    * KICK from 1 to 4 targets, to make it easier for channel operators
      to quickly kick a large amount of spambots
    See https://www.unrealircd.org/docs/Set_block#set::max-targets-per-command
    

Issue History

Date Modified Username Field Change
2018-02-11 20:29 Gottem New Issue
2018-03-25 14:15 syzop Note Added: 0020072
2018-03-25 14:18 syzop Note Edited: 0020072
2018-03-25 14:19 syzop Note Added: 0020073
2018-03-29 17:21 Gottem Note Added: 0020077
2018-06-21 09:39 PeGaSuS Note Added: 0020176
2018-07-14 16:43 syzop Assigned To => syzop
2018-07-14 16:43 syzop Status new => acknowledged
2018-07-14 16:43 syzop Note Added: 0020201
2019-02-06 12:26 syzop Status acknowledged => resolved
2019-02-06 12:26 syzop Resolution open => fixed
2019-02-06 12:26 syzop Fixed in Version => 4.2.2-rc1
2019-02-06 12:26 syzop Note Added: 0020482