Serious problem in SunOS 3.3 subnetting w/r/t booting Sun-2 clients

[earle at smeagol.UUCP]

I have just installed SunOS 3.3 (with subnetting support) on a net of
Sun-2's and Sun-3's; some diskless, most diskful.  I have encountered
a serious problem ...

I am on a Class B network, 128.149.0.0, on subnet 10, with host numbers 1-XX.
My main gateway, smeagol, is at 128.149.10.1.  Because of this setup, I
assumed that I wanted to use the subnet mask 255.255.255.0, and so I changed
all the invocations of ifconfig in /etc/rc.boot to add the 
`netmask 255.255.255.0' parameter.  So far so good.

Now, when booting, if a machine is a diskless client, after the message
`using nn buffers containing <humongous amount> bytes of main memory'
comes out, and before /etc/rc.boot is invoked (and the normal case fsck
begins), then the new version of ip_icmp puts out the message
	Setting subnet mask to 0x(nnnnnnnn) 
where the `nnnnnnnn' seems to be matched to the current mask used by the
disk server for the network interface (in my case, 0xffffff00).  On a
Sun-3 client, this message comes out, rc.boot is invoked, and everything
proceeds normally with no problem (as an aside, a diskful Sun-2 running
SunOS 3.3 has no trouble, either, but then again the `Setting subnet mask'
message does not appear).  However, with the 255.255.255.0 subnet mask
on the server, attempts to boot a Sun-2 diskless client *fail* after the
`Setting subnet mask to 0xffffff00'; with resulting error messages:
	nd: output error 51
Assuming this is from errno, we have nd claiming
>	51  ENETUNREACH  Network is unreachable
>	     A socket operation was attempted to an unreachable network.

All I have been able to determine so far is:
(1) If one sets the mask to 255.255.255.254 on the server (obviously
wrong, but an experiment), then the *server* begins emitting these
when the client begins its boot attempt.

(2) The ONLY way I have seen to enable the Sun-2 clients to boot is to
manually reset the netmask to `255.255.0.0' (i.e., the Class B default)
for the particular interface (in my case, ie0).  Then they will boot
properly; the Sun-3 clients don't give a fsck what the mask is, they'll
boot either way.  Now, the problem is that this is *wrong*, I want the
subnet mask to always be 255.255.255.0 (Indeed, on the Sun-2 clients I
invoke `/etc/ifconfig ie0 netmask 255.255.255.0 -trailers up' inside
rc.boot, and there is nary a peep - it only matters during that initial
boot phase), but if the Sun-2 clients should glitch and random crash
they will be hung out to dry forever if I do that!  So ...

- Hasn't anyone else seen this problem?  Unless I've grossly overlooked
something, this should have been caught before any 3.3 tapes were ever
produced!

- Why would (all things being equal) things be different between a Sun-2
and a Sun-3?

- Is there any way around this problem, so I can leave my netmask the way
I want it?

- Is there anything missing in the equation?  Anything that should be done
on the server that isn't obvious???   Arggghhh ...

Anxiously,
-- 
	Greg Earle	UUCP: sdcrdcf!smeagol!earle; attmail!earle
	JPL		ARPA: elroy!smeagol!earle at csvax.caltech.edu
AT&T: +1 818 354 4034	      earle at jplpub1.jpl.nasa.gov (For the daring)
- if it GLISTENS, gobble it!!