#38 Some Bugs and minor flaws and a suggestion :)

[Anonymous]

Hiho :)
I've tested your IRCd for some days now and it seems
totally stable, no crashs, nothing like that :)
Nevertheless, I found some bugs/flaws:

1. Flaw: MODEline for Users is parsed even if mode is
already set (no real bug, but it would look better if it'd
just ignore it)
----------------------------
/mode \dev\null -x
27/08/03 [13:16:59] * \dev\null sets mode: -x
/mode \dev\null +x
27/08/03 [13:17:25] * \dev\null sets mode: +x
/mode \dev\null +x
27/08/03 [13:17:26] * \dev\null sets mode: +
----------------------------

2. Flaw: Chanserv sends incorrect Notice
----------------------------
27/08/03 [04:02:54] -> *Chanserv* register #moo
\dev\null
27/08/03 [04:02:54] Ť127.0.0.1ť *** GlobOps --
\dev\null (null@192.168.0.5) has successfully registered
#moo
27/08/03 [04:02:54] Ť127.0.0.1ť Successfully registered
channel: #moo
27/08/03 [04:02:54] Ť127.0.0.1ť register -- Need more
parameters
----------------------------

3. Flaw: Rehash doubles up
----------------------------
27/08/03 [13:05:37] Ť127.0.0.1ť *** LocOps --
[\dev\null (null@localhost)] has rehashed the ircd.conf
file
27/08/03 [13:05:37] Ť127.0.0.1ť *** LocOps -- Rehash
complete, 0 users dropped due to new conf file
27/08/03 [13:05:37] Ť127.0.0.1ť *** LocOps --
Collecting Garbage.....
27/08/03 [13:05:37] Ť127.0.0.1ť *** LocOps --
Successfully rehashed and relogged on local clients
27/08/03 [13:05:37] Ť127.0.0.1ť *** LocOps -- Rehash
complete, 0 users dropped due to new conf file
27/08/03 [13:05:37] Ť127.0.0.1ť *** LocOps --
Collecting Garbage.....
27/08/03 [13:05:37] Ť127.0.0.1ť *** LocOps --
Successfully rehashed and relogged on local clients
----------------------------

4. Bug: Services die/crash after /rehash .
It seems to happen fairly random, sometimes I can
rehash 10 times in a row without crashing the services (I
know, no one would do something like this, but it was a
boring night ;P), sometimes they crash after a
single /rehash (I testet it with 4 Installations of your ircd
on 4 Systems (see systems at the end of this post))

5. Bug: Channel PRIVMSGs impossible

Sometimes after a /rehash you can't PRIVMSG Channels
anymore, you can NOTICE, but not PRIVMSG and it looks
like they would be +m (without the flag set) but no one,
not even Chanops or Opers, can msg the chan.

27/08/03 [14:09:52] <@\dev\null> moo?
#moo Cannot send to channel

6. Improvment Ideas :)

6.1 Services
In my opinion the services should be designed to be
(virtualy) leafs (i.e. a C: and a U:Line)
It would improve comfort (because you could /squit
them if you want) and the fixing of bugs (i.e. if one of
them crashs)

6.2 Override Channelmodes
In my opinion, Opers (at least +AN's) should be able to
override +r Flags (while registring channels) and
Password requirements on a Channel drop. I think opers
should also be able to override +b of their hostmask, to
join Channels with keys, with +i, with limit, etc. (maybe
a new Flag, like asuka's +kX?)

Summary:
A very, very nice Win32 IRCd and I know it's in
development so don't flame me to the bones that most
of the stuff I mention here is bugfixed soon, I know :D

regards, \dev\null - null.device@r00tb0x.org

Systems:

Cerberus
1000 Mhz Athlon Tbird
512 Mb SD-RAM
Windows 2000 SP 4

Soulfly
1200 Mhz Athlon TBird
512 Mb SD-RAM
Windows XP SP1

Occulus
3000 Mhz P4
1536 Mb DDR-RAM
Windows 2003 Server

NetCat
800 Mhz Athlon
128 Mb SD-RAM
Windows 2000 Sp 3

[Dennis Fisch]

Logged In: YES
user_id=602919

Hello,

Thanks a great deal for your bug submission!

1st: well, it's not a real bug, but i consider it a protocol
breach which in my opinion is just as bad.

2nd: I will have a look at that, for some reason i haven#t had
this problem yet, i do however know that i must write
documentation files for the services. right now every error
that happens due to not enough or invalid parameters is
reported with
[servicename] [command name] " - need more parameters"
which is pretty poor if you ask me :)

3rd: I am aware of this problem, but i wasnt able to find it's
cause yet. I think this problem is resolved in the latest (not
yet released) version.

4th: I wasnt aware of this critical one yet, but i'm sure this
also will be resolved when the new versions will be released.

5th: well, the same as above applies to this one ;)

6th:

a) the services were initially designed in that fashion but i
also intenionally left the clientside in because it would have
been a hassle to remove it and i also had lots of people here
that just want to run a single server for their friends.

b) Hehe, want to have Oper godmode, eh? :)
Well, in feature releases this may be put into the server (as
special patches, or so). The main reason i don't like this one
100% is that it could be abused to invade a channels privacy.
Generally a channel belongs to the channel owner/operator
(s), and it's their sole responsibility to take care of the
channel. That means that if they dont you in, they just ban
you, no matter if you're an oper or whatever. If you seriously
MUST enter the channel you could use /SAMODE (syntax is
like /mode) to *force* settting/unsetting channel modes.

again, thanks alot for this report, i sure as hell will add these
to my todo list, also, thanks alot for your kind words about
the product,

Sincerely,
Dennis Fisch

[Nobody/Anonymous]

Logged In: NO

---------------------------
a) the services were initially designed in that fashion but i
also intenionally left the clientside in because it would have
been a hassle to remove it and i also had lots of people here
that just want to run a single server for their friends.
---------------------------

Agreed, for a single server/a simple LAN-Party Server it's
better the way it is but I'd be happy if you could implement
the C/N Version too :)

----------------------------------------
b) Hehe, want to have Oper godmode, eh? :)
Well, in feature releases this may be put into the server (as
special patches, or so). The main reason i don't like this one
100% is that it could be abused to invade a channels privacy.
Generally a channel belongs to the channel owner/operator
(s), and it's their sole responsibility to take care of the
channel. That means that if they dont you in, they just ban
you, no matter if you're an oper or whatever. If you seriously
MUST enter the channel you could use /SAMODE (syntax is
like /mode) to *force* settting/unsetting channel modes.
----------------------------------------

I don't think this should be avaiable to regular Opers (o) nor
to (A) Opers, at all (i.e. general opinion about asuka patch for
ircu) this should only be possible for assigned U:Lines (i.e. real
Service bots) and (for your ircd) for Root Administrators (AN) -
a RA should know what he's doing and should not abuse it, at
all.

Btw, /SAMODE #moo +b <mask> does not work, any idea why
(-b works)?

Servicecrash/Timeout Problem:
I'd suggest to lower the Timeout, currently the Services time
out after 1500 Seconds and (in my opinion) this is too long
because it could mean 25 Minutes without any services in the
network and no one would notice it.