port-i386/54562: pxeboot NFS V2 READ Call into the void

[pbraun%nethence.com@localhost]

>Number:         54562
>Category:       port-i386
>Synopsis:       pxeboot NFS V2 READ Call into the void
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 22 17:45:00 +0000 2019
>Originator:     pierre-philipp braun
>Release:        9.0_BETA
>Organization:
Innopolis University
>Environment:
n.a. (pxeboot)
>Description:
This bug report is either about the NFS client built-into netbsd's pxeboot, or probably rather about its built-in DHCP client.

While trying to PXE boot netbsd-INSTALL.gz from a Lignux NFS server, and after facing, sniffing and solving unknown error codes 72 and 45, I finally end-up with a similar problem as in the pxeboot/TFTP client bug I just reported (54561).  So after numerous tweaks on the server side, namely enabling NFS version 2 and adding no_subtree_check to exports, it looks like it could work.

The pxeboot built-in NFS client sends its `V2 LOOKUP Call` alright and the server answers with `V2 LOOKUP Reply`.  Then comes two `V2 READ Call` requests and server answers back two `V2 READ Reply` in turns.  However the third `V2 READ Call` sent by the client ends-up nowhere as the destination IP is 0.0.0.0.

It seems pxeboot lost track of its DHCP lease.

>How-To-Repeat:
Setup a PXE service (DHCP+TFTP+pxeboot), here done on Slackware Linux 14.2.  I did not try to reproduce it with NetBSD's NFS server.

    max-lease-time 7200;

    next-server TFTP-NFS-SERVER;
    filename "pxeboot_ia32.bin";
    option root-path "/tftpboot";

Then PXE boot from a client node, get to the netbsd boot loader prompt provided by pxeboot and enter one of those (NFS is the default)

    boot nfs:netbsd-INSTALL.gz
    boot netbsd-INSTALL.gz

>Fix: