>It still baffles me, how NetBSD chose to broadcast on 131.181.255.255.
>
>131.181 is a class B address, isn't it?
>
>christos


But Christos, what does that have to do with anything?


My machine at home on net 36, has a class A address, but if I send MAC
broadcasts packets to 36.255.255.255, it:

	 (a) isn't going to  get  response from anything except
	     misconfigured or hosts, as maybe in  Greg's situation,
	     where the only response is an ICMP port unreachable(!);

	 (b) for all I know, fmay even get me in mild trouble
	     with the Net.Police here for being so ill-behaved
	     as to send directed broadcasts.

Really, if the kernel doesn't know what the netmask is, it should use
255.255.255.255.  Not doing so might explain some of the problems I
had before trying to diskless-boot on nets with non-octet-aligned
subnetmasks.

If you UTSL, even sys/nfs/nfs_boot.c says quite correctly that it
should use the all-ones broadcast address for this broadcast RPC.

I tend to think anything else is a bug.  And using a class-based
broadcast address (or netmask) isn't just a bug, it's *stoopid*.

Not to mention the embarassing ugliness of using a crock like
RARP/bootparams on non-Sun hardware.  Heck, even new *Sun* proms can
do bootp/dhcp (like the IPX repackaged as a JavaStation.)  There
really is no excuse for the kernel to use bootparams at all, now we
don't need to find swap.