Subject: Re: NetBSD NFS root
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Gregory McGarry <gmcgarry@lux.sprc.qut.edu.au>
List: port-pmax
Date: 07/15/1997 08:33:43
Jonathan Stone wrote:

> It's really hard to tell with the names in your tcpdump output.
> (I'm sure they're meaningful to you, but raw IP and MAC addresses
> would be easier tome.) I woudl

Sorry.  Here it is again:

(1) :  rarp who-is 8:0:2b:2a:22:5a tell 8:0:2b:2a:22:5a
(2) :  rarp reply 8:0:2b:2a:22:5a at 131.181.17.28
(3) :  arp who-has 131.181.17.28 tell 131.181.17.28
(4) :  131.181.17.28.1023 > 131.181.255.255.111: udp 96 (ttl 64, id 0)
(5) :  arp reply 131.181.17.28 is-at 8:0:2b:2a:22:5a
(6) :  131.181.17.81 > 131.181.17.28: icmp: 131.181.255.255 udp port 111
       unreachable (ttl 255, id 62286)
(7) :  131.181.17.5.32771 > 131.181.17.28.1023: udp 80 (DF) (ttl 255, id 41011)
(8) :  arp who-has 131.181.17.5 tell 131.181.17.28
(9) :  arp reply 131.181.17.5 is-at 8:0:20:1d:80:5e
(10):  131.181.17.28.1023 > 131.181.17.5.38671: udp 76 (ttl 64, id 1)
(11):  131.181.17.5.38671 > 131.181.17.28.1023: udp 84 (DF) (ttl 255, id 41012)
(12):  131.181.17.28.1023 > 131.181.17.5.38671: udp 76 (ttl 64, id 2)
(*) :  [...]

This is my understanding.

The DS5000/25 is 8:0:2b:2a:22:5a.  It has just tftpboot'ed the
newest GENERIC kernel from last night in ftp.netbsd.org/~test/netbsd.ecoff.
It is asked to NFS mount root.  The NFS server is 8:0:20:1d:80:5e which
is IP address 131.181.17.5.  It works under Ultrix 4.2.

The DS sends out a RARP request (1) which is promptly replied as
being 131.181.17.2 (2).
What does (3) do?  rpc.bootparamd maybe?
(4): A broadcast? on sunrpc port 111?  Why would it do this, when it
knows the NFS server from rpc.bootparamd? (or does it? - see (5))
(5) is reply to (3)?
(6) is a reply to the broadcast denying connection to sunrpc port 111
of 131.181.17.81.  Why didn't more machine reply I wonder?
(7): I'd suspect that 131.181.17.5.111 (the actual NFS server) also has
received the broadcast, has fork()ed and replied on the new port 32771
to 131.181.17.28.
(8,9): 131.181.17.28 received the reply and now wants to talk back.
(10) 131.181.17.28.1023 talks to 131.181.17.5.38671.  Is this the
correct port?
(11) maybe some error message?
(12) 31.181.17.28.1023 keeps trying.

Have a look under Ultrix (very straight forward):

[mount -t nfs 31.181.17.5:/opt/dsroot /mnt]

131.181.17.28.1038 > 131.181.17.5.111: udp 56 (ttl 30, id 35)
131.181.17.5.111 > 131.181.17.28.1038: udp 28 (DF) (ttl 255, id 42336)
131.181.17.28.305ba744 > 131.181.17.5.801: 40 null (ttl 30, id 36)
131.181.17.5.801 > 131.181.17.28.305ba744: reply ok 24 null (DF) (ttl 255, id 42337)
131.181.17.28.1040 > 131.181.17.5.111: udp 56 (ttl 30, id 37)
131.181.17.5.111 > 131.181.17.28.1040: udp 28 (DF) (ttl 255, id 42338)
131.181.17.28.1022 > 131.181.17.5.32782: udp 100 (ttl 30, id 38)
131.181.17.5.32782 > 131.181.17.28.1022: udp 60 (DF) (ttl 255, id 42339)
131.181.17.28.f2a15d2f > 131.181.17.5.801: 116 getattr [|nfs] (ttl 255, id 9984)
131.181.17.5.801 > 131.181.17.28.f2a15d2f: reply ok 96 getattr [|nfs] (DF) (ttl 255, id 42340)
131.181.17.28.f3a15d2f > 131.181.17.5.801: 116 statfs [|nfs] (ttl 255, id 10240)
131.181.17.5.801 > 131.181.17.28.f3a15d2f: reply ok 48 statfs [|nfs] (DF) (ttl 255, id 42341)

>  >Why does it say it's talking to 0x83b51105 when it actually tried
>  >talking to 131.181.255.255?
> 
> Are you sure? that sounds very suspicious to me. What is your subnet
> and subnetmask?  What broadcast address are you using?

How is that specified through rpc.bootparamd?

> The NetBSD machine says it thinks it's talking to 131.181.17.5.  (look
> in sys/nfs/krb_subr, that's where the message is; that hex number is
> an IP address in native byteorder).  Is that your  NFS server?

Yes.  I think I'll get some sources.

Jonathan Stone also wrote:

> I just put a new GENERIC kernel on ftp.netbsd.org in
> ~ftp/pub/NetBSD/arch/pmax/test/, in a.out ecoff and ELF format.
> 
> This kernel is GENERIC as of last night. I haven't tested it other
> than verifying that it boots ('m still running an older kernel
> to build a snapshot.)
> 
> But (courtesy of Michael Hitch) the kernel in test/ *does* have fixes
> for two Personal DECstation (MAXINE) specific bugs:
>         * the "cursor movement restricted to 3/4s of screen"  problem
>         * the "cannot type in a root when NFSbooting a GENERIC kernel"
>           problem

Very nice.

Regards,
Greg