problem with ping scripts with mirc?

[rosc2112]

Has anyone else come across a problem using a ping script to check an
mirc client? I've been using sir_fz's ping script, and have tried others that
use the same basic binds, and I've even looked at the traffic through
ethereal and my irc client. I don't see a reason why the ping script does
not obtain a reply from (some) mirc clients. My irc client (bitchx) can ping
these people and gets a reply, but the ping script does not?

This is basically sir_fz's script with some minor modifications I made:
(The script works, except for these few mirc clients)

Code: Select all

#########################################################################################################################################################
bind pub - .ping pub:ping
bind ctcr - PING ctcr:ping

proc pub:ping {nick uhost hand chan arg} {
global pingreq pingp pingchans
        if {[lsearch -exact $pingchans $chan] == -1} {
                puthelp "PRIVMSG $nick :ping disabled on $chan"
                return
        }
        set arg [string trim $arg]
        if {![info exists pingp($chan)]} { 
                set pingp($chan) 0 
        }
        utimer 2 [list incr pingp($chan) -1]
        if {[incr pingp($chan)] < 3} {
                if {[set targ [lindex [split $arg] 0]] == ""} {
                        putserv "PRIVMSG $chan :Use: .ping <nick> or .ping me"
                        return
                }
                if {([string equal -nocase "me" $targ] == 1)} {
                        putserv "PRIVMSG $nick :\001PING [clock clicks -milliseconds]\001"
                        set pingreq($nick) "$chan"
                        return
                }
                if {[onchan $targ $chan]} {
                        putserv "PRIVMSG $targ :\001PING [clock clicks -milliseconds]\001"
                        set pingreq($targ) "$chan"
                } else {
                        puthelp "PRIVMSG $chan :$targ is not in $chan."
                }
        }
}

proc ctcr:ping {nick uhost hand dest keyword arg} {
        global pingreq
        if {![info exists pingreq([set nnick $nick])]} {return}
        if {[string is integer [set reply [lindex [split $arg] 0]]]} {
                putserv "PRIVMSG $pingreq($nnick) :\[\002$nick\002 PING reply\]: [expr {abs([clock clicks -milliseconds] - $reply) / 1000.0}] seconds."
        }
        unset pingreq($nnick)
}

This is the responses I captured with ethereal and my irc client:

Code: Select all

Non-working response (doesnt work with script, but works with irc client)

[binary packet junk deleted]:user!~username@User1.users.undernet.org NOTICE rosc :PING 1157607381 537606

Working response from different mirc user:
[binary junk]:user2!~Foo@user2.users.undernet.org NOTICE rosc :PING 1157610199 651325

The only difference I see is in the binary junk which I assume is just the packet's header, which should not matter? Also, yes the mirc clients are receiving the ping request, I asked and they showed me the request that was sent.

Anyone have a clue for me? =)

[demond]

neither mIRC nor "windoze" have anything to do with your problem, your script is buggy

key values of Tcl's associative arrays are case-sensitive, therefore you won't get a response from nicks you typed not in their original case; fix the script to store the nick keys either in all lower- or uppercase

[rosc2112]

I had thought of the case, and tried it both as upper and lower (eg, Nick was Somenick, I tried both "Somenick" and "somenick") I also turned on raw logging and saw no reply.. And actually, just double checked, I have another bot on the channel called UnoGame2112, and if I run the ping script on it, I do get the ping reply in the log (but not the output in channel cos of the case-sensitive array, like you mentioned.)

<rosc> .ping unogame2112

[UnoGame2112(dcc)] [03:29] CTCP PING: -1940600381 from TheEntity (~TheEntity@TheEntity.users.undernet.org)

[theentity(dcc)] [03:29] CTCP reply PING: -1940600381 from UnoGame2112 (rosc2112@UnoGameBot.users.undernet.org) to TheEntity


I don't think I'll be able to figure out the problem without setting up a windows box of my own :/

[Alchera]

One also has to be very careful that an exploit isn't opened.