Author Topic: Clients with buggy supports block (Read 15658 times)

PPK · « **on:** December 16, 2007, 01:49:15 am »

-- Block of clients with buggy supports
-- Created for fun and to force client creators to fix bug caused by bad quack coding.

function SupportsArrival(curUser, sData)
    if string.sub(sData, string.len(sData)-1, string.len(sData)-1) == " " then
        Core.SendToUser(curUser, "<"..Core.GetHubSecAlias().."> Your client is buggy and sent bad $Supports command.")
        Core.SendToUser(curUser, "<"..Core.GetHubSecAlias().."> Please report that bug to your client creator and wait for fixed version.")
        Core.SendToUser(curUser, "<"..Core.GetHubSecAlias().."> If you don't want to wait or your client creator is not able to fix that bug then please change client.")
	Core.Disconnect(curUser)
    end
end

bastya_elvtars · « **Reply #1 on:** December 16, 2007, 01:06:11 pm »

Yes, but not in a hardcoded way. Or at least not for the first time.

CrazyGuy · « **Reply #2 on:** December 16, 2007, 01:48:55 pm »

May i suggest a Core.Kick instead of a Core.Disconnect to avoid hammering ?

bastya_elvtars · « **Reply #3 on:** December 16, 2007, 02:01:34 pm »

Quote from: CrazyGuy on December 16, 2007, 01:48:55 pm

May i suggest a Core.Kick instead of a Core.Disconnect to avoid hammering ?

I object; hammering will lead to autoban anyway. And kicking would disappoint the user too much IMHO.

CrazyGuy · « **Reply #4 on:** December 16, 2007, 07:33:02 pm »

Quote from: bastya_elvtars on December 16, 2007, 02:01:34 pm

I object; hammering will lead to autoban anyway. And kicking would disappoint the user too much IMHO.

i don't really see why kicking would disappoint more than an autoban for hammering

TwîsTèd-dèvîl · « **Reply #5 on:** December 16, 2007, 07:35:43 pm »

If kicking doesnt that mean user has to be in hub ... therefore defeting the object

ruler · « **Reply #6 on:** December 16, 2007, 10:16:14 pm »

i voted 'yes' but thats because i'd like to see the back of all dodgy clients

TTB · « **Reply #7 on:** December 17, 2007, 10:08:01 am »

Voted: Only as option with default enabled.

I don't know which clients has buggy supports. The hub-runner should manage it if needed, imo.

Thor · « **Reply #8 on:** December 17, 2007, 12:58:37 pm »

The only one client which sends corrupted $Supports string is rmDC.

PPK · « **Reply #9 on:** December 17, 2007, 01:09:32 pm »

No, it is not only one client

But yes this script block rmDC++ too

PPK · « **Reply #10 on:** January 05, 2008, 10:59:00 pm »

36.8% for yes, 36.8% for option with enabled, 26.3% for option with disabled.

Who really test that script ? Why nobody complains that this script blocking DC++ and most of DC++ modifications ? Who really want to block them ?

Mutor · « **Reply #11 on:** January 05, 2008, 11:17:08 pm »

Well the poll itself has little to do with your script.
Asking if users want bad supports blocked does not
infer you want them to test your script.

I'm not sure why blocking this is even a question.
Do you allow bad client tags? Do you allow invalid MyINFO?
Did you put either of those to a vote? Not AFAIK, but
you do have an option to allow clients without tags.
So in keeping with tradition, provide it as an option.

PPK · « **Reply #12 on:** January 05, 2008, 11:39:05 pm »

Tag is optional because it is not part of protocol, it is ugly description hack by quack.

This block is question, because that bug is in most actually used clients

CrazyGuy · « **Reply #13 on:** January 06, 2008, 11:07:17 am »

Quote from: PPK on January 05, 2008, 10:59:00 pm

36.8% for yes, 36.8% for option with enabled, 26.3% for option with disabled.

Who really test that script ? Why nobody complains that this script blocking DC++ and most of DC++ modifications ? Who really want to block them ?

I haven't tested that script, but I can see pretty clearly what it does

As Mutor said, the question asked in the poll is taken as stand-alone.

I would encourage such a block as default if it wasn't that it would mean so many current clients will not be allowed in because of it

Therefor I'm sticking with my vote of making it optional

PPK · « **Reply #14 on:** July 04, 2008, 04:06:51 pm »

Voting locked, will be implemented in next PtokaX version as option with default enabled

CrazyGuy · « **Reply #15 on:** July 04, 2008, 09:20:07 pm »

good

ATAG · « **Reply #16 on:** October 12, 2008, 11:57:22 pm »

Quote from: PPK on July 04, 2008, 04:06:51 pm

Voting locked, will be implemented in next PtokaX version as option with default enabled

How can i disable it?

Mutor · « **Reply #17 on:** October 13, 2008, 12:45:34 am »

There will be an option for you to toggle once it's implemented.

First the horse, then the cart.

ATAG · « **Reply #18 on:** October 13, 2008, 01:09:16 am »

Then what is "Bad $Supports from <unknown> (xxx.xxx.xxx.xxx) - user closed." in the log?

Mutor · « **Reply #19 on:** October 13, 2008, 01:13:49 am »

Just what it seems. AFAIK, there is no option to enable/disable yet.
Correct me if I'm wrong. I can take it.

PPK · « **Reply #20 on:** October 13, 2008, 01:36:20 am »

Quote from: ATAG on October 13, 2008, 01:09:16 am

Then what is "Bad $Supports from <unknown> (xxx.xxx.xxx.xxx) - user closed." in the log?

That is rmDC++, client sending more buggy supports that this block will disallow

PPK · « **Reply #21 on:** November 19, 2011, 05:54:42 pm »

It is funny but dc++ devs again shown that they are bunch of idiots. Not only that they are not able to correctly code things as it is documented by them, but they are not able to fix bugs they created... https://answers.launchpad.net/dcplusplus/+question/179023

Mutor · « **Reply #22 on:** November 19, 2011, 08:32:16 pm »

Some things never change.

News:

Author Topic: Clients with buggy supports block (Read 15658 times)