We are dropping the TTL data during execution.

[l4m3rx]

We are dropping the TTL data during execution.

[EclectickMedia]

For my own software, it would be nice to be able to retrieve, and log the TTL information.

The TTL information is retrieved from the call to _recieve as iphTTL here: (d735df8)

146                                                                                 
147     recvTime, dataSize, iphSrcIP, icmpSeqNumber, iphTTL \                       
148         = _receive(mySocket, my_ID, timeout, ipv6)                              
149

And is only used in a print statement here: (d735df8)

164                                                                                 
165             if verbose:                                                         
166                 print("%d bytes from %s: icmp_seq=%d ttl=%d time=%.2f ms" % (   
167                       dataSize, host_addr, icmpSeqNumber, iphTTL, delay)        
168                       )                                                         
169       

My proposed change would be to extend the return statement for send_one by returning the results of the request as a tuple after the delay value:

return delay, (recvTime, dataSize, host_addr, icmpSeqNumber, iphTTL)

Not only does this allow developers to access the TTL information, but it allows them to access the information about each request response as it is recieved. For example, right now my code needs to log a time as to when single_ping completes executing, but this information is already stored with ping.single_ping.recvTime, and I need access to the TTL information that is stored at ping.single_ping.iphTTL. Previous iterations of my software used to just capture the STDOUT data and sift through it for the TTL, and I'd rather not have to do that again. This allows me to retrieve it naturally.

This way, our code can be refactored to just use single_ping()[0] to access the delay value.

[l4m3rx]

Got for it 👍

[l4m3rx]

We're displaying the actual TTL data

python ping.py 8.8.4.4

PYTHON PING 8.8.4.4 (8.8.4.4): 64 data bytes
64 bytes from 8.8.4.4: icmp_seq=0 ttl=61 time=3.92 ms
64 bytes from 8.8.4.4: icmp_seq=1 ttl=61 time=3.93 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=61 time=3.96 ms
^C
----8.8.4.4 PYTHON PING Statistics----
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip (ms) min/avg/max = 3.9/3.9/4.0

(Terminated with signal 2)

python ping.py 195.24.90.1
PYTHON PING 195.24.90.1 (195.24.90.1): 64 data bytes
64 bytes from 195.24.90.1: icmp_seq=0 ttl=64 time=0.19 ms
64 bytes from 195.24.90.1: icmp_seq=1 ttl=64 time=0.26 ms
----195.24.90.1 PYTHON PING Statistics----
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip (ms) min/avg/max = 0.2/0.2/0.3

[EclectickMedia]

We are displaying it, but we arent collecting the data into MStats.

TTL's can change over time.

Really, I just think single_ping should allow developers access to the data instead of just dropping it. It may not be useful for the end user, but it is useful for data tracking and network monitoring.

Maybe just add it to the return statement?

[l4m3rx]

Can you show an example of what you have in mind?