View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000870 | unreal | ircd | public | 2003-04-05 20:35 | 2003-11-20 19:46 |
| Reporter | KnuX` | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.2-beta15 | ||||
| Summary | 0000870: Client not glined if shunned | ||||
| Description | On my server, there is : - a gline on *TesT@* - a shun on *TesT@*.somedomain.fr If [email protected] connects to the ircd, he is not glined but just shunned, so he can flood by server notices about connections. This shun and this gline are both set automatically by OperServ and an eggdrop. You will ask my "Why would you like to shun an glined mask ?!", I will reply "The shun were configured in the eggdrop before the gline !" It's not a serious bug, I wanted only give you this notice ;) | ||||
| Additional Information | Unreal3.2-beta15. irc.mynet.net CFhiInXOo [Linux dstiny.net 2.4.18 #1 Wed Jul 17 18:28:39 CEST 2002 i686 unknown=2303] | ||||
| 3rd party modules | |||||
|
|
I wouldn't ask it, a gline is something that should have a higher precedence than shun. << gline +*angrywolf@localhost* >> :server3.test.com NOTICE AngryWolf :*** Permanent G:Line added for *angrywolf@localhost* on Sun Apr 6 13:42:45 2003 GMT (from [email protected]: no reason) << shun +*angrywolf@localhost* >> :server3.test.com NOTICE AngryWolf :*** Permanent Shun added for *angrywolf@localhost* on Sun Apr 6 13:42:52 2003 GMT (from [email protected]: no reason) << PING LAG1986093120 Ok, Wolf!~angrywolf@localhost tries to connect to server1.test.com --> success, but shunned. >> :server3.test.com NOTICE AngryWolf :[email protected] removed Shun *angrywolf@localhost* (set at Sun Apr 6 13:42:52 2003 - reason: no reason) Ok, trying to connect again: ERROR :Closing Link: Wolf[localhost] (User has been permanently banned from TEST (no reason)) But if I add the shun before the gline, I will be banned immediately. It looks like the first tkline match is used on clients. Is there a way to give them a precedence or anything? |
|
|
Fixed in .1709 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-11-20 19:46 | syzop | Status | resolved => closed |
