[Cerowrt-devel] ping icmp ttl exceeded

Dave Taht dave.taht at gmail.com
Mon Feb 4 11:37:41 EST 2013

On Mon, Feb 4, 2013 at 6:17 AM, Maciej Soltysiak <maciej at soltysiak.com>wrote:

> On Mon, Feb 4, 2013 at 8:41 AM, Dave Taht <dave.taht at gmail.com> wrote:
>> Heh. I turned out I'd left mtr running in another window...
> Yeah, exactly. Decreasing TTLs suggest traceroute tools :-)

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

pdsh -a -l root 'fping -C 2 -q'

(which -a finds all routers in /etc/genders, and simultaneously as possible
executes the ping command)

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.

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)

The longest path through it:


(pdsh is also very useful for things like 'opkg update; opkg install
when a network gets this large and complex)

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.

> As Ketan noted, it's best to decode what's in the ICMP TTL exceeded
> payload to see what packet triggered this.
> traceroute uses ICMP ECHO REQUEST
> tracepath uses UDP
> 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)
> 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.
> Regards,
> Maciej

Dave Täht

Fixing bufferbloat with cerowrt:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20130204/ed609eb8/attachment-0002.html>

More information about the Cerowrt-devel mailing list