On Fri, 27 Aug 1999, Paul wrote:

	Ok. I mannaged to get the machine to netboot once again, thanks in
part to a helpful suggestion by Greg Oster. There were two problems,
the second one of which I am confused about.
	First, the lif file that rbootd was giving to the client machine was
antiquated, and apparantly has difficulties with some kernels (ie. the
diskless ones) causing the kernel to appear to hang, or perhaps the boot
program hung after loading and before transfering to the kernel. Whatever.
Once I got rbootd to use a more modern lif file, I was stuck at the
point where the generic kernel had stopped trying to talk to my
server machines bootparamd.

(from tcpdump--- the server is not responding to the portmap request)
@>21:28:42.042320 squidclock.home.org.1023 > 192.168.2.255.sunrpc: udp 96
@>21:28:43.035204 squidclock.home.org.1023 > 192.168.2.255.sunrpc: udp 96
@>21:28:45.035160 squidclock.home.org.1023 > 192.168.2.255.sunrpc: udp 96
@>

(This is different from when the boot program successfully was able to
connect to my servers bootparamd, by broadcasting to everything, not just
the subnet its on. eg squidclock.home.org.1023 > 255.255.255.255.sunrpc )

	The problem here has something to do with how my server's ethernet
device was configured.
	Here is the non-working ifconfig:

le0: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        media: Ethernet manual
        status: active
        inet 192.168.2.2 netmask 0xffff0000 broadcast 192.168.255.255

	Here is the working one:

le0: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        media: Ethernet manual
        status: active
        inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255


	The only difference is the netmask and broadcast address. Can anyone
explain why this caused portmap to not respond?

Paul