l4m3rx/python-ping

Pure Python2/3 ICMP ping implementation using raw sockets.

python-ping's Issues

Broadcast Pings do not appear to be working

I have not yet had a chance to test it on a different OS. But under Mac OS X 10.10.4, with stock python Python 2.7.6 (default, Sep 9 2014, 15:04:36)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin

I am unable to get broadcast pinging to acknowledge/display, the broadcasts from other systems.

For example, here is a standard broadcast ping:

nerv:~ Benjamin$ ping 192.168.1.255
PING 192.168.1.255 (192.168.1.255): 56 data bytes
64 bytes from 192.168.1.52: icmp_seq=0 ttl=64 time=0.077 ms
64 bytes from 192.168.1.38: icmp_seq=0 ttl=64 time=0.354 ms
64 bytes from 192.168.1.12: icmp_seq=0 ttl=64 time=0.520 ms
64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.551 ms
64 bytes from 192.168.1.3: icmp_seq=0 ttl=255 time=0.555 ms
64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=0.567 ms
64 bytes from 192.168.1.46: icmp_seq=0 ttl=64 time=1.976 ms
64 bytes from 192.168.1.25: icmp_seq=0 ttl=64 time=2.707 ms
64 bytes from 192.168.1.29: icmp_seq=0 ttl=64 time=206.287 ms
^C
--- 192.168.1.255 ping statistics ---
1 packets transmitted, 1 packets received, +8 duplicates, 0.0% packet loss
round-trip min/avg/max/stddev = 0.077/23.733/206.287/64.548 ms

Here is the results using python-ping:

nerv:python-ping-master Benjamin$ sudo python ping.py 192.168.1.255

PYTHON PING 192.168.1.255 (192.168.1.255): 64 data bytes
64 bytes from 192.168.1.52: icmp_seq=0 ttl=64 time=0 ms
64 bytes from 192.168.1.52: icmp_seq=1 ttl=64 time=0 ms
64 bytes from 192.168.1.52: icmp_seq=2 ttl=64 time=0 ms

----192.168.1.255 PYTHON PING Statistics----
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip (ms) min/avg/max = 0/0.1/0

The only replies that are being returned, are from the host computer that is running the ping.

I have glanced through the code, and don't see anything obvious...

The current experimental generator functionality breaks myStats.

Description

The iteration of the master branchat db9553f breaks the myStats functionality when the generators are exited via a keyboard interrupt (see the execution snippet).

I haven't looked to far into it, and will move to that next, but the commit at db9553f is likely fine to be pulled to the repository. This would allow for cleaner repository history via the branch and pull idiom.

If this issue is not overly concerning, the afore mentioned commit can be pulled.

Bugged Execution Snippet

$ sudo python3 ping.py -T
Running PYTHON PING test case.

PYTHON PING 127.0.0.1 (127.0.0.1): 64 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.06 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.12 ms
^C
----0.0.0.0 PYTHON PING Statistics----
0 packets transmitted, 0 packets received, 100.0% packet loss


(Terminated with signal 2)

What should be collected

$ sudo python3 ping.py -T
Running PYTHON PING test case.

PYTHON PING 127.0.0.1 (127.0.0.1): 64 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.06 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.12 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.11 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.11 ms

----127.0.0.1 PYTHON PING Statistics----
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip (ms)  min/avg/max = 0/0.1/0


PYTHON PING 8.8.8.8 (8.8.8.8): 64 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=46.63 ms
^C
----0.0.0.0 PYTHON PING Statistics----
0 packets transmitted, 0 packets received, 100.0% packet loss

This even shows the broken functionality upon KeyboardInterrupt at the end of the snippet

do_one is named obtusely

Obtuse naming and the issues it causes.

Whether working with the software as a command line interface or via another software package, the naming scheme of do_one and send_one_ping cause a headache when trying to understand how to use the software.

This could be fixed easily if the private access functions (i.e send_one_ping and receive_one_ping) were refactored to include an underscore at the beginning of the name.

Naming considerations.

The names of send_one_ping and recieve_one_ping could likely be shortened to _send and _recieve respectively. The fact that more public access functions imply that they are or could be used for more than one ping sequence allows them to be shortened to simply ping.

There is a set of logic in single_ping that potentially blocks out ipv6 decoding

The logic on these lines is potentially blocked by the kwarg quiet on this line.

The logic is called upon the completion of the underlying call to _recieve, and is meant to properly decode IPv6 data that was received, if IPv6 is enabled.

This kwarg seems to be replaced by verbose and is only used in the following locations:

1. The call described above,
2. This line, which potentially breaks the verbosity flag on timed out requests,
3. And finally, one of two remaining uses of the quiet flag.

These calls are even hardcoded to True in either use case, which is silly if there is a globally set verbosity flag.

Python 2.7 spits out a traceback on [Error 65]

Bug description

The current iteration of master (#15) does not operate the same as Python 3.x. See the Execution Snippets below.

Is this intentional? A try except block may fix the issue.

Python 2.7 Execution Snippet

$ sudo python2 ping.py -T
Running PYTHON PING test case.

PYTHON PING 127.0.0.1 (127.0.0.1): 64 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.08 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.12 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.12 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.12 ms

----127.0.0.1 PYTHON PING Statistics----
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip (ms)  min/avg/max = 0/0.1/0


PYTHON PING 8.8.8.8 (8.8.8.8): 64 data bytes
Traceback (most recent call last):
  File "ping.py", line 456, in <module>
    for val in verbose_ping("8.8.8.8"):
  File "ping.py", line 364, in verbose_ping
    numDataBytes, ipv6=ipv6, myStats=myStats)
  File "ping.py", line 136, in single_ping
    sentTime = _send(mySocket, destIP, my_ID, mySeqNumber, numDataBytes, ipv6)
  File "ping.py", line 235, in _send
    mySocket.sendto(packet, (destIP, 1))  # Port number is irrelevant
socket.error: [Errno 65] No route to host

Python 3.x (3.5.2) Execution Snippet

$ sudo python3 ping.py -T
Running PYTHON PING test case.

PYTHON PING 127.0.0.1 (127.0.0.1): 64 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.06 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.13 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.10 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.09 ms

----127.0.0.1 PYTHON PING Statistics----
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip (ms)  min/avg/max = 0/0.1/0


PYTHON PING 8.8.8.8 (8.8.8.8): 64 data bytes
General failure ([Errno 65] No route to host)
General failure ([Errno 65] No route to host)
General failure ([Errno 65] No route to host)
General failure ([Errno 65] No route to host)

----8.8.8.8 PYTHON PING Statistics----
0 packets transmitted, 0 packets received, 100.0% packet loss

... Continues with the rest of the if __name__ == '__main__' test block ...

Should we submit a pull to samuel/python-ping?

This repo's base is horribly out of date.

This software seems to be the most recently, and heavily maintained branch of the software.

Is there any reason to not notify the base maintainer of new code?

It would not only expand the current collaborators list, but it would allow this repository more hits via github's search.

Needs more 3.6 compatibility

Frawst#3553

Doesn't work anymore on Windows

Python 2.7 on Windows:

  File "ping4.py", line 338, in do_one
    host_addr = socket.inet_ntop(socket.AF_INET, struct.pack("!I", iphSrcIP))
AttributeError: 'module' object has no attribute 'inet_ntop'

The current license has outdated information

This line has an outdated URL.

Are we able to change the license?

quiet and verbose_ping cannot ping continuously

Preamble

The current iteration of the functions quiet_ping and verbose_ping do not allow for continuous ping requesting due to their current for i in range(x) structure.

The current iteration simply counts down from the kwarg count, which no matter how theoretically large of a number we supply, will never achieve the necessary functionality.

Even if we were to provide a number at the maximum of integer size, it would present a few unnecessary behaviours:

1. An unnecessarily large number inherently takes up more memory than it is worth.
2. We could even need to go so far as to determine wether to provide a 32bit max or a 64bit maximum integer.

Solution Number 1

We could potentially solve the problem by simply providing a generator that continuously spits out numbers for range to consume.

• I feel that this could present more complex code than is necessary to achieve the functionality we are looking for. Consider the following code as an example generator object:

def gen():
    i = 0

    while 1:  # Continuously loop
        i += 1
        yield i

• Unless we reset the number, this would still result in extremely large numbers and run into complication 1.
  • Reseting the number sequence could potentially cause strange behaviour in range.

Solution Number 2

We could use an if else block to determine whether to use the current for i in range(x) behaviour or use a while loop to continuously request pings.
-This could run into issues meshing with other frameworks due to the nature of the while loop not relinquishing control.

Solution Number 3 - A More Elegant Solution

Converting the quiet and verbose_ping functions to generators would allow us to use a for loop to infinitely generate ping statistics.

This can be achieved by placing the functions in a while 1 loop with an exit clause checking for max iterations completion, and a yield after every successful call to do_one.

The calling code/function could then call the function in the following manner:

for results in verbose_ping():
    pass

Summary (TL;DR)

The current implementation of quiet and verbose_ping does not allow truelly endless pinging (for those who really like to collect statistics), and there are a couple ways we could get that done.

I am not sure which way to proceed, but will likely go with Solution Number 3

--Ari

How to hide 'Request timed out' message when calling quiet_ping() ?

quiet_ping() function is not really quite =) it prints 'Request timed out' message.
Is it possible to hide them when calling quiet_ping() but don't do it verbose_ping() ?

The current repository name breaks python import structures in python3 and above

The repositories use of a - in the name makes the user walk through additional actions to allow the repo to be imported. Forcing them to remove the - from the resulting folder of a git clone.

For example:
Performing git clone https://github.com/l4m3rx/python-ping.git, then running the following breaks the import structure.

Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import python-ping
  File "<stdin>", line 1
    import python-ping
                 ^
SyntaxError: invalid syntax

Renaming the repo would fix this issue.

Even if we don't rename the repo, attention should be drawn to this flaw in the Readme.

quiet_ping() loops

quiet_ping() function cannot end.

Running

list(ping.quiet_ping('google.com', timeout=3000, count=3, numDataBytes=1300))

never exits.

single_ping blocks threading.Thread.join

When using single_ping under a thread in the attached example usage (initial wrapper that is instantiated at self.ping_generator, access function, thread declaration), when a call is made to threading.Thread.join, single_ping blocks the call and continues to execute without end.

This is a fatal flaw with our software that needs to be fixed.

I am working with wrapping this software into a Kivy application to display ping information as it comes in on a graph (the main branch which works fine, for reference). Kivy needs to maintain control, and any function longer than O(1) causes frames to be dropped and a decrease in performance. Thus, I see only two solutions:

1. Run _send and _recieve individually, which could cause lost packets.

This goes against the current design philosophy of this software, which provides single_ping as a higher level access function than _send and _recieve individually

2. Execute the access function in my software under a thread.

Obviously, one of those two would be much easier than the other, and it frustrates me to no end that our software breaks python's threading functionality.

It would seem to be the call to _recieve within single_ping that blocks the threading.Thread.join functionality, specifically because of the while 1: and select calls.

We are dropping the TTL data during execution.

Why aren't we collecting data about the TTL.

Seems to me during single_ping's runtime it would only take an extra line to calculate an average TTL.

TTL's are useful to track to monitor packet forwarding in large networks.