* [Cerowrt-devel] ping icmp ttl exceeded @ 2013-02-04 7:10 Dave Taht 2013-02-04 7:33 ` Ketan Kulkarni 0 siblings, 1 reply; 6+ messages in thread From: Dave Taht @ 2013-02-04 7:10 UTC (permalink / raw) To: cerowrt-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] ping icmp ttl exceeded 2013-02-04 7:10 [Cerowrt-devel] ping icmp ttl exceeded Dave Taht @ 2013-02-04 7:33 ` Ketan Kulkarni 2013-02-04 7:34 ` Ketan Kulkarni 0 siblings, 1 reply; 6+ messages in thread From: Ketan Kulkarni @ 2013-02-04 7:33 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] ping icmp ttl exceeded 2013-02-04 7:33 ` Ketan Kulkarni @ 2013-02-04 7:34 ` Ketan Kulkarni 2013-02-04 7:41 ` Dave Taht 0 siblings, 1 reply; 6+ messages in thread From: Ketan Kulkarni @ 2013-02-04 7:34 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt-devel 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 >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] ping icmp ttl exceeded 2013-02-04 7:34 ` Ketan Kulkarni @ 2013-02-04 7:41 ` Dave Taht 2013-02-04 14:17 ` Maciej Soltysiak 0 siblings, 1 reply; 6+ messages in thread From: Dave Taht @ 2013-02-04 7:41 UTC (permalink / raw) To: Ketan Kulkarni; +Cc: cerowrt-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] ping icmp ttl exceeded 2013-02-04 7:41 ` Dave Taht @ 2013-02-04 14:17 ` Maciej Soltysiak 2013-02-04 16:37 ` Dave Taht 0 siblings, 1 reply; 6+ messages in thread From: Maciej Soltysiak @ 2013-02-04 14:17 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] ping icmp ttl exceeded 2013-02-04 14:17 ` Maciej Soltysiak @ 2013-02-04 16:37 ` Dave Taht 0 siblings, 0 replies; 6+ messages in thread From: Dave Taht @ 2013-02-04 16:37 UTC (permalink / raw) To: Maciej Soltysiak; +Cc: cerowrt-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-02-04 16:37 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-04 7:10 [Cerowrt-devel] ping icmp ttl exceeded Dave Taht 2013-02-04 7:33 ` Ketan Kulkarni 2013-02-04 7:34 ` Ketan Kulkarni 2013-02-04 7:41 ` Dave Taht 2013-02-04 14:17 ` Maciej Soltysiak 2013-02-04 16:37 ` Dave Taht
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
![[-- Attachment #2: icmp_ttl_exceed.JPG --] [-- Type: image/jpeg, Size: 319527 bytes --]](../../CAD6NSj5ZPr1yz9FqnyusicqsdM42itc+HGqZ-1-EZpy0onf19g@mail.gmail.com/2-icmp_ttl_exceed.JPG){kind=link}