cvs commit: src/sbin/route route.c

Bruce Evans brde at optusnet.com.au
Wed Oct 31 05:42:03 PDT 2007


On Tue, 30 Oct 2007, Giorgos Keramidas wrote:

> On 2007-10-29 00:08, Mike Makonnen <mtm at freebsd.org> wrote:
>> mtm         2007-10-29 00:08:24 UTC
>>
>>   FreeBSD src repository
>>
>>   Modified files:
>>     sbin/route           route.c
>>   Log:
>>   Fix an error in bit shifting logic for network addresses. The route
>>   command would add incorrect routing entries if network numbers weren't
>>   fully "spelled" out according to their class. For example:
>>     # route add 128.0/16   (works)
>>     # route add 128/16     (doesn't work)

Isn't this supposed to be handled by inet_net_pton(3)?

>>   [...]
>>   Submitted by:   Nuno Antunes <nuno.antunes at gmail.com> (mostly)
>>   MFC after:      1 week
>>
>>   Revision  Changes    Path
>>   1.82      +24 -20    src/sbin/route/route.c
>
> Thank you Mike!  Almost identical to the patch I was testing a while
> back, including better netmask handling parts :-)
>
> Nuno has also mentioned that `netstat -rn' gets things wrong; do you
> have a WIP for that too?  Do you need help with testing?

I don't know much about this, but noticed some related bugs in netstat
going away, which I though was due to the libary being improved.
Actually, the problems in netstat are smaller, since it just needs to
print addresses in a standard format.  It uses inet_ntoa() and
inet_ntop(), and these seem to be inferior in most ways to inet_net_*().
In particular, /N is only documented to be handled by inet_net_pton(),
and then only for full quad addresses.  However, inet_net_pton() seems
to do the right thing for shorter addresses (it does the same thing
for 128/16 as for 128/16; the result on little-endian machines is 16
bits with value 0x0080; printing this result using inet_net_ntop()
gives 128.0/16).  OTOH, inet_net_pton() doesn't support hex numbers in
dotted-quad format (it only accepts a leading 0x and then wants no dots).

The man pages aren't very clear about this.

FreeBSD's libc/net/in_addr.c was cleaned up significantly in rev.1.8,
but the changes were clobbered by less significant changes in the ISC
version.  E.g., where 1.8 version uses strtoul() and actually checks
for errors, rev.1.7 uses a home-made number parser that silently
overflows for large (invalid) numbers, while the current FreeBSD=ISC
version is identical with 1.7 except for cosmetic changes and 2 fixes
for bugs other than the overflow bugs in the parser.  The history is
hard to follow because the current version is in a different directory
(libc/inet).

The inet_net_*() functions are in a different file and don't seem to
have ever been changed significantly by FreeBSD.  They have the usual
home-made number parser with overflow bugs.  Their non-support for
dotted-hex numbers may be just a bug.  A comment in the code says that
hex octets are supported, and the man page says that all "parts" of
an address may be a number in C format, including hex and octal.  The
implementation is completely missing support for octal (e.g., 010 is
interpreted as decimal 10 by inet_net_ntop() but as decimal 8 by
inet_ntop()).  However, their man page seems to have been cloned from
inet.3, so it might not be authoritative.

Bruce


More information about the cvs-src mailing list