View Issue Details

IDProjectCategoryView StatusLast Update
0002680unrealircdpublic2006-11-12 13:49
Reportersyzop Assigned Tosyzop  
PrioritynormalSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
OSANY (though mainly win32)OS Version- 
Product Version3.2.3 
Fixed in Version3.2.6 
Summary0002680: Remove "If you are having problems connecting due to ping timeouts" message
DescriptionRemove the "*** If you are having problems connecting due to ping timeouts, please type /quote pong B3DD35E or /raw pong B3DD35E now." alike message because it's outdated (it's common practice now on even some major nets) and thus only annoying. Even when getting such a message, stupid bot writers don't understand it, so it's hardly helpful for them either.

Keep the PING/PONG cookie anti-spoof protection itself of course, just remove the message.

Optionally, make it a configuration option to turn this message back on, but turn it off by default.
TagsNo tags attached.
3rd party modules

Activities

aquanight

2005-11-08 23:30

reporter   ~0010674

For some reason this reminds me of something somewhat like nospoof that I saw on a few efnet servers: if you didn't have an identd reply, they'd pass a pingcookie through figlet or something like that, send it to you a' la RPL_TEXT (usually ignored by bots I think?), and you had to /raw|/quote PONG back the cookie depicted - and you didn't get a PING for it! Was basically their way of putting a stop to some abusive bots that didn't have ident, etc because unless they somehow parse the figlet code or start guessing pongcookies they can't get in. I'm sure this little thing could be done in a module but like I said, I was just reminded of this wierdness and thought I'd mention it ;) .

As for what you said, yeah. In fact I have seen X billion people in #unreal-support ask how to remove that notice, and basically had to tell them they'd basically have to make their ircd less secure (read: switch off nospoof) to do it (especially @ Windows). Would be nice to just frag the notice but keep the pingcookies ;) .

Bergee

2005-11-10 15:58

reporter   ~0010686

I'd be all for removing this message as well. All I've seen it do these days is confuse users with poor connections into thinking they need to follow the instructions and then have them wonder why it isn't changing anything. :)

stskeeps

2005-11-11 03:01

reporter   ~0010694

I think we should better document it, the reason it is so, is that some clients only accept

PING :server.name

PONG :server.name

(since thats more sane understanding of IRC, since the prefix would be a server)

White_Magic

2005-11-15 08:20

reporter   ~0010745

yeah i agree with stskeep, better document it, howeve rhave the option to turn it off and on as well

syzop

2005-11-15 11:21

administrator   ~0010748

(well, of course I know why it originally is like that, that's why I don't even mention it)

Well, I don't agree :P. Let's put things in perspective...

PRO's for the message:
- some really old/odd clients might still work. Oh wait bots don't. But they get the 'type blabla message'.

CON's:
- It is confusing, like Bergee says... some users think they have to type it, some mail irc staff about the message (yes, really), etc.
- It is ugly
- Various people that write IRC clients don't even understand what they are doing wrong EVEN WITH THE MESSAGE. This is, because most of these self-made-stupid clients in fact DON'T PONG AT ALL, some don't even read network traffic (they then use stupid timers to evade pingpongs).
- It is outdated, various networks (including major nets) already require this (though they also have the notice).

We could, of course, try to find a compromise.
- If we get any incorrect PONG (with for example, the servername), print the message.
- If the connection times out when waiting for the pingcookie, print a message (and kill the connection).
But don't print the message in normal circumstances (unless the option to do so gets turned on, of course)

w00t

2005-11-15 17:42

reporter   ~0010749

I like both of the compromise options there.

o/t:
It would also be nice to see people actually following RFC spec on how to handle stuff.. (it's also a shiteload easier to just return a PONG on whatever the PING was, but eh)

syzop

2006-11-12 13:49

administrator   ~0012639

Fixed in CVS of 32* (.591) and 33* (.2296), part of mass-commit:
- Snomask N: Don't show nickchanges for U-lines, reported by seneces (0002636).
- Fixed set::dns::bind-ip directive seen as duplicate, reported by aegis (0003074).
- set::dns::* block is now no longer mandatory. All info has always been read from
  /etc/resolv.conf (*NIX) or the registry (Win32), and the set::dns block is ignored
  (except for set::dns::bind-ip, but that's a special case). Suggested by many including
  djGrrr to make things slightly more logical (0003019).
- As a consequence of the above, set::dns blocks were removed from doc/example*conf.
- Added two more characters to Catalan charset, reported by rmh (0002995).
- Added set::pingpong-warning [yes|no] which decides whether to send the "** If you are
  having problems connecting due to ping timeouts, please type /quote pong .." message
  to each client when NOSPOOF is enabled (usually on Win32). The default is NO.
  Previously this message was always sent if NOSPOOF was on, which often caused
  confusion among users. The message was intended for non-confirming clients, but these
  should be fixed by now, and those that were not fixed (self-made bots/etc) did often
  not understand the message anyway. Anyway, you can still turn it on ;). (0002680).

Issue History

Date Modified Username Field Change
2005-11-08 16:46 syzop New Issue
2005-11-08 16:46 syzop Description Updated
2005-11-08 23:30 aquanight Note Added: 0010674
2005-11-10 15:58 Bergee Note Added: 0010686
2005-11-11 03:01 stskeeps Note Added: 0010694
2005-11-15 08:20 White_Magic Note Added: 0010745
2005-11-15 11:21 syzop Note Added: 0010748
2005-11-15 17:42 w00t Note Added: 0010749
2006-11-12 13:49 syzop Status new => resolved
2006-11-12 13:49 syzop Fixed in Version => 3.2.6
2006-11-12 13:49 syzop Resolution open => fixed
2006-11-12 13:49 syzop Assigned To => syzop
2006-11-12 13:49 syzop Note Added: 0012639