bugs 0.17

Sedulus · Post by **Sedulus** » 2003-02-20 18:01

ACTION_STOP behaves as ACTION_HANDLED (yup, arne knows already)
getHubVersion() returns version,nil instead of hubname,version
non-allowed IP's pass by userConnected() and userDisconnected() while banned IP's do not... is this intended?
in dchpp.clientPrivateMessage( client, to, data ), data contains "[Rug.nl]Sedulus $<[Rug.nl]Sedulus> my message" instead of "<[Rug.nl]Sedulus> my message"

[edit: added 3,4]

Sedulus · Post by **Sedulus** » 2003-02-21 11:51

about 3,
okay.. nick validation takes places.. my bad :)

Sedulus · Post by **Sedulus** » 2003-02-21 21:50

that's odd..

sometimes they (disallowed IP's) do pass through userConnected/userDisconnected and sometimes they don't

who is responsible for the allow/ban lists, the core or opcom?
I do load luascript.so before opcom.so...

[edited]

Post by **arnetheduck** » 2003-02-24 09:47

The core...in the validatenick handling...but it sounds strange that they pass through all that...but now that I think about it, the disconnect is asynchronous to make sure that all data is sent to a client before disconnecting it (such as a kick message or ban reason). In this time, the client might already have queued some other work for dch++ that gets processed before the client is kicked...something to look into...

Sedulus · Post by **Sedulus** » 2003-02-25 17:10

disallowing an ip range which is a superset/subset of another range simply discards the command. adding a range does however work. now I know that calculating those things is annoying and possibly even ambiguous, so a simple NAK message would suffice =)
docs: clientValidateNick, still says HANDLED
the ACTION_VALIDATED could use a bit more explanation. the examples for clientValidateNick ("..the nick ban, hub full and ip allowed tests will be skipped.") were the only things I saw where I could produce any effects.

yakko · Post by **yakko** » 2003-02-26 17:30

There's still a problem with getting disconnected improperly (unplugged network cable in my case) and DCH++ not releasing the nick. It's been 12 hours so far for me and I'm still locked out. I'll have to restart the hub to get back in.

sandos · Post by **sandos** » 2003-02-26 20:05

yakko wrote:There's still a problem with getting disconnected improperly (unplugged network cable in my case) and DCH++ not releasing the nick. It's been 12 hours so far for me and I'm still locked out. I'll have to restart the hub to get back in.

Timeouts are non-existant (infinite) it seems. But this particular thing hasnt happened to me, rather it seems to me the hub disconnect the nick after some time of inactivity if theres a nickcollision, thats what happened atleast once for me atleast.

Post by **arnetheduck** » 2003-02-28 12:16

Actually, when there's a nick collision, it tries to send an empty command to the "old" connection to see if it's still alive...this should, in theory, close the connection if something goes wrong...but the windows version seems to have some problems closing connections every now and then, I'm looking into it...

Sedulus · Post by **Sedulus** » 2003-03-02 22:54

hmz.. kick+banip just resulted in this:
138.48.4.138 (0:00:29:04): You were kicked...
138.48.4.138 (1:00:15:49): cya when your share is big enough, part II, with more blood, more sensation, more bullets... and, above all, longer kicktime / simsity4 in/uitgepakt, totale share net 12gb /sed

now that can't be right... I'll see if I can reproduce that.

Sedulus · Post by **Sedulus** » 2003-03-02 23:00

okay, easily reproducible. just +banip however many ip's you want. description may be the same even.
luckily the magic 0 seconds removes all at once.

Post by **arnetheduck** » 2003-03-03 12:27

Yes, same / overlapping range with different time is considered a separate ban...perhaps I should make a special case for exact range matches (such as a single ip is...)?

DC++

bugs 0.17

bugs 0.17

Who is online