View Issue Details

IDProjectCategoryView StatusLast Update
0002386unrealircdpublic2005-03-04 16:30
ReporterSolutechUK Assigned Tosyzop  
Status resolvedResolutionfixed 
PlatformWin32OSWin XP pro SP2OS VersionSP2
Product Version3.2.3 
Summary0002386: Squits Ircservices on join
DescriptionWhen launching the services package it joins and immediately squits with Software caused connection abort . And SQUIT Unknown error
Steps To ReproduceStart servcices as normal and it just wont stay in there .
Additional InformationTested the config on a 3.2.2b build and it sits pretty in there no probs . Go back to pre-1 and it squits immediately
TagsNo tags attached.
3rd party modulesNone



2005-03-04 15:32

reporter   ~0009403

What version of IRCServices? And are you sure it's configured for Unreal 3.2? Also, any messages in the services log would be helpful.


2005-03-04 15:40

reporter   ~0009404

Yup its configured fine . Set it up on 3.2.2b and runs without a hitch .I ported the config from my live box where its been running aok. Move the same config onto pre-1 and bam it squits on connect .I even chucked up an old 3.2.2b test install and it connected fine to that and was stable. Tested with irc services 45 and 48 (latest)Both were clean installs to test the beta with. Nothing in services log at all . It seems to squit it the second after it connects so ircservices doesnt even have time to process the log b4 it gets shutdown .


2005-03-04 16:00

administrator   ~0009407

hm, nothing in log and it squits... perhaps it crashes? or would something differently happen then? (I'm not familiar with w32.. eventlog? :P).


2005-03-04 16:00

reporter   ~0009408

The following quote is taken from the ircservice mailing list. I hope this helps you.

"Hello all

seem like Services does not start with new Unreal build, that support NICKCHARS feature.
here is services log:
[Mar 04 10:58:09.431373 2005] debug: Sent: PROTOCTL SJOIN SJOIN2 SJ3 NICKv2 VHP VL NOQUIT UMODE2 TOKEN NICKIP
[Mar 04 10:58:09.433700 2005] debug: Sent: PASS :**********

... more sends, SERVER, NICK other ...

[Mar 04 10:58:09.458010 2005] debug: Received: NOTICE AUTH :*** Looking up your hostname...
[Mar 04 10:58:09.460022 2005] debug: Received: NOTICE AUTH :*** Found your hostname (cached)
[Mar 04 10:58:09.531932 2005] debug: Received: PROTOCTL NICKCHARS=
[Mar 04 10:58:09.540767 2005] debug: Sent: ERROR :Need NICKv2 protocol
[Mar 04 10:58:09.543939 2005] Remote server doesn't support NICKv2"


2005-03-04 16:04

administrator   ~0009409

[oh you got a useful log? scratch my previous bugnote then]

Oh... yeah Unreal now sends 2 PROTOCTL's to a server.. because I think we were aproaching (or hitting) the MAXPARA limit and I wanted to be safe with that AND the "512" buffer limit. But... that wouldn't be illegal, eh codemastr? It's nowhere stated at least, and it seems logical to allow multiple PROTOCTLS :)

Anyway, what I could do is just reverse the order: send most protoctls first, and then the NICKCHARS= one after that :).. Although that might not fix the ircservices issue, I don't know.


2005-03-04 16:08

reporter   ~0009410

[Fri Mar 04 19:29:15 2005] - SERVER
[Fri Mar 04 19:29:15 2005] - Lost connection to[]:Software caused connection abort

Thats from ircd.log services.log is blank .

No mention of the error on the ircservices list which they say as its based on a cvs and not an official build they wont even look at yet .


2005-03-04 16:10

reporter   ~0009411


mayby should have gotten this into also :)
Not me that is testing this I saw the bug and Im on the ircservice mailing list so I thought I share the info.

This was also in the mail:

"and code from Unreal sources (send_proto procedure, s_serv file):
void send_proto(aClient *cptr, ConfigItem_link *aconf)
char buf[512];

    sendto_one(cptr, "PROTOCTL NICKCHARS=%s", langsinuse);

    sprintf(buf, "CHANMODES=%s%s,%s%s,%s%s,%s%s",
#ifdef ZIP_LINKS
    if (aconf->options & CONNECT_ZIP)
        sendto_one(cptr, "PROTOCTL %s ZIP %s", PROTOCTL_SERVER, buf);
    } else {
        sendto_one(cptr, "PROTOCTL %s %s", PROTOCTL_SERVER, buf);
#ifdef ZIP_LINKS
... more code ...

Server always send first PROTOCTL NICKCHARS, therefor services crashed to start.

I just tested, moved NICKCHARS after "normal" PROTOCTL... and services doesn`t start again, it crashed on PROTOCTL NICKCHARS, because no NICKv2 in this PROTOCTL directive."


2005-03-04 16:23

administrator   ~0009412

heh too bad :p.

While, when I carefully look, I think merging them in PROTOCTL would not cause any problem (enough room), one might argue that merging them to fix this problem is only moving the problem ahead (or however you say that in english).. there will be a day, probably not too far from now, that we might need multiple PROTOCTL lines (eg: if just 1 or 2 tokens are added, or if we add more languages that can be combined), so I'm not entirely sure what to do :p.


2005-03-04 16:26

reporter   ~0009413

Talk nicly to Andrew Church?


2005-03-04 16:30

administrator   ~0009414

Last edited: 2005-03-04 16:32

Just merged PROTOCTLS for now, I'll see if we can have a word with our services friends another time when we really need it -- I didn't think they would be processing PROTOCTLs in such an 'old' way :).

Thanks for the report.

Issue History

Date Modified Username Field Change
2005-03-04 15:25 SolutechUK New Issue
2005-03-04 15:25 SolutechUK 3rd party modules => None
2005-03-04 15:32 codemastr Note Added: 0009403
2005-03-04 15:40 SolutechUK Note Added: 0009404
2005-03-04 16:00 syzop Note Added: 0009407
2005-03-04 16:00 psadi Note Added: 0009408
2005-03-04 16:04 syzop Note Added: 0009409
2005-03-04 16:08 SolutechUK Note Added: 0009410
2005-03-04 16:10 psadi Note Added: 0009411
2005-03-04 16:23 syzop Note Added: 0009412
2005-03-04 16:26 psadi Note Added: 0009413
2005-03-04 16:30 syzop Status new => resolved
2005-03-04 16:30 syzop Resolution open => fixed
2005-03-04 16:30 syzop Assigned To => syzop
2005-03-04 16:30 syzop Note Added: 0009414
2005-03-04 16:32 syzop Note Edited: 0009414