I've been using jedie's python ping
implementation on Windows. I could be wrong, but when pinging two computers (A and B) from separate threads, ping will return the first ping it receives, regardless of source.
Since it could be an issue with jedie's fork, I reverted to the previous version. (This is the version I'm going to explore below)
I added in a line of code in receive_one_ping
: (Line 134 or similar)
recPacket, addr = my_socket.recvfrom(1024) # Existing line
print "dest: {}, recv addr: {}.".format(dest_addr, addr) # New line
This allows us to see the address of the ping we're receiving. (Should be same as the destination IP, right?)
Testing:
ping1() pings a known offline IP (1.2.3.4),
ping2() pings a known online IP (192.168.1.1 - my router)
>>> from ping import do_one
>>> def ping1():
print "Offline:", do_one("1.2.3.4",1)
>>> ping1()
Offline: None
>>> def ping2():
print "Online:", do_one("192.168.1.1",1)
>>> ping2()
Online: dest: 192.168.1.1, recv addr: ('192.168.1.1', 0).
0.000403682590942
Now if we do them together: (Using Timer for simplicity)
>>> from threading import Timer
>>> t1 = Timer(1, ping1)
>>> t2 = Timer(1, ping2)
>>> t1.start(); t2.start()
>>> Offline:Online: dest: 192.168.1.1, recv addr: ('192.168.1.1', 0).dest: 1.2.3.4, recv addr: ('192.168.1.1', 0).
0.0004508952953870.000423517514093
It's a little mangled (due to print not working nicely with threading), so here it is a bit clearer:
>>> Online: dest: 192.168.1.1, recv addr: ('192.168.1.1', 0).
Offline:dest: 1.2.3.4, recv addr: ('192.168.1.1', 0). # this is the issue - I assume dest should be the same as recv address?
0.000450895295387
0.000423517514093
My questions:
Can anyone recreate this?
Should ping be behaving like this? I assume not.
Is there an existing ICMP ping for python that will not have this behaviour?
Alternatively, can you think of an easy fix - ie pollingreceive_one_ping
until our destination matches our receive address?
Edit: I've created an issue on the python-ping github page