View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002521 | unreal | ircd | public | 2005-05-10 05:44 | 2009-01-24 15:20 |
| Reporter | durrie | Assigned To | syzop | ||
| Priority | normal | Severity | major | Reproducibility | random |
| Status | resolved | Resolution | unable to duplicate | ||
| Platform | bsd | OS | freebsd | OS Version | 4.10 |
| Product Version | 3.2.3 | ||||
| Fixed in Version | 3.2.8 | ||||
| Summary | 0002521: User throttled for no reason | ||||
| Description | For no reason out of nowhere some users become throttled and are unable to connect no matter how long they wait between connections, only way to solve the problem at the moment is to restart the server. | ||||
| Steps To Reproduce | none, completely random. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
| related to | 0003252 | closed | New version of openssl breaks connection throttle... |
|
|
have you made heavy use of svskill? do you have your timestamps all sync'ed? Ive noticed if I've used svskill alot, i get odd errors, and if timestamps arnt sync'ed all sorts of crap goes wrong, like throttling, netsplits, glines expiring early, so best bet is to make sure to keep em as close as possible, and not use svskill |
|
|
nope, svskill is never used, and everything is sync'ed far as I know |
|
|
hmmm, well just for giggles could you drop an alltime output? /tsctl alltime |
|
|
- [03:09] -irc.carbonblue.net- *** Server=irc.carbonblue.net TStime=1115719776 time()=1115719779 TSoffset=0 - |
|
|
just one server? hmmm well yeah then its not gonna be timestamps :P does he have more than one connection trying at a time (clones, relitives, roomates, forgotten clients)? (running outta ideas fast) |
|
|
Nope none, and this happens to several people, last week I had about 10 people unable to connect all being throttled. I had one guy wait almost 2 days, and he was still throttled, and no it's doing it to my eggdrops out of nowhere, I restarted the server and the problem is fixed..but i dont want to have to restart the server everytime ya know what I mean. |
|
|
then sorry i couldnt help, im outta ideas. maybe someone else has an idea :/ |
|
|
I hope because next time this happens someone or something is getting hurt, thanks for trying though |
|
|
Could you paste the output of /stats S regarding throttling? (the 2 throttle::<etc> items) Did you compile with IPv6 support? ('grep INET6 config.settings' in unreal dir) No 3rd party modules? No modified code? If all results are negative then I'll probably give you a module to trace this issue :p. |
|
|
throttle::period: 2 minutes throttle::connections: 5 nope didn't compile with IPv6 no 3rd party & no modified code |
|
|
I've attached TDebug.tar.gz to the bugreport - a small debugging module I made for this, just extract it somewhere and run ./build in it. If someone tells you (s)he is throttled for no reason again, then do: /TDEBUG LIST /TDEBUG LISTEVENTS and mail it to me ([email protected]) or post it here. After you did that, you can do /TDEBUG FLUSH which will remove all throttling entries. These commands (especially the /TDEBUG LIST) are also "safe" to use when there's no problem, so feel free to test if it outputs anything (if there are any throttling entries of course ;p). |
|
|
./build: Permission denied. nm got it had to chmod +x build |
|
|
slot=192, ip=65.170.4.59, since=1115794611, count=1, on_for=25 slot=385, ip=172.169.251.224, since=1115794502, count=8, on_for=134 [EXP] End of /TDEBUG LIST htmcalc: fptr=2818e03c, every=1, howmany=0, last=1115794671, owner=81f1880 lcf: fptr=2818de3c, every=5, howmany=0, last=1115794671, owner=81f1880 modef_event: fptr=8058364, every=10, howmany=0, last=1115794671, owner=0 bucketcleaning: fptr=805aaac, every=60, howmany=0, last=1115794671, owner=0 cmodej_cleanup_structs: fptr=805d808, every=60, howmany=0, last=1115794671, owner=0 fdlistcheck: fptr=805ba74, every=1, howmany=0, last=1115794671, owner=0 loop: fptr=805b38c, every=0, howmany=0, last=1115794671, owner=0 garbage: fptr=805b3a8, every=600, howmany=0, last=1115794611, owner=0 tunefile: fptr=807d560, every=300, howmany=0, last=1115794627, owner=0 tklexpire: fptr=80781d4, every=5, howmany=0, last=1115794671, owner=0 ADDITIONAL INFO: now=1115794671, e_clean_out_throttling_buckets=805aaac End of event list. |
|
|
slot=294, ip=24.32.5.73, since=1117353224, count=2, on_for=74 slot=326, ip=63.230.51.126, since=1117353224, count=1, on_for=74 slot=477, ip=207.68.110.129, since=1117353226, count=1, on_for=72 slot=567, ip=66.252.2.167, since=1117353221, count=2, on_for=77 slot=614, ip=172.149.68.101, since=1117353230, count=1, on_for=68 slot=633, ip=24.49.97.211, since=1117353224, count=1, on_for=74 slot=670, ip=65.170.4.157, since=1117353226, count=1, on_for=72 slot=948, ip=65.95.26.183, since=1117353225, count=1, on_for=73 slot=955, ip=65.3.154.86, since=1117353232, count=1, on_for=66 slot=977, ip=67.181.231.43, since=1117353225, count=1, on_for=73 slot=1006, ip=70.178.137.3, since=1117353226, count=1, on_for=72 End of /TDEBUG LIST |
|
|
Unable to reproduce. Module output also showed (in all cases) the user was "rightfully" throttled (no weird timestamps etc). |
|
|
I just want to add that someone else reported a similar problem on another server. I ran the TDEBUG module at it, and it actually showed tons (really *TONS*) of entries that should have been cleared. Unfortunately it didn't have a debugger (well, gdb crashed on boot), so wasn't able to figure it out. I've upgraded the server now from 3.2.4 to 3.2.5. slot=0, ip=XXX.157.116.XX, since=1151878203, count=1, on_for=5492508 [EXP] slot=2, ip=XX.17.166.X, since=1154570315, count=1, on_for=2800396 [EXP] slot=2, ip=XXX.169.153.XX, since=1154514478, count=1, on_for=2856233 [EXP] slot=2, ip=XXX.173.0.XX, since=1152066530, count=1, on_for=5304181 [EXP] slot=3, ip=XX.231.248.XX, since=1153460793, count=1, on_for=3909918 [EXP] slot=3, ip=XX.25.164.X, since=1153003905, count=1, on_for=4366806 [EXP] slot=4, ip=XX.248.53.XX, since=1154859996, count=1, on_for=2510715 [EXP] slot=4, ip=XXX.147.104.XXX, since=1151843211, count=1, on_for=5527500 [EXP] slot=6, ip=XX.6.177.XXX, since=1156311818, count=2, on_for=1058893 [EXP] slot=6, ip=XXX.144.32.XXX, since=1156078137, count=1, on_for=1292574 [EXP] slot=6, ip=XX.232.185.XXX, since=1155404820, count=1, on_for=1965891 [EXP] slot=6, ip=XX.248.53.XXX, since=1153276292, count=1, on_for=4094419 [EXP] As you can see, some throttling entries have been on it for over 2 months. If it happens again, I hope to trace it better, but without a debugger it's hard. Also ->durrie... I didn't notice any [EXP] entries in your list, yet you were saying you're having trouble, back then I therefore said it didn't show anything suspicious. But.. maybe you were pasting only part of it (the last XX lines) and not everything? So maybe you did actually have more results, including [EXP] entries? Well, I'm not expecting any answer back, but... just to say maybe due to miscommunication I did not receive the proper results. Otherwise, if that actually *was* the complete output (*all* output). Then there was no issue at that time (no bug). That could mean that others were having issues at another time, but not the time when /TDEBUG LIST was done. Or at least, all the IP's on that specific list were throttled correctly. |
|
|
I recently updated from CVS to regular .5 and started having the very same error. The time is now 00:37 local, and I get: ERROR :Closing Link: [83.233.59.125] (Throttled: Reconnecting too fast) -Email [email protected] for more information. The time() is: 1164588259 TDebug list shows: 01:43 -!- ip=81.224.227.246, since=1164583970, count=1, on_for=223 [EXP] 01:43 -!- ip=83.233.59.125, since=1164583950, count=19, on_for=243 [EXP] 01:43 -!- ip=194.237.110.189, since=1164583939, count=1, on_for=254 [EXP] 01:43 -!- ip=81.236.210.39, since=1164583958, count=1, on_for=235 [EXP] 01:43 -!- ip=213.114.201.165, since=1164583978, count=1, on_for=215 [EXP] 01:43 -!- of /TDEBUG LIST [EXP] is there and I still get throttled. Happens to everyone. You simply can't reconnect since it doesn't appear to clear the throttle. I've got AntiRandom and PrivDeaf modules installed. Neither "should" disturb throttle and I've been running a late CVS of .5 for month (many month). However, my time offset it huge: 01:53 !chat.snyggast.se *** Server=chat.snyggast.se TStime=1164584823 time()=1164588823 TSoffset=-3998 But it's been working for years as it is. The time offset is due to summer/winter time. I'm reverting to the older version to see it if works there. Honestly I don't have the time right now. If it works I'll probably wait for .6 and check there. |
|
|
Old CVS worked. So either one of the modules disturbed (old CVS used the same modules) or something else was wrong. I would really like to dig deeper into this bug honestly I am kind of burned out at the moment. If you would like I could probably do it later this week. Regards, Niklas |
|
|
Understood. Thanks for your info so far ;) |
|
|
If the ts offset change happend more than 3998 seconds ago (well slightly more), then the offset should be no problem. Basically whenever it's changed, like from 0 to -3998, it takes up to that time (3998 seconds, and a bit more) for everyhing to be back in line again [hence why having incorrect time is so bad]. [If this offset was already stored (like in ircd.tune), then it's no problem to begin with.] That's all for now ;) -- off to bed |
|
|
i've also experienced this with at least one of my users on one of my servers with 3.2.5 without either of those modules loaded, so its not related to those modules at all |
|
|
Some of my users are experiencing this problem too. I can post any debug stuff you need. I just rebooted the server, I think it's working now. |
|
|
If you could do this (after installing the TDebug module, see 'attached files' in the report), run these commands as ircop on irc: /TDEBUG LIST /TDEBUG LISTEVENTS /TSCTL ALLTIME (applies to everyone experiencing this issue, btw) |
|
|
I guess the above would also be helpful for in devil's case... Like I guess I was missing /TDEBUG LISTEVENTS output, which would be helpful (this shows, for example, if the 'remove old entries every X time' timer was correctly called). |
|
|
Only /TDEBUG LISTEVENTS gave any output: fptr=28399d30, every=5, howmany=0, last=1164815421, owner=816d3c0 fptr=2838f2bc, every=1, howmany=0, last=1164815422, owner=816d3c0 fptr=2838f094, every=5, howmany=0, last=1164815421, owner=816d3c0 fptr=805ba68, every=10, howmany=0, last=1164815422, owner=0 fptr=805df7c, every=30, howmany=0, last=1164815393, owner=0 fptr=8054e98, every=15, howmany=0, last=1164815412, owner=0 fptr=8060e54, every=60, howmany=0, last=1164815382, owner=0 fptr=805ef50, every=1, howmany=0, last=1164815422, owner=0 fptr=805e91c, every=0, howmany=0, last=1164815422, owner=0 fptr=805e85c, every=600, howmany=0, last=1164815371, owner=0 fptr=8079cd0, every=300, howmany=0, last=1164815373, owner=0 INFO: now=1164815422, e_clean_out_throttling_buckets=805df7c of event list. I also noticed that only the people running IceChat 7.0 (OS X) are experiencing this issue. Restarting the server fixed the issue temporarily. |
|
|
Hm, all those 3 should output *something*. Also I'm missing the first word of the LISTEVENTS output for each line :P. /me blames your client ;) <-- for not displaying all info correctly, that is. |
|
|
slot=106, ip=XXX.60.236.XXX, since=1173350598, count=2, on_for=730 [EXP] slot=426, ip=XXX.134.221.XXX, since=1173350546, count=3, on_for=782 [EXP] End of /TDEBUG LIST tklexpire: fptr=2a955a3150, every=5, howmany=0, last=1173354141, owner=8621f0 modef_event: fptr=43a5e0, every=10, howmany=0, last=1173354141, owner=0 bucketcleaning: fptr=43d0b0, every=15, howmany=0, last=1173354141, owner=0 unrealdns_removeoldrecords: fptr=433600, every=15, howmany=0, last=1173354141, owner=0 cmodej_cleanup_structs: fptr=440510, every=60, howmany=0, last=1173354141, owner=0 fdlistcheck: fptr=43e180, every=1, howmany=0, last=1173354141, owner=0 loop: fptr=43dae0, every=0, howmany=0, last=1173351332, owner=0 garbage: fptr=43da10, every=600, howmany=0, last=1173354141, owner=0 tunefile: fptr=45a740, every=300, howmany=0, last=1173354141, owner=0 htmcalc: fptr=2a95598470, every=1, howmany=0, last=1173354141, owner=8621f0 lcf: fptr=2a95598230, every=5, howmany=0, last=1173354141, owner=8621f0 ADDITIONAL INFO: now=1173351332, e_clean_out_throttling_buckets=43d0b0 End of event list. -Corvus.Immortal-Anime.Net- *** Server=Corvus.Immortal-Anime.Net TStime=1173351384 time()=1173354983 TSoffset=-3597 Unreal3.2.6 x86_64 GNU/Linux=2309 /edit: after issuing infinite throttles for a while they suddenly started to work fine as they should. weird. |
|
|
Thanks hmtX, for all the info. All details seem to indicate that the IRCd clock was put 1 hour backwards (3597 seconds to be exact) very recently before your post. Possibly by a services time synch (SVSTIME), such as one done by neostats (though anope mods exist as well). Can you confirm that the issue solved by itself, to be exact: 46 minutes after your first post (without the edit)? Whenever the ircd clock is changed so drastically, it takes up to [the offset change] to get everything correct again. Although many things are impacted by a time change, throttling is the most visible part in this case (eg: few will notice a channel timestamp in the future, but when they can't connect to the server that's immediately visible). I'm working on something that will actively warn ircops whenever such a huge timeshift happens, and also tries to do a couple of small things to fix the *worst* part of the consequences, such as throttling. Let me know if you agree the above (first part ;p) has possibly happened. |
|
|
unfortunately i can't confirm that because something weird happened afterwards. after the TSCTL ALLTIME i could no longer perform any command, the the ircd was stalled like it is when it tries to catch up after a time change. i stayed connected for 10 minutes and told myself to wait it out, ever so often issuing /lusers to see when it would react again. after 10 minutes i suddenly got a * [10101] Host disconnected message and couldn't reconnect (because of the throttle). ok er not that i wrote that... i reconnected 12:30, issued TDEBUG LIST at 13:11 where it output slot=426, ip=XXX.134.221.XXX, since=1173349799, count=1, on_for=2485 [EXP] End of /TDEBUG LIST next time i did it was 14:00 where the list was empty. it has worked since then even after restarting the ircd. /edit: TSoffset=0 since then. the server is standalone right now and not connected to the network, it was initially though until we noticed the throttle thing. |
|
|
Ok, thanks :) The "stalling" is indeed another effect of time change, I forgot if that happens if the time goes backwards or forwards, though ;p It's the other thing I'll code a workaround for when timechanging, besides throttling. EDIT: time shift = time |
|
|
it stalls for positive timeshifts until it has been caught. negative timeshifts are worse i guess ;o /edit: manually changing TStime() back and forth is fun. /edit2: while i'm ranting, i don't understand why there's a difference between hash.c:796 for (i = 0; i < THROTTLING_HASH_SIZE; i++) and tdebug.c:84 for (i=0; i <= THROTTLING_HASH_SIZE; i++) ~_~ |
|
|
perhaps we should use this report for the timechange stuff: 0003230 i think when adjusting timestamp offset, every timestamp should be updated (or at the least, ones that cause issues) |
|
|
yes, we'll use 0003230 for this. Note for future users experiencing this throttle bug: if you have not doneany time changes and can provide us with the TDEBUG stuff from above, let us know |
|
|
Syzop, whats causing this bug is actually the event timers (not sure if you knew that or not) [4] <- [:bunker.de.p2p-network.net 304 :slot=204, ip=85.17.40.165, since=1173501224, count=2, on_for=317 [EXP]] [4] <- [:bunker.de.p2p-network.net 304 :slot=423, ip=85.17.40.167, since=1173500484, count=2, on_for=1057 [EXP]] [4] <- [:bunker.de.p2p-network.net 304 :slot=434, ip=209.128.8.134, since=1173500216, count=3, on_for=1325 [EXP]] [4] <- [:bunker.de.p2p-network.net 304 :slot=1004, ip=85.17.40.163, since=1173501137, count=3, on_for=404 [EXP]] [4] <- [:bunker.de.p2p-network.net 304 :tklexpire: fptr=b7dc47d9, every=5, howmany=0, last=1173501587, owner=864b690] [4] <- [:bunker.de.p2p-network.net 304 :htmcalc: fptr=b7db9403, every=1, howmany=0, last=1173501589, owner=864b690] [4] <- [:bunker.de.p2p-network.net 304 :lcf: fptr=b7db950e, every=5, howmany=0, last=1173501587, owner=864b690] [4] <- [:bunker.de.p2p-network.net 304 :modef_event: fptr=807f2b7, every=10, howmany=0, last=1173503741, owner=0] [4] <- [:bunker.de.p2p-network.net 304 :bucketcleaning: fptr=8083db1, every=30, howmany=0, last=1173503730, owner=0] [4] <- [:bunker.de.p2p-network.net 304 :unrealdns_removeoldrecords: fptr=807a60a, every=15, howmany=0, last=1173503736, owner=0] [4] <- [:bunker.de.p2p-network.net 304 :cmodej_cleanup_structs: fptr=80874f0, every=60, howmany=0, last=1173503730, owner=0] [4] <- [:bunker.de.p2p-network.net 304 :fdlistcheck: fptr=808584a, every=1, howmany=0, last=1173503743, owner=0] [4] <- [:bunker.de.p2p-network.net 304 :loop: fptr=8085638, every=0, howmany=0, last=1173501589, owner=0] [4] <- [:bunker.de.p2p-network.net 304 :garbage: fptr=8085588, every=600, howmany=0, last=1173503549, owner=0] [4] <- [:bunker.de.p2p-network.net 304 :tunefile: fptr=80a4a6a, every=300, howmany=0, last=1173503549, owner=0] [4] <- [:bunker.de.p2p-network.net 304 :ADDITIONAL INFO: now=1173501589, e_clean_out_throttling_buckets=8083db1] [4] <- [:bunker.de.p2p-network.net NOTICE djGrrr_Marine :*** Server=bunker.de.p2p-network.net TStime=1173501660 time()=1173501662 TSoffset=-1] [4] <- [:borg.nl.p2p-network.net NOTICE djGrrr_Marine :*** Server=borg.nl.p2p-network.net TStime=1173501661 time()=1173501663 TSoffset=0] [4] <- [:grass.nl.p2p-network.net NOTICE djGrrr_Marine :*** Server=grass.nl.p2p-network.net TStime=1173501663 time()=1173501663 TSoffset=0] [4] <- [:thecrypt.de.p2p-network.net NOTICE djGrrr_Marine :*** Server=thecrypt.de.p2p-network.net TStime=1173501662 time()=1173501662 TSoffset=1] [4] <- [:meatball.se.p2p-network.net NOTICE djGrrr_Marine :*** Server=meatball.se.p2p-network.net TStime=1173501662 time()=1173501665 TSoffset=-3] [4] <- [:hub.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=hub.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=0] [4] <- [:citadel.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=citadel.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=0] [4] <- [:juggernaut.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=juggernaut.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1] [4] <- [:blizzard.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=blizzard.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1] [4] <- [:base.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=base.us.p2p-network.net TStime=1173501664 time()=1173501664 TSoffset=0] [4] <- [:juno.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=juno.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1] [4] <- [:enterprise.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=enterprise.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1] [4] <- [:mars.ca.p2p-network.net NOTICE djGrrr_Marine :*** Server=mars.ca.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=0] [4] <- [:drone.p2p-network.net NOTICE djGrrr_Marine :*** Server=drone.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=0] [4] <- [:area51.us.p2p-network.net NOTICE djGrrr_Marine :*** Server=area51.us.p2p-network.net TStime=1173501663 time()=1173501664 TSoffset=-1] my clock was behind by 1 hour (-3600). i synced it via ntpdate, then, when i synced the clocks with SVSTIME via services, it adjusted the event timers forward by 3600 seconds. so basically, you need to be able to detect system clock changes somehow btw, i never started connecting to this server until i did all this clock syncing stuff edit: or maybe, this would be easier... detect when the "last" parameter for the event timers are ahead of current TStime(), if they are, readjust them |
|
|
Yeah I know, see 0003230 :) |
|
|
- Added some big warnings regarding big timeshifts. In the IRCd world correct time is very important. This means that time should be correct when the IRCd is booted, either by running ntpd/ntpdate on the system or some other synchronization software, or by using the built-in timesync feature. Whenever the clock is adjusted for more than a few seconds AFTER the IRCd has booted, it can lead to dangerous effects ranging from unfair timestamps for nicks and channels (and hence the possibility to takeover channels), to even completely stalling the IRCd (negative timeshift) or making it so nobody can connect anymore due to throttling (positive timeshift). We now try to 'fix' the worst effects such as the IRCd freeze and throttling. This does not fix the whole problem, so I've added some big warnings when the clock is adjusted, including an annoying one every 5 minutes if the clock was set backwards, until the time is OK again (catches up with the original time). This fixes 0003230 reported by Stealth, and 0002521 reported by durrie. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-05-10 05:44 | durrie | New Issue | |
| 2005-05-10 06:08 | sin-x | Note Added: 0009920 | |
| 2005-05-10 06:09 | sin-x | Note Edited: 0009920 | |
| 2005-05-10 06:14 | durrie | Note Added: 0009921 | |
| 2005-05-10 06:20 | sin-x | Note Added: 0009923 | |
| 2005-05-10 06:22 | durrie | Note Added: 0009924 | |
| 2005-05-10 06:26 | sin-x | Note Added: 0009926 | |
| 2005-05-10 06:29 | durrie | Note Added: 0009927 | |
| 2005-05-10 06:34 | sin-x | Note Added: 0009928 | |
| 2005-05-10 06:37 | durrie | Note Added: 0009929 | |
| 2005-05-10 10:38 | syzop | Note Added: 0009931 | |
| 2005-05-10 18:45 | durrie | Note Added: 0009933 | |
| 2005-05-10 19:00 | syzop | File Added: TDebug.tar.gz | |
| 2005-05-10 19:04 | syzop | Note Added: 0009934 | |
| 2005-05-10 19:05 | syzop | Note Edited: 0009934 | |
| 2005-05-10 19:05 | syzop | Note Edited: 0009934 | |
| 2005-05-10 19:17 | durrie | Note Added: 0009935 | |
| 2005-05-10 19:40 | durrie | Note Edited: 0009935 | |
| 2005-05-11 03:11 | durrie | Note Added: 0009936 | |
| 2005-05-29 04:12 | durrie | Note Added: 0010010 | |
| 2005-12-10 17:18 | syzop | Status | new => closed |
| 2005-12-10 17:18 | syzop | Note Added: 0010852 | |
| 2005-12-10 17:18 | syzop | Resolution | open => unable to duplicate |
| 2006-09-04 09:50 | syzop | Note Added: 0012306 | |
| 2006-09-04 09:50 | syzop | Status | closed => acknowledged |
| 2006-11-26 17:49 | devil | Note Added: 0012738 | |
| 2006-11-26 17:56 | devil | Note Added: 0012739 | |
| 2006-11-26 17:58 | syzop | Note Added: 0012740 | |
| 2006-11-26 18:03 | syzop | Note Added: 0012741 | |
| 2006-11-27 04:48 | djGrrr | Note Added: 0012742 | |
| 2006-11-29 09:34 | Jon335 | Note Added: 0012764 | |
| 2006-11-29 09:40 | syzop | Note Added: 0012765 | |
| 2006-11-29 09:43 | syzop | Note Added: 0012766 | |
| 2006-11-29 09:55 | Jon335 | Note Added: 0012767 | |
| 2006-11-29 09:56 | Jon335 | Note Edited: 0012767 | |
| 2006-11-29 10:02 | syzop | Note Added: 0012768 | |
| 2006-11-29 10:02 | syzop | Note Edited: 0012768 | |
| 2007-03-05 05:52 | syzop | Relationship added | related to 0003252 |
| 2007-03-08 05:15 | hmtX | Note Added: 0013281 | |
| 2007-03-08 05:20 | hmtX | Note Edited: 0013281 | |
| 2007-03-08 06:09 | hmtX | Note Edited: 0013281 | |
| 2007-03-08 07:10 | hmtX | Note Edited: 0013281 | |
| 2007-03-08 07:18 | syzop | Note Added: 0013282 | |
| 2007-03-08 07:38 | hmtX | Note Added: 0013283 | |
| 2007-03-08 07:41 | hmtX | Note Edited: 0013283 | |
| 2007-03-08 07:44 | syzop | Note Added: 0013284 | |
| 2007-03-08 07:45 | syzop | Note Edited: 0013284 | |
| 2007-03-08 07:45 | syzop | Note Edited: 0013284 | |
| 2007-03-08 07:49 | hmtX | Note Added: 0013285 | |
| 2007-03-08 07:57 | hmtX | Note Edited: 0013285 | |
| 2007-03-08 08:24 | hmtX | Note Edited: 0013285 | |
| 2007-03-08 09:13 | djGrrr | Note Added: 0013286 | |
| 2007-03-08 09:22 | syzop | Note Added: 0013287 | |
| 2007-03-09 22:54 | djGrrr | Note Added: 0013296 | |
| 2007-03-09 22:56 | djGrrr | Note Edited: 0013296 | |
| 2007-03-10 05:31 | syzop | Note Added: 0013300 | |
| 2009-01-24 15:20 | syzop | QA | => Not touched yet by developer |
| 2009-01-24 15:20 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2009-01-24 15:20 | syzop | Status | acknowledged => resolved |
| 2009-01-24 15:20 | syzop | Fixed in Version | => 3.2.8 |
| 2009-01-24 15:20 | syzop | Assigned To | => syzop |
| 2009-01-24 15:20 | syzop | Note Added: 0015704 |
