RE: dhcpcd not working in simh-vax with xq0:nat networking

[Mark Pizzolato - Info Comm <Mark%infocomm.com@localhost>]

On Saturday, December 11, 2021 at 5:12 AM, Rhialto wrote:
> On Fri 10 Dec 2021 at 21:47:15 +0000, Mark Pizzolato - Info Comm wrote:
> > Well, the configuration you're working with is running in DELQA-T mode
> > which has a different register/programming interface than the original
> > DEQNA.  In DELQA-T mode the OS driver, rather than providing a list of
> > receive MAC addresses (up to about 16), it provides a 8 byte
> > Multi-Cast hash field.  Received packets (including broadcasts) are
> > either the interface's configured MAC address OR they are hashed and
> > looked up for a matching set bit in the Multi-Cast hash.  Broadcast
> > packets are one example of multi-cast packets, BUT the programmed
> > Multi-cast hash provided has no set bits, thus the NAT dhcpd's
> > response packet (which was sent to the broadcast address) , although
> > received is not delivered into the OS since it wasn't an expected
> > packet.
> 
> So that sounds like a NetBSD weirdness: by the time dhcpcd runs, I'd
> expect the interface to be set up to be fully operational, which would
> include being able to receive broadcasts.
> 
> I've looked at NetBSD's if_qt.c
> (https://github.com/NetBSD/src/blob/trunk/sys/dev/qbus/if_qt.c) but I
> didn't see any obvious places where it handles broad/multicast, so that
> is probably somewhere else (or missing). if_qe.c does seem to have some
> mention of that.
> 
> If I configure "set xq type=DELQA", NetBSD sees a qe0 device ("qe0 at
> uba0 csr 174440 vec 764 ipl 17: delqa, hardware address 08:00:2b:af:2c:e8")
> and this works (after I edit /etc/rc.conf to remove the reference to
> qt0).
> 
> With "set xq type=DEQNA" there is again a qe0 device: "qe0 at uba0 csr
> 174440 vec 764 ipl 17: deqna, hardware address 08:00:2b:af:2c:e8" and it
> still works.
> 
> > The problem is actually a bug in the slirp dhcpd which is sending its
> > response to the broadcast address when the protocol specifies the
> > response should be to the MAC address which the request packet came
> > from.

The DELQA-T is the only case (in the XQ variants) which use the multi-cast 
hash.

> I did know it can work, because NetBSD/amd64 in qemu with its slirp
> networking is ok.  Maybe the slirp upstream has made a change in this,
> and/or on that hardware the broadcast is accepted and passed to the OS.

Qemu was the keeper of the legacy slirp code which it used for is earlier 
NAT implementation.  I picked that stuff back in 2015 and used it for the
simh ethernet stack.  Since that time, qemu has completely rewritten 
their NAT implementation so that it could also support NAT for IPv6 
networking.  This new implementation, like the rest of qemu is GPL'd 
and as such not a candidate for inclusion in simh which would then 
make the rest of simh code GPLd.  Lacking IPv6 support is a minimal 
negative for simh since many simh simulator use cases (and the OSes
that run on them) vastly predate IPv6.

Your qemu tests most likely used the newer NAT implementation 
which didn't have the bug.

- Mark