0001194: Banlists not working

(0005450)
Dusk (developer)
2012-12-01 15:36

Works fine for me under Debian...

(0005451)
Torr Samaho (administrator)
2012-12-01 19:42

I can't reproduce these problems either. Did this only recently start happening? Are the affected servers running the official Zandronum 1.0 binary or some modified version?

(0005453)
Metal (reporter)
2012-12-02 01:34
edited on: 2012-12-02 01:50

Yes, this started fairly recently. AFAIK, they are running modified binaries. NJ is the only one using the Zandro 1.0 binary. But they still encounter this problem.

Edit: I kind of figured it was only on linux because I tested it on my own windows machine and it seemed to work perfectly. Sorry for the confusion.

A small log from another person experiencing this problem.
[21:38] <Watermelon> if it helps, when you press "up" on your keyboard to do the last command, this is what happened to me
[21:38] <Watermelon> oh damn didnt know that
[21:38] <Watermelon> addban "ip" "perm" "reason"
[21:38] <Watermelon> *press up to get the above line again*
[21:38] <Watermelon> addban "ip" "perm" "reason"
[21:38] <Watermelon> i did that every second
[21:39] <Watermelon> for the first 5 seconds (5 ups and enters) it says "ip is already on the ban list"
[21:39] <Watermelon> then randomly it gets removed after 5 seconds

(0005454)
Torr Samaho (administrator)
2012-12-02 08:19

Is the IP ban file opened by any other program while the servers are running?

(0005462)
Metal (reporter)
2012-12-02 21:44

They say no.

(0005463)
Torr Samaho (administrator)
2012-12-02 22:06

Is the file write protected? If this didn't happen earlier, something has to have changed on their systems.

(0005470)
Metal (reporter)
2012-12-03 23:50

The host for BE says

[19:49] <Jenova> no
[19:49] <Jenova> and this has been a problem forever

I'm not getting a straight answer from anyone. Watermelon (The co host of BE) says it's been recent, and Jenova says it's been forever.

[19:49] <Jenova> like since I first installed st on the box
[19:50] <Jenova> it can add to the file
[19:50] <Jenova> but its messed up

I think it would be beneficial to open this ticket to the public so they can reply themselves.

(0005471)
Torr Samaho (administrator)
2012-12-04 06:15

Ok, the ticket should be public now.

(0005473)
Konar6 (reporter)
2012-12-04 19:15
edited on: 2012-12-04 19:16

There are two independent issues mentioned in this ticket.

First one isn't really an issue in Zandronum - NJ is using a modified binary, and Watermelon confirmed that it was the cause, as the official build worked fine (and apparently he fixed his one too now).

The second issue occuring on Jenova's server is a duplicate of'http://zandronum.com/tracker/view.php?id=290 [^]' , which reminded me that I had that problem back in 2010 on one of my servers before I switched it to Ubuntu (it affects only some systems - Debian 64bit being one). Now when the source is open, I inspected it again and here comes the fix. Unlike my expectations, no change in the source was needed to make it work. Just build Zandronum from source on the system and that's it. Or here is a precompiled working 1.0 server binary, built on the "problematic" Debian 64bit system ->'http://sickedwick.net/misc/zandronum-server_debian_x64.zip [^]'

(0005477)
Watermelon (developer)
2012-12-05 21:02

Interestingly as Konar said, the regular build seemed to have worked. I compiled a new version fresh and terminated all the servers.

Though it seems that the problem begins to happen later on, so I will ideally stay tuned. Resetting the servers could be the key to this potential problem. For some reason when I recompiled it fixed itself... which doesn't make sense since I never touched the ban mechanisms in the first place. Could there be possibly something that causes it to go hay-wire later on?

(0005478)
AlexMax (developer)
2012-12-06 02:05
edited on: 2012-12-06 02:08

For what it is worth, I have been having this problem with bans since Zandronum 1.0. I do not run a modded server (Spak City runs wbuild, but Spak City and Funcrusher are not affiliated), just the binary grabbed from zandronum site. I load the banlist on a timer, and what I find in the banlist after commands are run is...interesting.

From my limited experimentation with "addban", it seems like any permanent ban is written correctly. Also, updating an existing ban in any case works fantastically. However, new timed bans are where things mess up...if you ban someone for say 30min for no reason, only the ban time will be written to the file. If you add a new timed ban with a reason, only the colon and the reason are written to the file. This applies to votebans too.

So it seems to me that as a workaround, admins should permaban people first, then update the ban after-the-fact to a specific time.

(0005480)
Torr Samaho (administrator)
2012-12-07 18:49

Quote from AlexMax
From my limited experimentation with "addban", it seems like any permanent ban is written correctly. Also, updating an existing ban in any case works fantastically. However, new timed bans are where things mess up...if you ban someone for say 30min for no reason, only the ban time will be written to the file. If you add a new timed ban with a reason, only the colon and the reason are written to the file. This applies to votebans too.

I just tested this briefly, but addban works fine for me with non-permanent bans. Who can confirm that there are problems with addban? And for those who have problems: Does it also happen if Zandronum itself created the banlist file and no other program ever touched that file?

(0005484)
AlexMax (developer)
2012-12-08 01:40

Torr, I tried adding a ban to a fresh banlist, and it had the same effects.

(0005487)
Konar6 (reporter)
2012-12-08 14:30

Did you read/try the solution I posted above?

(0005758)
Torr Samaho (administrator)
2013-01-13 10:40

Without more information there is nothing I can do. It works just fine for me on all systems I tested.

(0005785)
DevilHunter (reporter)
2013-01-15 06:17

C4 tried to make a Static Link of Zandronum, but for some reason could not find a way to.

[08:51:21] [Affliction] a makefile without any references to any form of linker settings :|
[08:55:54] [Affliction] so, it compiles fine
[08:56:19] [Affliction] But unless I can find some way to statically link it, we won't be able to rule out the alleged issue as being my server's fault
[09:06:46] [Affliction] Well, I don't see any form of linker settings anywhere. No point compiling it to correct this alleged environment issue if it can't be static linked.
[10:47:05] [Affliction] I can compile it fine, I just can't figure out how to modify the (c)makefile to pass a very simple argument to the linker

(0007034)
Catastrophe (reporter)
2013-08-17 00:06

Please fix this already there are people openly evading kicks on [NJ] Funcrusher, this needs to be fixed -immediately-

(0007037)
Dusk (developer)
2013-08-17 04:55
edited on: 2013-08-17 04:56

And how is this supposed to be fixed when nobody can reproduce this? Please don't bump tickets without adding anything new to it.

(0007038)
Konar6 (reporter)
2013-08-17 09:14

Well, I reproduced this and found a (immediate) solution above. Just have the admin of NJ apply it...

(0010928)
DevilHunter (reporter)
2014-11-22 05:49

I know this is old. But I somewhat found a fix for this.. I just gone ahead, and grabbed the source, and built it on TSPG, and Armada. The bans work as they should.

I just can't figure out for the life of me, why the precompiled builds on the site have this issue.

(0011611)
Konar6 (reporter)
2015-02-07 18:56

Fixed in the attached patch.

(0011613)
Edward-san (developer)
2015-02-07 20:29

It's not clear if the issue happens in 2.0 beta builds. Please check this out.

If it happens in the beta builds, it's gonna be easier to check the fix, ie make Blzut3 build a special zandronum x64 build containing the fix.

(0011614)
Konar6 (reporter)
2015-02-07 20:34

DevilHunter: ^

(0011621)
Edward-san (developer)
2015-02-08 01:48

I've taken a look at the patch and I believe there's no need for FString, hence I've made a somewhat simpler patch which should do the job fine.

(0011622)
Torr Samaho (administrator)
2015-02-08 09:41

Before I look at the patches, can somebody summarize what the problem is that causes the ban list not to work on some systems?

(0011623)
Edward-san (developer)
2015-02-08 10:19

Torr, while it's not sure this is the real fix, but according to C and C++ rules, using "sprintf(str, "%s%s", str, other_str);" is undefined behavior, because of the memory overlapping. It was used in abundance in 'IPList::AddEntry' and in 'IPList::removeExpiredEntries'.

IMO in some systems such "sprintf" call wouldn't work at all, hence the "other_str" would be not appended to the existing "str", hence making the banlist entry adding not working properly.

(0011627)
Torr Samaho (administrator)
2015-02-08 12:35
edited on: 2015-02-08 12:40

Can you point me to a source that describes the corresponding C/C++ limitations? Would make sense if this stuff doesn't have to work, but I'd like to understand what we are fixing before marking something as fixed in the history file.

(0011628)
Konar6 (reporter)
2015-02-08 12:41

"The behavior of this function is undefined if copying takes place between objects that overlap—for example, if s is also given as an argument to be printed under control of the ‘%s’ conversion."

'http://www.gnu.org/software/libc/manual/html_mono/libc.html#Formatted-Output-Functions [^]'

'http://stackoverflow.com/questions/1283354/is-sprintfbuffer-s-buffer-safe [^]'

(0011629)
Dusk (developer)
2015-02-08 12:48
edited on: 2015-02-08 12:49

I'll just point out that, by the looks of it, FString::Format is not affected by this since it reallocates the Chars buffer before doing the format. FString::AppendFormat is, however, since it reallocates on demand (though you shouldn't need to pass the FString itself into AppendFormat anyway since you're already appending to it).

(0011630)
Torr Samaho (administrator)
2015-02-08 12:55

Thanks for the detailed info! We should definitely change this and I agree with Edward-san that we should not start using FStrings for this, but use proper sprintf calls instead. This way the code doesn't get any additional ZDoom dependencies and can still easily be used in non-ZDoom code like the master server.

Edward-san, I have some comments to your patch. Can you commit it to the sandbox, then I can write the comments into the code changes on bitbucket.

(0011632)
Edward-san (developer)
2015-02-08 13:36
edited on: 2015-02-08 15:07

Done.

(0011691)
cobalt (updater)
2015-02-15 20:18

Issue addressed by commit 0cf13db5ce64: - Fixed: On some systems, adding bans and ban exemptions from the server console didn't work (fixes 1194).
Committed by edward_san [edward-san] on Sunday 15 February 2015 13:00:29

Changes in files:
docs/zandronum-history.txt | 1 +
src/networkshared.cpp | 83 ++++++++++++++++++++++++++++++++++++-----------------------------------------------
2 files changed, 37 insertions(+), 47 deletions(-)

(0011693)
Torr Samaho (administrator)
2015-02-15 20:54

I just hear that nobody ever confirmed that this patch actually fixes the problem. Konar6, is this true?

(0011695)
Konar6 (reporter)
2015-02-15 21:31
edited on: 2015-02-15 21:32

I don't know how we could accurately confirm that until the next beta build is released, since the bug can be reproduced only in the official builds.

(0011696)
Edward-san (developer)
2015-02-15 22:38

DevilHunter doesn't reproduce the issue with the official 1.3 build from this link:'http://zandronum.com/downloads/zandronum1.3-linux-x86_64.tar.bz2 [^]'

If someone else can reproduce the problem with that build, please reply.

(0011834)
Dusk (developer)
2015-03-16 01:25

Nobody can reproduce the problem anymore so.. let's just hope the commit fixed it I guess.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	DevilHunter Catastrophe WaTaKiD
Opponents:	No one explicitly opposes this issue yet.

Notes
(0005450) Dusk (developer) 2012-12-01 15:36	Works fine for me under Debian...

(0005451) Torr Samaho (administrator) 2012-12-01 19:42	I can't reproduce these problems either. Did this only recently start happening? Are the affected servers running the official Zandronum 1.0 binary or some modified version?

(0005453) Metal (reporter) 2012-12-02 01:34 edited on: 2012-12-02 01:50	Yes, this started fairly recently. AFAIK, they are running modified binaries. NJ is the only one using the Zandro 1.0 binary. But they still encounter this problem. Edit: I kind of figured it was only on linux because I tested it on my own windows machine and it seemed to work perfectly. Sorry for the confusion. A small log from another person experiencing this problem. [21:38] <Watermelon> if it helps, when you press "up" on your keyboard to do the last command, this is what happened to me [21:38] <Watermelon> oh damn didnt know that [21:38] <Watermelon> addban "ip" "perm" "reason" [21:38] <Watermelon> press up to get the above line again [21:38] <Watermelon> addban "ip" "perm" "reason" [21:38] <Watermelon> i did that every second [21:39] <Watermelon> for the first 5 seconds (5 ups and enters) it says "ip is already on the ban list" [21:39] <Watermelon> then randomly it gets removed after 5 seconds

(0005454) Torr Samaho (administrator) 2012-12-02 08:19	Is the IP ban file opened by any other program while the servers are running?

(0005462) Metal (reporter) 2012-12-02 21:44	They say no.

(0005463) Torr Samaho (administrator) 2012-12-02 22:06	Is the file write protected? If this didn't happen earlier, something has to have changed on their systems.

(0005470) Metal (reporter) 2012-12-03 23:50	The host for BE says [19:49] <Jenova> no [19:49] <Jenova> and this has been a problem forever I'm not getting a straight answer from anyone. Watermelon (The co host of BE) says it's been recent, and Jenova says it's been forever. [19:49] <Jenova> like since I first installed st on the box [19:50] <Jenova> it can add to the file [19:50] <Jenova> but its messed up I think it would be beneficial to open this ticket to the public so they can reply themselves.

(0005471) Torr Samaho (administrator) 2012-12-04 06:15	Ok, the ticket should be public now.

(0005473) Konar6 (reporter) 2012-12-04 19:15 edited on: 2012-12-04 19:16	There are two independent issues mentioned in this ticket. First one isn't really an issue in Zandronum - NJ is using a modified binary, and Watermelon confirmed that it was the cause, as the official build worked fine (and apparently he fixed his one too now). The second issue occuring on Jenova's server is a duplicate of'http://zandronum.com/tracker/view.php?id=290 [^]' , which reminded me that I had that problem back in 2010 on one of my servers before I switched it to Ubuntu (it affects only some systems - Debian 64bit being one). Now when the source is open, I inspected it again and here comes the fix. Unlike my expectations, no change in the source was needed to make it work. Just build Zandronum from source on the system and that's it. Or here is a precompiled working 1.0 server binary, built on the "problematic" Debian 64bit system ->'http://sickedwick.net/misc/zandronum-server_debian_x64.zip [^]'

(0005477) Watermelon (developer) 2012-12-05 21:02	Interestingly as Konar said, the regular build seemed to have worked. I compiled a new version fresh and terminated all the servers. Though it seems that the problem begins to happen later on, so I will ideally stay tuned. Resetting the servers could be the key to this potential problem. For some reason when I recompiled it fixed itself... which doesn't make sense since I never touched the ban mechanisms in the first place. Could there be possibly something that causes it to go hay-wire later on?

(0005478) AlexMax (developer) 2012-12-06 02:05 edited on: 2012-12-06 02:08	For what it is worth, I have been having this problem with bans since Zandronum 1.0. I do not run a modded server (Spak City runs wbuild, but Spak City and Funcrusher are not affiliated), just the binary grabbed from zandronum site. I load the banlist on a timer, and what I find in the banlist after commands are run is...interesting. From my limited experimentation with "addban", it seems like any permanent ban is written correctly. Also, updating an existing ban in any case works fantastically. However, new timed bans are where things mess up...if you ban someone for say 30min for no reason, only the ban time will be written to the file. If you add a new timed ban with a reason, only the colon and the reason are written to the file. This applies to votebans too. So it seems to me that as a workaround, admins should permaban people first, then update the ban after-the-fact to a specific time.

(0005480) Torr Samaho (administrator) 2012-12-07 18:49	Quote from AlexMax From my limited experimentation with "addban", it seems like any permanent ban is written correctly. Also, updating an existing ban in any case works fantastically. However, new timed bans are where things mess up...if you ban someone for say 30min for no reason, only the ban time will be written to the file. If you add a new timed ban with a reason, only the colon and the reason are written to the file. This applies to votebans too. I just tested this briefly, but addban works fine for me with non-permanent bans. Who can confirm that there are problems with addban? And for those who have problems: Does it also happen if Zandronum itself created the banlist file and no other program ever touched that file?

(0005484) AlexMax (developer) 2012-12-08 01:40	Torr, I tried adding a ban to a fresh banlist, and it had the same effects.

(0005487) Konar6 (reporter) 2012-12-08 14:30	Did you read/try the solution I posted above?

(0005758) Torr Samaho (administrator) 2013-01-13 10:40	Without more information there is nothing I can do. It works just fine for me on all systems I tested.

(0005785) DevilHunter (reporter) 2013-01-15 06:17	C4 tried to make a Static Link of Zandronum, but for some reason could not find a way to. [08:51:21] [Affliction] a makefile without any references to any form of linker settings :\| [08:55:54] [Affliction] so, it compiles fine [08:56:19] [Affliction] But unless I can find some way to statically link it, we won't be able to rule out the alleged issue as being my server's fault [09:06:46] [Affliction] Well, I don't see any form of linker settings anywhere. No point compiling it to correct this alleged environment issue if it can't be static linked. [10:47:05] [Affliction] I can compile it fine, I just can't figure out how to modify the (c)makefile to pass a very simple argument to the linker

(0007034) Catastrophe (reporter) 2013-08-17 00:06	Please fix this already there are people openly evading kicks on [NJ] Funcrusher, this needs to be fixed -immediately-

(0007037) Dusk (developer) 2013-08-17 04:55 edited on: 2013-08-17 04:56	And how is this supposed to be fixed when nobody can reproduce this? Please don't bump tickets without adding anything new to it.

(0007038) Konar6 (reporter) 2013-08-17 09:14	Well, I reproduced this and found a (immediate) solution above. Just have the admin of NJ apply it...

(0010928) DevilHunter (reporter) 2014-11-22 05:49	I know this is old. But I somewhat found a fix for this.. I just gone ahead, and grabbed the source, and built it on TSPG, and Armada. The bans work as they should. I just can't figure out for the life of me, why the precompiled builds on the site have this issue.

(0011611) Konar6 (reporter) 2015-02-07 18:56	Fixed in the attached patch.

(0011613) Edward-san (developer) 2015-02-07 20:29	It's not clear if the issue happens in 2.0 beta builds. Please check this out. If it happens in the beta builds, it's gonna be easier to check the fix, ie make Blzut3 build a special zandronum x64 build containing the fix.

(0011614) Konar6 (reporter) 2015-02-07 20:34	DevilHunter: ^

(0011621) Edward-san (developer) 2015-02-08 01:48	I've taken a look at the patch and I believe there's no need for FString, hence I've made a somewhat simpler patch which should do the job fine.

(0011622) Torr Samaho (administrator) 2015-02-08 09:41	Before I look at the patches, can somebody summarize what the problem is that causes the ban list not to work on some systems?

(0011623) Edward-san (developer) 2015-02-08 10:19	Torr, while it's not sure this is the real fix, but according to C and C++ rules, using "sprintf(str, "%s%s", str, other_str);" is undefined behavior, because of the memory overlapping. It was used in abundance in 'IPList::AddEntry' and in 'IPList::removeExpiredEntries'. IMO in some systems such "sprintf" call wouldn't work at all, hence the "other_str" would be not appended to the existing "str", hence making the banlist entry adding not working properly.

(0011627) Torr Samaho (administrator) 2015-02-08 12:35 edited on: 2015-02-08 12:40	Can you point me to a source that describes the corresponding C/C++ limitations? Would make sense if this stuff doesn't have to work, but I'd like to understand what we are fixing before marking something as fixed in the history file.

(0011628) Konar6 (reporter) 2015-02-08 12:41	"The behavior of this function is undefined if copying takes place between objects that overlap—for example, if s is also given as an argument to be printed under control of the ‘%s’ conversion." 'http://www.gnu.org/software/libc/manual/html_mono/libc.html#Formatted-Output-Functions [^]' 'http://stackoverflow.com/questions/1283354/is-sprintfbuffer-s-buffer-safe [^]'

(0011629) Dusk (developer) 2015-02-08 12:48 edited on: 2015-02-08 12:49	I'll just point out that, by the looks of it, FString::Format is not affected by this since it reallocates the Chars buffer before doing the format. FString::AppendFormat is, however, since it reallocates on demand (though you shouldn't need to pass the FString itself into AppendFormat anyway since you're already appending to it).

(0011630) Torr Samaho (administrator) 2015-02-08 12:55	Thanks for the detailed info! We should definitely change this and I agree with Edward-san that we should not start using FStrings for this, but use proper sprintf calls instead. This way the code doesn't get any additional ZDoom dependencies and can still easily be used in non-ZDoom code like the master server. Edward-san, I have some comments to your patch. Can you commit it to the sandbox, then I can write the comments into the code changes on bitbucket.

(0011632) Edward-san (developer) 2015-02-08 13:36 edited on: 2015-02-08 15:07	Done.

(0011691) cobalt (updater) 2015-02-15 20:18	Issue addressed by commit 0cf13db5ce64: - Fixed: On some systems, adding bans and ban exemptions from the server console didn't work (fixes 1194). Committed by edward_san [edward-san] on Sunday 15 February 2015 13:00:29 Changes in files: docs/zandronum-history.txt \| 1 + src/networkshared.cpp \| 83 ++++++++++++++++++++++++++++++++++++----------------------------------------------- 2 files changed, 37 insertions(+), 47 deletions(-)

(0011693) Torr Samaho (administrator) 2015-02-15 20:54	I just hear that nobody ever confirmed that this patch actually fixes the problem. Konar6, is this true?

(0011695) Konar6 (reporter) 2015-02-15 21:31 edited on: 2015-02-15 21:32	I don't know how we could accurately confirm that until the next beta build is released, since the bug can be reproduced only in the official builds.

(0011696) Edward-san (developer) 2015-02-15 22:38	DevilHunter doesn't reproduce the issue with the official 1.3 build from this link:'http://zandronum.com/downloads/zandronum1.3-linux-x86_64.tar.bz2 [^]' If someone else can reproduce the problem with that build, please reply.

(0011834) Dusk (developer) 2015-03-16 01:25	Nobody can reproduce the problem anymore so.. let's just hope the commit fixed it I guess.

Issue History
Date Modified	Username	Field	Change
2012-12-01 04:40	Metal	New Issue
2012-12-01 15:36	Dusk	Note Added: 0005450
2012-12-01 15:36	Dusk	Status	new => feedback
2012-12-01 19:42	Torr Samaho	Note Added: 0005451
2012-12-02 01:34	Metal	Note Added: 0005453
2012-12-02 01:34	Metal	Status	feedback => new
2012-12-02 01:35	Metal	Note Edited: 0005453	View Revisions
2012-12-02 01:36	Metal	Note Edited: 0005453	View Revisions
2012-12-02 01:36	Metal	Note View State: 0005453: private
2012-12-02 01:36	Metal	Note View State: 0005453: public
2012-12-02 01:39	Metal	Note Edited: 0005453	View Revisions
2012-12-02 01:48	Metal	Note Edited: 0005453	View Revisions
2012-12-02 01:50	Metal	Note Edited: 0005453	View Revisions
2012-12-02 08:19	Torr Samaho	Note Added: 0005454
2012-12-02 21:44	Metal	Note Added: 0005462
2012-12-02 22:06	Torr Samaho	Note Added: 0005463
2012-12-03 23:50	Metal	Note Added: 0005470
2012-12-04 06:15	Torr Samaho	View Status	private => public
2012-12-04 06:15	Torr Samaho	Note Added: 0005471
2012-12-04 19:15	Konar6	Note Added: 0005473
2012-12-04 19:16	Konar6	Note Edited: 0005473	View Revisions
2012-12-05 21:02	Watermelon	Note Added: 0005477
2012-12-06 02:05	AlexMax	Note Added: 0005478
2012-12-06 02:07	AlexMax	Note Edited: 0005478	View Revisions
2012-12-06 02:08	AlexMax	Note Edited: 0005478	View Revisions
2012-12-07 18:49	Torr Samaho	Note Added: 0005480
2012-12-08 01:40	AlexMax	Note Added: 0005484
2012-12-08 14:30	Konar6	Note Added: 0005487
2013-01-13 10:40	Torr Samaho	Note Added: 0005758
2013-01-13 10:40	Torr Samaho	Status	new => feedback
2013-01-15 06:17	DevilHunter	Note Added: 0005785
2013-08-17 00:06	Catastrophe	Note Added: 0007034
2013-08-17 04:55	Dusk	Note Added: 0007037
2013-08-17 04:56	Dusk	Note Edited: 0007037	View Revisions
2013-08-17 09:14	Konar6	Note Added: 0007038
2013-08-17 10:05	Torr Samaho	Note Added: 0007040
2013-08-17 10:27	Torr Samaho	Note Deleted: 0007040
2014-11-22 05:49	DevilHunter	Note Added: 0010928
2015-02-07 18:55	Konar6	File Added: q.patch
2015-02-07 18:56	Konar6	Note Added: 0011611
2015-02-07 19:03	Dusk	Status	feedback => needs review
2015-02-07 20:29	Edward-san	Note Added: 0011613
2015-02-07 20:34	Konar6	Note Added: 0011614
2015-02-08 01:48	Edward-san	Note Added: 0011621
2015-02-08 01:48	Edward-san	File Added: banlist.diff.txt
2015-02-08 09:41	Torr Samaho	Note Added: 0011622
2015-02-08 10:19	Edward-san	Note Added: 0011623
2015-02-08 12:35	Torr Samaho	Note Added: 0011627
2015-02-08 12:40	Torr Samaho	Note Edited: 0011627	View Revisions
2015-02-08 12:41	Konar6	Note Added: 0011628
2015-02-08 12:48	Dusk	Note Added: 0011629
2015-02-08 12:49	Dusk	Note Edited: 0011629	View Revisions
2015-02-08 12:55	Torr Samaho	Note Added: 0011630
2015-02-08 13:36	Edward-san	Note Added: 0011632
2015-02-08 15:07	Edward-san	Note Edited: 0011632	View Revisions
2015-02-15 20:18	cobalt	Status	needs review => needs testing
2015-02-15 20:18	cobalt	Target Version	=> 1.4
2015-02-15 20:18	cobalt	Steps to Reproduce Updated	View Revisions
2015-02-15 20:18	cobalt	Note Added: 0011691
2015-02-15 20:54	Torr Samaho	Note Added: 0011693
2015-02-15 21:31	Konar6	Note Added: 0011695
2015-02-15 21:32	Konar6	Note Edited: 0011695	View Revisions
2015-02-15 22:38	Edward-san	Note Added: 0011696
2015-03-16 01:25	Dusk	Note Added: 0011834
2015-03-16 01:25	Dusk	Status	needs testing => closed
2015-03-16 01:25	Dusk	Assigned To	=> Edward-san
2015-03-16 01:25	Dusk	Resolution	open => unable to reproduce
2015-03-16 01:25	Dusk	Fixed in Version	=> 1.4
2015-03-16 01:25	Dusk	Steps to Reproduce Updated	View Revisions

Relationships