Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The <code>EAGAIN</code> error ( producing "Resource temporarily unavailable;" string) could be raised by the timeout of the receiving socket.</p> <p>Since you set just 10000 microseconds as read timeout (that's really short IMHO) with this line...</p> <pre><code>struct timeval tv; tv.tv_sec = 0; tv.tv_usec = 10000; setsockopt(recv_sock, SOL_SOCKET, SO_RCVTIMEO, (char *)&amp;tv,sizeof(struct timeval)); </code></pre> <p>... it's possibile that the longer the way (i mean the number of router you have to pass through), the more chance you have to incour in this situation.</p> <p>Try to raise timeout value and let us know if it got better.</p> <p><strong>EDIT</strong></p> <p>I tried the source code under linux and i noticed two kind of problems.</p> <ul> <li>As mentioned above: Timeouts</li> <li>Problem with the 80 port</li> </ul> <p>I just raised the timeout and used a port different than 80 (in my case i sent udp message to 40000 port) and i got back all the hops just like <code>traceroute</code> command.</p> <p>I'm not sure why this behaviour occour. Maybe some kind of <em>"possible malicious packet alarm"</em> gets triggered by the router that discards it</p> <p><strong>FURTHER EDIT</strong></p> <p>Look at this link: <a href="http://linux.die.net/man/8/traceroute" rel="nofollow">man traceroute</a></p> <p>In the <strong>List Of Available Methods</strong> section you can find many ways to achieve what you need. Your method is similar to the default one, stating:</p> <p><em>Probe packets are udp datagrams with so-called "unlikely" destination ports. The "unlikely" port of the first probe is 33434, then for each next probe it is incremented by one. Since the ports are expected to be unused, the destination host normally returns "icmp unreach port" as a final response. (<strong>Nobody knows what happens when some application listens for such ports, though</strong>).</em></p> <p>So, if you need to full emulate the behaviour of the common Linux traceroute you have to increase by 1 the destination port, everytime the TTL increase (or everytime you can't get a response IMHO)</p> <p>MAYBE, sometimes your command doesn't work on certain ports because the router is listening to the latter (as suggested by Linux manual and underlined in bold by me). </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload