[Cerowrt-devel] ping icmp ttl exceeded

[Cerowrt-devel] ping icmp ttl exceeded

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

I have been largely looking at packet captures for tcp streams. today I
noticed that I was oddly getting icmp ttl exceeded messages back on the
network from various devices on the path when I wasn't even pinging...

I have to admit parsing icmp is not in my skillset. Is there useful
information in the icmp messages in this capture?

http://snapon.lab.bufferbloat.net/~d/ttl_exceeded.cap

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 679 bytes --]

Re: [Cerowrt-devel] ping icmp ttl exceeded

[Ketan Kulkarni]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

Hi Dave,

The TTL is decremented by 1 on every router. If it reaches 0, the pkt
is dropped and ICMP ttl exceeded is sent to the sender with icmp body
= first few bytes of the packet which caused this error.
Looks like, for every new Echo Req, ip ttl is set to 1. The next
router decrements it and send ICMP ttl exceeded back.

So 172.20.26.17 send Echo Req to 172.20.0.1 with ttl=1.
172.20.26.1 (probably your next router) decrements and sends ICMP TTL
exceeded to 172.20.26.17 (probably your client)

For the next request, ttl=2 and this time 172.20.26.17 (next to next
router) send ttl exceeded.
This is happening till ttl=6 at which the Echo Req is successful.

Probably this is the behaviour of ping cmd used with -R (record route)
option enabled.

Attached jpg for reference.

-Ketan

On Mon, Feb 4, 2013 at 12:40 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I have been largely looking at packet captures for tcp streams. today I
> noticed that I was oddly getting icmp ttl exceeded messages back on the
> network from various devices on the path when I wasn't even pinging...
>
> I have to admit parsing icmp is not in my skillset. Is there useful
> information in the icmp messages in this capture?
>
> http://snapon.lab.bufferbloat.net/~d/ttl_exceeded.cap
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: icmp_ttl_exceed.JPG --]
[-- Type: image/jpeg, Size: 319527 bytes --]

Re: [Cerowrt-devel] ping icmp ttl exceeded

[Ketan Kulkarni]

Sorry to send it again, as the list rejected the attachment
(attachment removed in this one)

Hi Dave,

The TTL is decremented by 1 on every router. If it reaches 0, the pkt
is dropped and ICMP ttl exceeded is sent to the sender with icmp body
= first few bytes of the packet which caused this error.
Looks like, for every new Echo Req, ip ttl is set to 1. The next
router decrements it and send ICMP ttl exceeded back.

So 172.20.26.17 send Echo Req to 172.20.0.1 with ttl=1.
172.20.26.1 (probably your next router) decrements and sends ICMP TTL
exceeded to 172.20.26.17 (probably your client)

For the next request, ttl=2 and this time 172.20.26.17 (next to next
router) send ttl exceeded.
This is happening till ttl=6 at which the Echo Req is successful.

Probably this is the behaviour of ping cmd used with -R (record route)
option enabled.

Attached jpg for reference.

-Ketan

On Mon, Feb 4, 2013 at 1:03 PM, Ketan Kulkarni <ketkulka@gmail.com> wrote:
> Hi Dave,
>
> The TTL is decremented by 1 on every router. If it reaches 0, the pkt
> is dropped and ICMP ttl exceeded is sent to the sender with icmp body
> = first few bytes of the packet which caused this error.
> Looks like, for every new Echo Req, ip ttl is set to 1. The next
> router decrements it and send ICMP ttl exceeded back.
>
> So 172.20.26.17 send Echo Req to 172.20.0.1 with ttl=1.
> 172.20.26.1 (probably your next router) decrements and sends ICMP TTL
> exceeded to 172.20.26.17 (probably your client)
>
> For the next request, ttl=2 and this time 172.20.26.17 (next to next
> router) send ttl exceeded.
> This is happening till ttl=6 at which the Echo Req is successful.
>
> Probably this is the behaviour of ping cmd used with -R (record route)
> option enabled.
>
> Attached jpg for reference.
>
> -Ketan
>
> On Mon, Feb 4, 2013 at 12:40 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> I have been largely looking at packet captures for tcp streams. today I
>> noticed that I was oddly getting icmp ttl exceeded messages back on the
>> network from various devices on the path when I wasn't even pinging...
>>
>> I have to admit parsing icmp is not in my skillset. Is there useful
>> information in the icmp messages in this capture?
>>
>> http://snapon.lab.bufferbloat.net/~d/ttl_exceeded.cap
>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>

Re: [Cerowrt-devel] ping icmp ttl exceeded

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]

Heh. I turned out I'd left mtr running in another window...

On Sun, Feb 3, 2013 at 11:34 PM, Ketan Kulkarni <ketkulka@gmail.com> wrote:

> Sorry to send it again, as the list rejected the attachment
> (attachment removed in this one)
>
> Hi Dave,
>
> The TTL is decremented by 1 on every router. If it reaches 0, the pkt
> is dropped and ICMP ttl exceeded is sent to the sender with icmp body
> = first few bytes of the packet which caused this error.
> Looks like, for every new Echo Req, ip ttl is set to 1. The next
> router decrements it and send ICMP ttl exceeded back.
>
> So 172.20.26.17 send Echo Req to 172.20.0.1 with ttl=1.
> 172.20.26.1 (probably your next router) decrements and sends ICMP TTL
> exceeded to 172.20.26.17 (probably your client)
>
> For the next request, ttl=2 and this time 172.20.26.17 (next to next
> router) send ttl exceeded.
> This is happening till ttl=6 at which the Echo Req is successful.
>
> Probably this is the behaviour of ping cmd used with -R (record route)
> option enabled.
>
> Attached jpg for reference.
>
> -Ketan
>
> On Mon, Feb 4, 2013 at 1:03 PM, Ketan Kulkarni <ketkulka@gmail.com> wrote:
> > Hi Dave,
> >
> > The TTL is decremented by 1 on every router. If it reaches 0, the pkt
> > is dropped and ICMP ttl exceeded is sent to the sender with icmp body
> > = first few bytes of the packet which caused this error.
> > Looks like, for every new Echo Req, ip ttl is set to 1. The next
> > router decrements it and send ICMP ttl exceeded back.
> >
> > So 172.20.26.17 send Echo Req to 172.20.0.1 with ttl=1.
> > 172.20.26.1 (probably your next router) decrements and sends ICMP TTL
> > exceeded to 172.20.26.17 (probably your client)
> >
> > For the next request, ttl=2 and this time 172.20.26.17 (next to next
> > router) send ttl exceeded.
> > This is happening till ttl=6 at which the Echo Req is successful.
> >
> > Probably this is the behaviour of ping cmd used with -R (record route)
> > option enabled.
> >
> > Attached jpg for reference.
> >
> > -Ketan
> >
> > On Mon, Feb 4, 2013 at 12:40 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >> I have been largely looking at packet captures for tcp streams. today I
> >> noticed that I was oddly getting icmp ttl exceeded messages back on the
> >> network from various devices on the path when I wasn't even pinging...
> >>
> >> I have to admit parsing icmp is not in my skillset. Is there useful
> >> information in the icmp messages in this capture?
> >>
> >> http://snapon.lab.bufferbloat.net/~d/ttl_exceeded.cap
> >>
> >> --
> >> Dave Täht
> >>
> >> Fixing bufferbloat with cerowrt:
> >> http://www.teklibre.com/cerowrt/subscribe.html
> >> _______________________________________________
> >> Cerowrt-devel mailing list
> >> Cerowrt-devel@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >>
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 4164 bytes --]

Re: [Cerowrt-devel] ping icmp ttl exceeded

[Maciej Soltysiak]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

On Mon, Feb 4, 2013 at 8:41 AM, Dave Taht <dave.taht@gmail.com> wrote:

> Heh. I turned out I'd left mtr running in another window...

Yeah, exactly. Decreasing TTLs suggest traceroute tools :-)

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

[-- Attachment #2: Type: text/html, Size: 1225 bytes --]

Re: [Cerowrt-devel] ping icmp ttl exceeded

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]

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

> On Mon, Feb 4, 2013 at 8:41 AM, Dave Taht <dave.taht@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 8.8.8.8'

(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:

http://pastebin.com/kWAXJS6d

(pdsh is also very useful for things like 'opkg update; opkg install
something',
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:
http://www.teklibre.com/cerowrt/subscribe.html

[-- Attachment #2: Type: text/html, Size: 3280 bytes --]