Subject: RE: [Fwd: TTL of zero in WinNT?]

From: Amritansh Raghav <[email-masked]>
Date: Tue, 10 Nov 1998 14:15:36 -0800

like I said:
NT will set the TTL to either 1, or the value set via setsockopt - and a
value of 0 is accepted. (the #if 0 was to send with default).

sorry if my tone was harsh - it wasnt directed at the folks who reported the
bug, rather at the random hypotheses being flung around.

> -----Original Message-----
> From: Igor Slepchin [mailto:[email-masked]]
> Sent: Tuesday, November 10, 1998 2:00 PM
> To: Amritansh Raghav
> Cc: Jonathan D. Rosenberg; 'Jon Crowcroft'; Colin Perkins;
> [email-masked]
> Subject: Re: [Fwd: TTL of zero in WinNT?]
> 
> 
> Unfortunately, Mr. Raghav's code doesn't work (even after 
> removing #if 0
> -#endif around the code that sets TTL). In fact, that code does
> precisely what we complained about: it _does_ set the TTL to 
> 0 but then
> it happily sends those datagrams onto the network where they 
> are picked
> up by tcpdump running on a Linux host. This is what happens when i
> specify the real IP address as an outgoing interface. If I bind the
> socket to 127.0.0.1 instead (cute hack, right?), the 
> datagrams are _not_
> sent to the network (hurray?) Alas, they are not sent anywhere else
> either: another app on the same machine listening to the same mcast
> group doesn't receive anything.
> 
> I don't think this is the way anybody but Microsoft would 
> expect that to
> work.
> 
> BTW, this is a confirmed bug: see article Q138268 on msdn
> (http://support.microsoft.com/support/kb/articles/q138/2/68.asp)
> 
> ---
> Igor Slepchin
> 
> Jonathan Rosenberg wrote:
> > 
> > alas, Microsoft speaks (harshly, in fact)
> > 
> > try this fix and see if it helps.
> > --
> > Jonathan D. Rosenberg                       Lucent Technologies
> > Member of Technical Staff                   101 Crawfords Corner Rd.
> > High Speed Networks Research                Holmdel, NJ 07733
> > FAX:   (732) 834-5379                       Rm. 4C-526
> > EMAIL: [email-masked]
> > URL: http://www.cs.columbia.edu/~jdrosen
> > 
> >   
> --------------------------------------------------------------
> ----------
> > 
> > Subject: RE: TTL of zero in WinNT?
> > Date: Tue, 10 Nov 1998 11:56:35 -0800
> > From: Amritansh Raghav <[email-masked]>
> > To: "'Jon Crowcroft'" <[email-masked]>,
> >      Colin Perkins
> >      <[email-masked]>
> > CC: Jonathan Rosenberg <[email-masked]>, 
> [email-masked]
> > 
> > > -----Original Message-----
> > > From: Jon Crowcroft [mailto:[email-masked]]
> > >
> > > In message <[email-masked]>, Colin Perkins typed:
> > >
> > >  >>--> Jonathan Rosenberg writes:
> > >  >>>Has anyone had any experience with sending multicast
> > > packets with a TTL
> > >  >>>of 0 under WinNT? We are getting the bizarre result that
> > > Windows sets
> > >  >>>the TTL to zero, but sends the packets anyway.. We kind
> > > of need this for
> > >  >>>all of these conference bus schemes.
> > >
> > >  >>I'm seeing the same problem -- WinNT 4.0 with service pack
> > > 4 installed.
> > >
> > > Colin
> > >
> > > hypothesis - some smart NT soft-person uses loopback in a
> > > link level driver to
> > > loop multicast packets, instead of havign a general abstraction of
> > > loopback drivers, then forgets that by the time they get to the
> > > link/mac level they cannot check the TTL, so they see a multicast
> > > packet, loop it back, but send it on the wire with TTL=0
> > >
> > > oops
> > 
> > and, as usual, you would be wrong.
> > 
> > anyways - i just tried this and NT defaults to a ttl of 1 
> if you dont
> > setsockopt IP_MULTICAST_TTL, otherwise sets the ttl to the 
> value passed for
> > the socket option (and will accept 0).
> > 
> > i used a small test program (attached, quick cut and paste 
> from someone
> > elses test)which sends UDP packets. seems to work as 
> expected on NT4 SP4.
> > If you can send me more info as to what exactly the program 
> is doing, i
> > would be glad to look at it.
> > 
> > >
> > > j.
> > > this wouldn't hapen in a millenium of halloweens with linux:-)
> > >
> > 
> > once it runs a fully multithreaded kernel with fine grain 
> locking on an mp
> > alpha...
> > 
> > < ..some uuencoded stuff removed..>
>

---

From: Mark Handley <[email-masked]>
Date: Tue, 10 Nov 1998 17:29:27 -0500

>value of 0 is accepted. (the #if 0 was to send with default).

It may _accept_ a value of zero via the setsockopt, but what happens
to packets sent on that socket then?  The correct behaviour is for
them to be received by other applications listening on that host, but
_not_ to be forwarded from any of the physical interfaces.

For what Colin, Igon and Jonathan are saying, this is not what happens
on NT4, but instead they are forwarded from the bound interface.

Mark

---

From: Igor Slepchin <[email-masked]>
Date: Tue, 10 Nov 1998 17:50:06 -0500

The point of this discussion was that NT doesn't handle datagrams with
TTL of 0 correctly, not that it refuses to set ttl. No packets with
ttl=0 should ever appear on the network; in case of multicast, such
packets should only be forwarded to the apps listening to the mcast
group on the same host.

---
Igor Slepchin

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 11 Nov 1998 08:19:03 +0100

In message <ED7E7104F236D11190D800805FFE89950A2D1F29@RED-MSG-49>, Amritansh Rag

 >>value of 0 is accepted. (the #if 0 was to send with default).

yes, but NT still does the wrong thing

 >>bug, rather at the random hypotheses being flung around.

it wasn't RANDOM - it was based on havign access to windows network
device driver code

and it was an informed attempt to help YOU (microsoft) correct things
by the way, so your "gratitude" is noted and will be factored into
future priotorization  of our copious time.

you lose.

 >>> > try this fix and see if it helps.

 cheers

   jon