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
--
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.
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.
-Andi
On Wed, Dec 06, 2000 at 02:09:05PM +0100, Andi Kleen wrote:
> 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.
> > 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
--
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.
Olaf Kirch <[email protected]> writes:
> 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.orig Wed Dec 6 10:33:48 2000
+++ traceroute.c Wed Dec 6 10:34:06 2000
@@ -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++) {
--
# James Antill -- [email protected]
:0:
* ^From: .*[email protected]
/dev/null
On Wed, Dec 06, 2000 at 04:07:38PM +0100, Olaf Kirch wrote:
> On Wed, Dec 06, 2000 at 02:09:05PM +0100, Andi Kleen wrote:
> > 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.
> 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.
>
> > > 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.
Right. I missed your 5ms timeout @)
-Andi
On Wed, Dec 06, 2000 at 10:35:14AM -0500, James Antill wrote:
> I've just looked at it, but I'm pretty sure this is a bug in your
> code.
Ick. Thanks!
Olaf
--
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.