Reading the Routing Tables

Tony Finch dot at
Tue Jan 16 10:05:51 GMT 2001

Dominic Mitchell <dom at> wrote:
>On Mon, Jan 15, 2001 at 12:07:55PM +0000, Roger Hardiman wrote:
>> And just as you suggested earlier, FreeBSD uses the
>> sysctl net.route.dump
>> However, it seems this is an internal sysctl which is why
>> it does not show up with the sysctl command from userland.
>That is most bizarre.  I won't even to pretend to understand why this is
>the case!

sysctl(8) only shows the values of sysctl nodes that it understands.
The routing table sysctl isn't one of them.

The old way of controlling the routing table from userland was to use
the routing socket, as described in Stevens. The sysctl was introduced
because the routing socket API doesn't handle variable- length socket
addresses well. The API for reading network interface addresses
(SIOCGIFADDR etc.) is also broken in this respect.

The original sockets API segregated socket address structures from
their lengths (see connect(2), accept(2), etc.). However SIOCGIFADDR
didn't allow for variable length addresses, but instead depended on
the length of struct sockaddr which is too short for (in order of
implementation) Unix domain sockets (i.e. filenames), ISO addresses,
and IPv6. So a length field sa_len was added to struct sockaddr so
that when the kernel passes socket addresses to userland via
SIOCGIFADDR or via the (new in 4.4) routing socket the kernel also
says how long it is. However in all other contexts the length field is
ignored by the kernel and unnecesary for userland and so is an
irrelevant distraction that should be ignored by portable code.

This part of 4.4BSD pisses me off because it gratuitously fucked up
a previously clean API in order to support an API that is broken as

f.a.n.finch    fanf at    dot at
"Because all you of Earth are idiots!"

More information about the Ukfreebsd mailing list