View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000847unrealircdpublic2003-03-27 13:002003-11-20 19:46
ReporterRavage Assigned Tocodemastr 
PrioritynormalSeveritycrashReproducibilityunable to reproduce
Status closedResolutionfixed 
Product Version3.2-beta15 
Summary0000847: ircd cored with throttle enabled
Descriptionircd cored with throttle enabled
Additional InformationGNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Core was generated by `/home/ircd/Unreal/src/ircd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libssl.so.0.9.6...done.
Loaded symbols for /usr/lib/libssl.so.0.9.6
Reading symbols from /usr/lib/libcrypto.so.0.9.6...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.6
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from src/modules/commands.so...done.
Loaded symbols for src/modules/commands.so
Reading symbols from src/modules/channeldumper.so...done.
Loaded symbols for src/modules/channeldumper.so
Reading symbols from src/modules/scan.so...done.
Loaded symbols for src/modules/scan.so
Reading symbols from src/modules/scan_socks.so...done.
Loaded symbols for src/modules/scan_socks.so
Reading symbols from src/modules/scan_http.so...done.
Loaded symbols for src/modules/scan_http.so
---Type <return> to continue, or q <return> to quit---
#0 0x0806498f in find_throttling_bucket (in=0x82629a8) at hash.c:771
771 if (bcmp(in, &p->in, sizeof(struct IN_ADDR)) == 0)
(gdb) bt
#0 0x0806498f in find_throttling_bucket (in=0x82629a8) at hash.c:771
#1 0x08064aa4 in throttle_can_connect (in=0x82629a8) at hash.c:803
#2 0x08070427 in add_connection (cptr=0x81811d0, fd=29) at s_bsd.c:1265
#3 0x08070df9 in read_message (delay=1, listp=0x814ad40) at s_bsd.c:1840
#4 0x080664b3 in main (argc=9, argv=0x0) at ircd.c:1336
#5 0x49ec19c4 in __libc_start_main () from /lib/libc.so.6
(gdb)
3rd party modules

Activities

codemastr

2003-04-06 22:34

reporter   ~0002131

Can you upgrade to the current cvs and see if this still exists?

Ravage

2003-04-06 22:49

reporter   ~0002132

i will test it after the next server restart

syzop

2003-04-07 01:10

administrator   ~0002138

[updated title]

Ravage

2003-04-10 12:53

reporter   ~0002202

releaseid 1.1.1.1.2.1.2.1.2.1711

#0 0x0806494f in find_throttling_bucket (in=0x82d0a98) at hash.c:771
---Type <return> to continue, or q <return> to quit---
771 if (bcmp(in, &p->in, sizeof(struct IN_ADDR)) == 0)
(gdb)

syzop

2003-04-10 13:18

administrator   ~0002206

Can you do:
x/x &in
x/x p
x/x p->in
p *in
p *p

Ravage

2003-04-10 13:34

reporter   ~0002207

Loaded symbols for src/modules/scan_http.so
#0 0x0806494f in find_throttling_bucket (in=0x82d0a98) at hash.c:771
---Type <return> to continue, or q <return> to quit---
771 if (bcmp(in, &p->in, sizeof(struct IN_ADDR)) == 0)
(gdb) bt
#0 0x0806494f in find_throttling_bucket (in=0x82d0a98) at hash.c:771
#1 0x08064a64 in throttle_can_connect (in=0x82d0a98) at hash.c:803
#2 0x080703f7 in add_connection (cptr=0x8181800, fd=131) at s_bsd.c:1265
#3 0x08070dc9 in read_message (delay=1, listp=0x814af60) at s_bsd.c:1840
#4 0x08066483 in main (argc=8, argv=0x0) at ircd.c:1337
#5 0x4bf9cdc4 in __libc_start_main () from /lib/libc.so.6
(gdb) x/x &in
Address requested for identifier "in" which is in register $ebx
(gdb) x/x p
0x5800: Cannot access memory at address 0x5800
(gdb) x/x p->in
Cannot access memory at address 0x5808
(gdb) p *in
$1 = {s_addr = 3878443532}
(gdb) p *p
Cannot access memory at address 0x5800
(gdb)

syzop

2003-04-10 14:34

administrator   ~0002210

Ok, and:
p p
p p->in
p *p->in

(for non-invited 3rd party viewers, I'm a bit lazy to find out which is a pointer etc)

Ravage

2003-04-10 14:41

reporter   ~0002211

(gdb) p p
$3 = (struct ThrottlingBucket *) 0x5800
(gdb) p p->in
Cannot access memory at address 0x5808
(gdb) p *p->in
Structure has no component named operator*.
(gdb)

syzop

2003-04-10 15:12

administrator   ~0002217

Last edited: 2003-04-10 15:13

 Ooo this is nice (not..):

763 struct ThrottlingBucket *find_throttling_bucket(struct IN_ADDR *in)
764 {
765 int hash = 0;
766 struct ThrottlingBucket *p;
767 hash = hash_throttling(in);
768
769 for (p = ThrottlingHash[hash]; p; p = p->next)
770 {
771 if (bcmp(in, &p->in, sizeof(struct IN_ADDR)) == 0)
772 return(p);
773 }
774 return NULL;
775 }

(gdb) p hash
$7 = 4
(gdb) p ThrottlingHash[4]
$8 = (struct ThrottlingBucket *) 0x0
(gdb) x/20x ThrottlingHash
0x81488c0 <ThrottlingHash>: 0x00000000 0x00000000 0x00000000 0x00000000
0x81488d0 <ThrottlingHash+16>: 0x00000000 0x00000000 0x00000000 0x00000000
0x81488e0 <ThrottlingHash+32>: 0x00000000 0x00000000 0x00000000 0x00000000
0x81488f0 <ThrottlingHash+48>: 0x00000000 0x00000000 0x00000000 0x00000000
0x8148900 <ThrottlingHash+64>: 0x00000000 0x00000000 0x00000000 0x00000000

(gdb) p p
$9 = (struct ThrottlingBucket *) 0x5800

So how did p get 0x5800 then? :P.

edited on: 04-10-03 15:13

codemastr

2003-04-10 21:08

reporter   ~0002229

Something tells me stskeeps's "expiring" routine is flawed...

codemastr

2003-04-12 20:23

reporter   ~0002295

Can you try upgrading to 1.1.1.1.2.1.2.1.2.1726 and see if it still happens? A few more throttling issues were fixed.

AI

2003-04-14 12:59

reporter   ~0002312

Last edited: 2003-04-14 13:02

 Is throtteling even working now? I updated to latest CVS on one my servers and now when I try to connect/disconnect then quickly re-connect I dont even see the 'Reconnecting too fast' message, I only get to see ' too many unknown connections from your IP' and that's I believe another anti flood feature not even Throttling related.
I know codemastr said he changed the throttle message a little so that mIRC recognizes it, but the problem is that I dont see it at all. what has really changed regarding Throttling?

edited on: 04-14-03 13:02

syzop

2003-04-14 13:13

administrator   ~0002313

from Changes:
- Changed throttling so it now bans after M connects in N seconds rather than 2 connects in N
  seconds. (set::throttle::connections).

The default is 3 in 15, so just change it :).

AI

2003-04-14 13:20

reporter   ~0002314

So if my unrealircd.conf reads:

throttle { period 10; };

How exactly do I go about changing that? what would it be to allow only 2 connects on 15 seconds?

throttle { period 2; 15; }; ?

Thanks in advance.

syzop

2003-04-14 13:27

administrator   ~0002315

throttle { connections 2; period 15; };

AI

2003-04-14 23:03

reporter   ~0002321

Well it has been running for the last 11 hours with an average of 50 users connected to that server with no problems so far, I ll keep you updated if it crashes.

Ravage

2003-04-14 23:55

reporter   ~0002327

I'm running 1737 now. I'll keep you updated, too.

syzop

2003-04-15 00:57

administrator   ~0002329

I've also enabled it in my CVS windows builds since I'm assuming it's (almost) stable now ;P.

AI

2003-04-16 01:47

reporter   ~0002349

So far so good, running for the last 34-35 hours with no trouble, I ll test it on Thursday on our main server and see how it goes with a heavier load of users. I personally want to thank Stskeeps, Codemastr, Syzop and the whole UnrealIRCd team for this feature, it really helps a lot to stop this script kiddies, We who use UnrealIRCd really do appreciate all of your effort and hard work.

codemastr

2003-04-16 18:57

reporter   ~0002364

Well since you've had it running this long with no problems, I assume it is fixed. If it does wind up crashing, just open up a new report.

Issue History

Date Modified Username Field Change
2003-04-10 12:53 Ravage Note Added: 0002202
2003-04-10 13:18 syzop Note Added: 0002206
2003-04-10 13:34 Ravage Note Added: 0002207
2003-04-10 14:34 syzop Note Added: 0002210
2003-04-10 14:41 Ravage Note Added: 0002211
2003-04-10 15:12 syzop Note Added: 0002217
2003-04-10 15:13 syzop Note Edited: 0002217
2003-04-10 21:08 codemastr Note Added: 0002229
2003-04-12 20:23 codemastr Note Added: 0002295
2003-04-14 12:59 AI Note Added: 0002312
2003-04-14 13:02 AI Note Edited: 0002312
2003-04-14 13:13 syzop Note Added: 0002313
2003-04-14 13:20 AI Note Added: 0002314
2003-04-14 13:27 syzop Note Added: 0002315
2003-04-14 23:03 AI Note Added: 0002321
2003-04-14 23:55 Ravage Note Added: 0002327
2003-04-15 00:57 syzop Note Added: 0002329
2003-04-16 01:47 AI Note Added: 0002349
2003-04-16 18:57 codemastr Status new => resolved
2003-04-16 18:57 codemastr Resolution open => fixed
2003-04-16 18:57 codemastr Assigned To => codemastr
2003-04-16 18:57 codemastr Note Added: 0002364
2003-11-20 19:46 syzop Status resolved => closed