Traceroute without s bit

DISCUSSION Olaf Kirch 3 participants 6 messages Dec 6, 2000

lore

Share & tools

lore

Olaf Kirch

author

2000-12-06 13:21 UTC #0 lore raw

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

Since the source code is small, I'm attaching it to this mail. Note that it requires a 2.4 linux kernel and possibly a recent glibc (not sure of that).

Most of the features it uses are standard BSD stack ones, except for the use of IP-level control messages to obtain the ICMP error codes and the error's time stamp.

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?

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.

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.

Any input from network kernel hackers would be greatly appreciated!

Cheers,
Olaf

Signature · 4 lines

Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
[email protected]  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
[email protected]    +-------------------- Why Not?! -----------------------
         UNIX, n.: Spanish manufacturer of fire extinguishers.

Andi Kleen

2000-12-06 13:40 UTC #1 lore raw

Quoted 4 lines · Olaf Kirch

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).

Quoted 9 lines

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.

Quoted 3 lines

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.

Quoted 6 lines

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.

Quoted 14 lines

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.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Olaf Kirch

author

2000-12-06 15:38 UTC #2 lore raw

In reply to Olaf Kirch

Quoted 2 lines · Andi Kleen

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

No. At least udp_sendmsg uses the spec_dst_addr field as the source address. I added some code to my traceroute that lets you select the source address in order to verify that.

However the good thing is that somewhere something seems to check that the requested address is indeed one attached to a local interface.

Quoted 7 lines

Quoted 4 lines
	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
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.

But it doesn't return POLLERR. If it was returning it, pollfd.revents would be set. pollfd.events is the event mask that's being passed _into_ the poll() call.

You're right about the IP_RETOPS stuff though. I didn't look closely enough; ip_cmsg_send does expect raw options.

Thanks,
Olaf

Signature · 8 lines

Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
[email protected]  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
[email protected]    +-------------------- Why Not?! -----------------------
         UNIX, n.: Spanish manufacturer of fire extinguishers.            
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

James Antill

2000-12-06 16:07 UTC #3 lore raw

In reply to Olaf Kirch

Quoted 13 lines · Olaf Kirch

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.

I've just looked at it, but I'm pretty sure this is a bug in your
code. This should fix it...

traceroute.c renamed from traceroute.c.orig +1 -1

@@ -193,7 +193,7 @@
 				timeout = hop->nextsend;
 		}
 
-		poll(pfd, m, timeout - now);
+		poll(pfd, m, (timeout - now) * 1000);
 
 		/* Receive any pending ICMP errors */
 		for (n = 0; n < m; n++) {

Signature · 8 lines

# James Antill -- [email protected]
:0:
* ^From: .*[email protected]
/dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Andi Kleen

2000-12-06 16:58 UTC #4 lore raw

In reply to Olaf Kirch

Quoted 7 lines · Olaf Kirch

Quoted 2 lines · Andi Kleen
IP_PKTINFO does not allow to set source addresses, only destination addresses. Source address depends on the boundage or the route.
No. At least udp_sendmsg uses the spec_dst_addr field as the source address. I added some code to my traceroute that lets you select the source address in order to verify that.

Please read the code again.

It uses spec_dst to select the possibly policy sourced route -- the actual source address is only set from that route (either default or what was set using ip route's from flag) or the bound address.

Quoted 2 lines

However the good thing is that somewhere something seems to check that the requested address is indeed one attached to a local interface.

That's not actually checked, but in most simple routing configurations it is true.

Quoted 6 lines

Quoted 5 lines

	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

Quoted 6 lines

Quoted 2 lines
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.
But it doesn't return POLLERR. If it was returning it, pollfd.revents would be set. pollfd.events is the event mask that's being passed _into_ the poll() call.

Right. I missed your 5ms timeout @)

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Olaf Kirch

author

2000-12-06 17:00 UTC #5 lore raw

In reply to Olaf Kirch

Quoted 2 lines · James Antill

I've just looked at it, but I'm pretty sure this is a bug in your
code.

Ick. Thanks!

Olaf

Signature · 8 lines

Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
[email protected]  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
[email protected]    +-------------------- Why Not?! -----------------------
         UNIX, n.: Spanish manufacturer of fire extinguishers.            
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/