<br><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 6:17 AM, Maciej Soltysiak <span dir="ltr"><<a href="mailto:maciej@soltysiak.com" target="_blank">maciej@soltysiak.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Mon, Feb 4, 2013 at 8:41 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">Heh. I turned out I'd left mtr running in another window... </blockquote>
</div><div>Yeah, exactly. Decreasing TTLs suggest traceroute tools :-)</div></div></blockquote><div><br>Well in this case I've still been chasing the crc bug I'd encountered and some problems with the double nat I'm still dealing with. I'd got pdsh up and had been issuing commands like <br>
<br>pdsh -a -l root 'fping -C 2 -q 8.8.8.8'<br><br>(which -a finds all routers in /etc/genders, and simultaneously as possible executes the ping command)<br><br>So I thought maybe I'd done an infinite ping or there was a real routing problem for the 5 minutes after I'd written that email.<br>
<br>This btw, is so far as I know, is now the worlds most complex, meshed, and nfq_codeled wifi/ethernet network. snmp is up too, but I struggle to get useful information out of minstrel and codel's drop stats as yet. I think adding better kernel support for the latter would be nice (some sort of netlink message containing the dropped packet and why)<br>
<br>The longest path through it:<br><br><a href="http://pastebin.com/kWAXJS6d">http://pastebin.com/kWAXJS6d</a><br><br>(pdsh is also very useful for things like 'opkg update; opkg install something',<br>when a network gets this large and complex)<br>
<br>I can certainly see why being able to specify a route was very important in the early protocol design of the imps and ip, and am kind of sorry it proved problematic in terms of security.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div> </div>
<div>As Ketan noted, it's best to decode what's in the ICMP TTL exceeded payload to see what packet triggered this.</div>
<div> </div>
<div>traceroute uses ICMP ECHO REQUEST</div>
<div>tracepath uses UDP</div>
<div>tcptraceroute uses TCP SYN (this tools is actually usefull to check if your packets go different routes depending on the port they're going to, e.g. detecting a transparent proxy which shows up for port 80, but not for others)</div>


<div> </div>
<div>There are other tools which could be used to do the same with different types of packets, say, crafting a fake ICMP ECHO REPLY to see how good at being stateful are the firewalls on the path.</div>
<div> </div>
<div>Regards,</div>
<div>Maciej</div>
<div> </div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br><br>Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a>