View Issue Details

IDProjectCategoryView StatusLast Update
0003018unrealircdpublic2006-11-25 10:54
ReporterMilliways Assigned Tosyzop  
Status resolvedResolutionfixed 
Platformi386OSlinuxOS Version2.6 something
Product Version3.2.5 
Fixed in Version3.2.6 
Summary0003018: Autoconnect flooding connections to hub
DescriptionWhen i enable autoconnect on leaf and it splits it starts to agressively connect to the hub, instead of the one connect every 100s as set in connfreq it does something like 100/s.
without autoconnect the leaf connects flawlessly
Steps To Reproduceactivating autoconnect
Additional InformationHub side configs:
leaf configs:
messages on autoconnect
that's only some of the messages, it fills up the scrollback buffer in notime

This has been looked at by several persons in #unreal-support without them being able to understand why this happens and i was told to file a bugreport
TagsNo tags attached.
3rd party modules


child of 0002936 resolvedsyzop 3.2.6 Release 



2006-08-05 13:11

administrator   ~0012157

I'll see if I can reproduce it here.

2006-08-05 13:55


bugtraq.txt (2,845 bytes)


2006-08-05 13:56

reporter   ~0012158

Seeing that the pastebin disappeared i put the same info in a text file, just took the linkblock for the leaf i tested with from the links.conf, all other are just the same.


2006-09-26 02:17

reporter   ~0012444

huh... where set::throttle ?
/* Throttling: this example sets a limit of 3 connections per 60s (per host). */
    throttle {
        connections 3;
        period 60s;

or it's different?


2006-09-27 00:49

reporter   ~0012447

Reply to Bock:
That is different, throttling is meant for users. connfreq is meant for servers


2006-09-27 08:15

administrator   ~0012449

It seems I cannot reproduce this issue.
I've tried your configuration (autoconnect, and your connfreq and pingfreq):
A) Connect server, tcpkill the connection, wait for reconnect
B) Connect server, halt the main server, wait for reconnect (from leaf) after the server doing a Ping timeout

Could you give me some more details:
1) When does the flood start? Immediately upon disconnect, or 100 seconds later (connfreq)? Is there any delay between the 1st connection attempt and the rest of the attempts?
2) Is it 100% reproducable?
3) What kind of serverlink breakage happens prior to the flood? Connection reset by peer? Ping timeout? Or does it happen with both?
4) This really is 3.2.5? Just asking again to be sure, because in 3.2.5 some major bugs got fixed with regards to this.

Feel free to mail these things to me privately at, for example a big log of what happens would be nice (rather than a snippet of 4 lines), particulary of the start of the flood (and not the middle of end), that could be helpful :).

Thanks in advance.


2006-10-15 14:04

reporter   ~0012487

Since this bug was filed we have moved the server onto another network but i see the same issues here too so i've disabled all autoconnects and made a small script to reconnect servers.
If it helps just get into contact with me and we can do some testing by linking a server i have to the network for tests.


2006-10-15 14:09

administrator   ~0012488

Last edited: 2006-10-15 14:13

Yeah, I would still be interested in the answer of the questions (and the log).

EDIT: FYI, I don't understand what I should do for you?


2006-10-28 19:01

reporter   ~0012528

I've sent an email to syzop with 2 seconds worth of connection notices after a netsplit we just had where the hub disconnected and the leafs reconnected automaticaly.
Hairy deal, several hundred lines of this:
[01:47:40] *** Notice -- Client connecting on port 6667: {T-L}darktrainer (java- [clients]
[01:48:12] *** Global -- Closing link: Write error: Connection reset by peer -[xx.xx.xx.xx]
[01:48:14] *** Notice -- Connection to[xx.xx.xx.xx] activated.
[01:48:14] *** Notice -- Client exiting: EvilRyuHayabusa (java-4b976@dialup- [Ping timeout]
[01:48:14] *** Notice -- Connection to[xx.xx.xx.xx] activated.
[01:48:14] *** Notice -- Connection to[xx.xx.xx.xx] activated.
[01:48:14] *** Notice -- Connection to[xx.xx.xx.xx] activated.
[01:48:14] *** Notice -- Connection to[xx.xx.xx.xx] activated.
[01:48:14] *** Notice -- Connection to[xx.xx.xx.xx] activated.
[01:48:14] *** Notice -- Connection to[xx.xx.xx.xx] activated.
[01:48:14] *** Notice -- (link) ZIPLink ->[@xx.xx.xx.xx.0]
[01:48:14] (link) ZIPLink ->[@]
[01:48:15] Lost connection to[xx.xx.xx.xx]:Connection reset by peer
[01:48:15] Lost connection to[xx.xx.xx.xx]:Connection reset by peer
[01:48:15] *** Notice -- Link[@xx.xx.xx.xx.0] cancelled, server
already exists from
[01:48:16] *** LocOps -- ERROR :from[xx.xx.xx.xx] -- Closing Link:
[] (Throttled: Reconnecting too fast) -Email for more
[01:48:16] *** LocOps -- ERROR :from[xx.xx.xx.xx] -- Closing Link:
[] (Throttled: Reconnecting too fast) -Email for more
[01:48:16] *** Notice -- Connection to[xx.xx.xx.xx] activated.
[01:48:16] *** LocOps -- Server[xx.xx.xx.xx] closed the connection
[01:48:16] *** LocOps -- Server[xx.xx.xx.xx] closed the connection
[01:48:16] *** Notice -- Connection to[xx.xx.xx.xx] activated.


2006-10-28 19:05

administrator   ~0012529

Thanks, received ;)


2006-10-28 19:07

reporter   ~0012530

if you want to i have a leaf connected to the network where this happens without any users on it that we can play around with if needed


2006-11-11 14:33

administrator   ~0012624

Sorry for not responding.

So me link a server onto the test network? Sounds good :)

Let me know the details at

I've dynamic IP, so for inbound you'll have to allow 82.157.*


2006-11-24 18:50

administrator   ~0012725

Server linked and idling now.. :P

How long does it usually happen till I can expect something to occur? couple of days?

I might as well fake a disconnect, though I don't think anything will happen.

(In fact I'll be surprised if anything will happen, but I'm hoping for it... since when I can reproduce it, then I can start working on fixing your problem ;p)


2006-11-25 10:47

administrator   ~0012728

Fixed in CVS of 32* and 33*, thanks :)

- Fixed bug where ommitting class::connfreq would not give a config error, and would
  cause a huge connection attempt flood when autoconnect was enabled. Reported by
  Milliways (0003018).


2006-11-25 10:54

administrator   ~0012729

fix-for-fix, realized that class::connfreq usually is not specified for client classes so now using a default instead of erroring. changelog changed to:

- Fixed bug where omitting class::connfreq would result in a huge connection attempt
  flood when autoconnect was enabled. We now set class::connfreq to 60 if it's not
  specified. Reported by Milliways (0003018).

Issue History

Date Modified Username Field Change
2006-08-05 12:15 Milliways New Issue
2006-08-05 13:11 syzop Note Added: 0012157
2006-08-05 13:11 syzop Assigned To => syzop
2006-08-05 13:11 syzop Status new => acknowledged
2006-08-05 13:55 Milliways File Added: bugtraq.txt
2006-08-05 13:56 Milliways Note Added: 0012158
2006-09-25 20:23 syzop Relationship added child of 0002936
2006-09-26 02:17 Bock Note Added: 0012444
2006-09-27 00:49 RandomNumber Note Added: 0012447
2006-09-27 08:15 syzop Note Added: 0012449
2006-10-15 14:04 Milliways Note Added: 0012487
2006-10-15 14:09 syzop Note Added: 0012488
2006-10-15 14:13 syzop Note Edited: 0012488
2006-10-28 19:01 Milliways Note Added: 0012528
2006-10-28 19:05 syzop Note Added: 0012529
2006-10-28 19:07 Milliways Note Added: 0012530
2006-11-11 14:33 syzop Note Added: 0012624
2006-11-24 18:50 syzop Note Added: 0012725
2006-11-25 10:47 syzop Status acknowledged => resolved
2006-11-25 10:47 syzop Fixed in Version => 3.2.6
2006-11-25 10:47 syzop Resolution open => fixed
2006-11-25 10:47 syzop Note Added: 0012728
2006-11-25 10:54 syzop Note Added: 0012729