Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!ll-xn!cit-vax!elroy!smeagol!earle From: earle@smeagol.UUCP Newsgroups: comp.unix.wizards,comp.bugs.4bsd Subject: Serious problem in SunOS 3.3 subnetting w/r/t booting Sun-2 clients Message-ID: <975@smeagol.JPL.NASA.GOV> Date: Sat, 14-Mar-87 04:01:18 EST Article-I.D.: smeagol.975 Posted: Sat Mar 14 04:01:18 1987 Date-Received: Sat, 14-Mar-87 19:52:31 EST Sender: news@smeagol.JPL.NASA.GOV Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 63 Keywords: ip_icmp.o subnet mask Xref: utgpu comp.unix.wizards:1383 comp.bugs.4bsd:215 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 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@csvax.caltech.edu AT&T: +1 818 354 4034 earle@jplpub1.jpl.nasa.gov (For the daring) - if it GLISTENS, gobble it!!