Date: Mon, 08 Jun 1998 02:33:50 -0700 From: Neil Magedman <neil@cobaltmoon.com> Cc: questions@FreeBSD.ORG Subject: traceroute, Bogus IP Identification in ICMP Message-ID: <357BAFFE.3296A135@cobaltmoon.com>
next in thread | raw e-mail | index | archive | help
I've been toying around with traceroute (1.0.4.4bsd) trying to better
understand how it handles the IP Identification field. I noticed that
it sets the ip_id field to (ident+seq), rather than just leaving it at
0. This seems unnecessary, especially since the id is not actually used
by traceroute when it checks the incoming icmp packets.
Question 1: Any idea why the id is explicitly being set?
Since simultaneous traceroutes could each send packets with the same id,
I began to wonder about how the tcp stack would handle all these
explicitly set id's. I ran two traceroutes simultaneously and confirmed
they were both using the same id numbers. (I added in lines to print out
the ip_id field on sending the probe and on receiving the icmp
response.) I didn't run into any problems, but I wonder how this can
break things.
Question 2: What are the dangers of explicitly setting the ip_id? (say
for example, another socket has already sent a large,
likely-to-be-fragmented packet that got assigned the same id)
Now the weird one! A few destinations seemed to mangle the ip_id when
they return it in the icmp datagram. All the results look good except
for the last one: (note: the "{sending id=%hd}" is just test code that
I've stuck in)
# ./a.out www.yahoo.com
traceroute to www9.yahoo.com (204.71.200.74), 30 hops max, 40 byte
packets
1 {sending id=38099} {received id=38099} gw (207.71.93.254) 2.239
ms {sending id=38100} {received id=38100} 2.67 ms {sending
id=38101} {received id=38101} 1.605 ms
2 {sending id=38102} {received id=38102} as10.irvnca.ni.net
(207.199.98.152) 31.8 ms {sending id=38103} {received id=38103}
31.481 ms {sending id=38104} {received id=38104} 31.882 ms
3 {sending id=38105} {received id=38105} 207.199.98.156
(207.199.98.156) 32.372 ms {sending id=38106} {received id=38106}
34.678 ms {sending id=38107} {received id=38107} 34.812 ms
...
7 {sending id=38117} {received id=58772} www9.yahoo.com
(204.71.200.74) 49.721 ms {sending id=38118} {received id=59028}
47.741 ms {sending id=38119} {received id=59284} 47.787 ms
Notice that the set ip_id matches the ip_id in the icmp data, except for
on the last hop, which mangles the id.
Question 3: [Question 3 was "what is happening here?", but then I
realized that this seems to be a FreeBSD bug (among possibly other
stacks) and that the id is just byte-swapped. So Question 3 is now "Is
this a common bug?"]
And finally of course, my *real* question. I'd like to encode some
additional information in the traceroute probes, and being that the
uh_sport and uh_dport are already being used, I'd like to put that info
in the ip_id field.
Question 4: Is the ip_id field a safe place to put info in or am I
asking for trouble? (ie. will it trip up my tcp stack, make my code
non-portable, fail when targetting certain ip implementations, etc.)
Thanks a bunch to those who have even read this far and a big thanks to
any who reply!
regards,
neil
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?357BAFFE.3296A135>