From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 777E121F0B3 for ; Sun, 3 Feb 2013 23:41:23 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id h37so3442562iak.18 for ; Sun, 03 Feb 2013 23:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+gcBBwMp+QMrtUyZ1u4ZhrKHG+mRFWFdUROWIQx39dg=; b=AfawJbP24kiceYU37UkQJZosvdRh/PgY/nNsTJ0dsURO502pt2LM/HoYebsrHXa6k0 Gn2Z0T3A1CLAKXcUtkmLFjy8U4Bp04uvH2dp7xw3DySTkymTCId34c22GXW3zxKhjlFP 2QER8OjOJPOBhjnbML2bnTADOSxIceP7Qxr73TXut+0SYdBgsoNnxSRv25n3km7McLE4 PoiU/egaecCVNFbd6klOd3JNFFQeSJXTHUKcJ32jv2Sr3FAI5TIa1Na3JRUvN3apTkEe IhuERDiFXsYIzib1ynQjbSsND0AXZO/NhbyXpTgDSRWkSmHd+7RwkSm0taaeVBNXd95Y 1viw== MIME-Version: 1.0 X-Received: by 10.50.56.139 with SMTP id a11mr4617470igq.86.1359963682857; Sun, 03 Feb 2013 23:41:22 -0800 (PST) Received: by 10.64.135.39 with HTTP; Sun, 3 Feb 2013 23:41:22 -0800 (PST) In-Reply-To: References: Date: Sun, 3 Feb 2013 23:41:22 -0800 Message-ID: From: Dave Taht To: Ketan Kulkarni Content-Type: multipart/alternative; boundary=f46d0401f44939633004d4e13873 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] ping icmp ttl exceeded X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 07:41:23 -0000 --f46d0401f44939633004d4e13873 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Heh. I turned out I'd left mtr running in another window... On Sun, Feb 3, 2013 at 11:34 PM, Ketan Kulkarni 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 > =3D 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=3D1. > 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=3D2 and this time 172.20.26.17 (next to next > router) send ttl exceeded. > This is happening till ttl=3D6 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 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 > > =3D 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=3D1. > > 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=3D2 and this time 172.20.26.17 (next to next > > router) send ttl exceeded. > > This is happening till ttl=3D6 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 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 th= e > >> 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=E4ht > >> > >> 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 > >> > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --f46d0401f44939633004d4e13873 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Heh. I turned out I'd left mtr running in another window...

On Sun, Feb 3, 2013 at 11:34 PM, Ketan Kulkarni <k= etkulka@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
=3D 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=3D1.
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=3D2 and this time 172.20.26.17 (next to next
router) send ttl exceeded.
This is happening till ttl=3D6 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 P= M, Ketan Kulkarni <ketkulka@gmail.= com> wrote:
> Hi Dave,
>
> The TTL is decremented by 1 on every router. If it reaches 0, the pkt<= br> > is dropped and ICMP ttl exceeded is sent to the sender with icmp body<= br> > =3D 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=3D1.
> 172.20.26.1 (probably your next router) decrements and sends ICMP TTL<= br> > exceeded to 172.20.26.17 (probably your client)
>
> For the next request, ttl=3D2 and this time 172.20.26.17 (next to next=
> router) send ttl exceeded.
> This is happening till ttl=3D6 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. to= day I
>> noticed that I was oddly getting icmp ttl exceeded messages back o= n the
>> network from various devices on the path when I wasn't even pi= nging...
>>
>> I have to admit parsing icmp is not in my skillset. Is there usefu= l
>> information in the icmp messages in this capture?
>>
>> http://snapon.lab.bufferbloat.net/~d/ttl_exceeded.cap=
>>
>> --
>> Dave T=E4ht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-dev= el@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>



--
Dave T=E4ht=

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/= subscribe.html=20 --f46d0401f44939633004d4e13873--