If you are having problems connecting due to ping timeouts ?

These are old archives. They are kept for historic purposes only.
Post Reply
blax

If you are having problems connecting due to ping timeouts ?

Post by blax » Mon Apr 10, 2006 12:07 pm

hey guys i realy need help with this i know its not that important but iv been searching how to remove :

*** If you are having problems connecting due to ping timeouts, please type /quote pong 50CF4C86 or /raw pong 50CF4C86 now.

and i cant figure it out ....

help pls . ;]

thx

Stealth
Head of Support
Posts: 2086
Joined: Tue Jun 15, 2004 8:50 pm
Location: Chino Hills, CA, US
Contact:

Post by Stealth » Mon Apr 10, 2006 12:55 pm

If you are on *nix:
Recompile Unreal, and in ./Config answer no to the question that asks about NoSpoof protection.

If you are on Windows:
It is there for your protection, live with it.

smirl.reverend

Post by smirl.reverend » Fri May 12, 2006 11:14 pm

Stealth wrote:If you are on *nix:
Recompile Unreal, and in ./Config answer no to the question that asks about NoSpoof protection.

If you are on Windows:
It is there for your protection, live with it.
We just upgraded our entire network from like 6 unix servers to 1 windows server 2003 (consolidated web/email/ftp/irc). Our entire migration was well planned and went very very smoothly, Except for this one thing. We are now using the windows version of Unreal, and we get this message Stealth is talking about when we try to connect. Our previous server must have been built with that NoSpoof option off.

The big problem is that we write software that uses IRC to verify the CD-key/user licenses and the software is not setup to respond to PINGs unless it's from the server and not this random hex digits...

So my software is not compatible with the windows version of unreal because of this... Please is there anyway I can disable this, at all in the windows version? If not, we've already gotten rid of our old servers and I would need to setup a new one just for UnrealIRC... I'd really prefer not to do that. Please help.

Stealth
Head of Support
Posts: 2086
Joined: Tue Jun 15, 2004 8:50 pm
Location: Chino Hills, CA, US
Contact:

Post by Stealth » Sat May 13, 2006 4:58 am

It seems to me, if you write the software, you should be able to write a simple reply...

Stskeeps
Former UnrealIRCd head coder
Posts: 23
Joined: Mon Mar 20, 2006 9:24 pm
Location: Hell, On, Earth

Post by Stskeeps » Sat May 13, 2006 3:04 pm

You could look into re-compiling the windows ircd yourself, there's plenty of guide and information about it. However, if your software doesn't understand simple PING/PONG, you should look into fixing it.

The reason nospoof is in, still, is not due to DNS stuff, but because it can stop a certain type of evil attack using HTTP POST (i've seen that cause a lot of shit in principle). We're sure if the client understands PING/PONG that it's a live client that understands the IRC protocol in the other end, and not a lame bot / web page / etc

Syzop
UnrealIRCd head coder
Posts: 1955
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Post by Syzop » Wed Aug 30, 2006 11:08 am

Call me crazy but I was walking through old posts.

The reason nospoof is there on windows is exactly against that.. against spoofing (IP spoofing, actually). Without it, one can spoof on Windows NT within seconds, and Windows 2000/XP within minutes (or at least, so it was in 2003/2004). Windows 2003 seems to have better randomness, and I wonder which patch added it in W2K/XP. I'm just saying that... until a few years ago, all windows versions could be spoofed in a matter of minutes. This is why we do not support disabling it.

There has been some discussion about disabling the message itself (but not the PING/PONG), but that's another thing :P.

Of course, seeing these new OS's having more secure[*] TCP ISN's... It's likely that we will revise our policy for, say, Unreal3.3*.

New faq item, just created: FAQ: Other - I want to get rid of this annoying connect message on windows / get rid of nospoof

[*] I'm not sure if sufficient research has been made into this. One could say - and rightfully so - that this isn't our thing. But given the impact and track record of MS TCP ISN randomness problems, it would be worth to look into ;p.

Post Reply