I didn't realize this was legal in the ip addressing standard,
however, if nothing else, it's a problem with 'netstat' 's inability
to represent the number, which is a netbsd problem:

# netstat -rnf inet
0.0.5&0xa050501    255.255.0.255      UGS         0       23      -  tlp0

and (to a lesser extent) 'route' 's reporting of a negative mask:
(I don't know a better way to report this, maybe /-8 would be better.=20
Maybe slash notation just doesn't work for non-contiguous masks)
# route -n show
0.0.5.0/-7        255.255.0.255      UG

Although I think a warning would be appropriate when this sort of
thing was entered.

On 1/23/06, Ignatios Souvatzis <ignatios@cs.uni-bonn.de> wrote:
> On Mon, Jan 23, 2006 at 11:25:34AM -0500, matthew sporleder wrote:
> >  0.0.5&0xa050501 isn't a valid ip.  From the part of the message you
> > cut off, you can see there's a negative value for the netmask set. (I
> > believe it was -7)  This should not be allowed, and it seems to be
> > causing some sort of (casting?) error where the last octect of the ip
> > is a larger-than-255 hex value.
> >
> > In what way is this legal?
>
> That's *not* the netmask. That's the attempt of "route" to translate
> the netmask into a number of contiguous bits being 1, which, of course,
> fails.
>
> Maybe I'm confused, but I don't see how the cited route and netstat
> output points to a NetBSD problem, unless the original poster tells us
> what entered that route into the kernel. I can do it, for example, with
> a simple shell commad:
>
> # route add 192.168.0.0 -netmask 10.5.5.1 255.255.0.255
> add net 192.168.0.0: gateway 255.255.0.255
> # netstat -rnf inet
> Routing tables
>
> Internet:
> Destination        Gateway            Flags     Refs     Use    Mtu  Inte=
rface
> 0&0xa050501        255.255.0.255      UGS         0        0      -  ex0 =
=3D>
>
> Regards
>         Ignatios
>
>