[lkml]   [2000]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Traceroute without s bit
On Wed, Dec 06, 2000 at 01:50:19PM +0100, Olaf Kirch wrote:
> Hi all,
> I wrote a small traceroute last night that works mostly like the
> LBL one, except it doesn't need an s bit anymore :)

It already existed in Alexey's iputils (tracepath).

> There are three things that puzzle me, however:
> 1. When I want to include IP options into an outgoing packet,
> I'm expected to include a struct ip_options in the IP_RETOPTS
> control message. However, this struct is included in
> #ifdef __KERNEL__/#endif in 2.4.0-t10 (on which I'm compiling
> right now). Normally this doesn't deter me, but in this case
> some of the fields look sort of fishy to me.
> My question is, do we really want to allow users to hand
> an arbitrary, unchecked struct ip_options to the kernel?
> Wouldn't raw options be a better choice?

Raw options are passed. That ip_options ever appeared in glibc/user headers
was a bug, it is strictly kernel internal.

> 2. There's another issue with ip_cmsg_send in ip_sockglue.c;
> it allows any user to specify PKTINFO data in a control
> messages. As far as I can tell, by looking at udp.c,
> this lets any user set arbitrary IP source addresses
> on outgoing UDP packets. Yikes.

IP_PKTINFO does not allow to set source addresses, only destination
addresses. Source address depends on the boundage or the route.

> 3. There seems to be a bug somewhere in the handling of poll().
> If you observe the traceroute process with strace, you'll
> notice that it starts spinning madly after receiving the
> first bunch of packets (those with ttl 1).
> 13:43:02 poll([{fd=4, events=POLLERR}], 1, 5) = 0
> 13:43:02 poll([{fd=4, events=POLLERR}], 1, 5) = 0
> 13:43:02 poll([{fd=4, events=POLLERR}], 1, 5) = 0
> 13:43:02 poll([{fd=4, events=POLLERR}], 1, 5) = 0
> ...
> I.e. the poll call returns as if it had timed out, but it
> hasn't.

POLLERR is returned until the error queue is empty. I suspect you're
not emptying it properly in all cases. It can contain multiple errors.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:51    [W:0.076 / U:2.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site