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.
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.
> I'll look to fix this.
Thanks! And I guess that on the NetBSD side somebody should look at the
device setup too, to make sure it receives broadcasts properly.
> - Mark
-Olaf.
--
___ "Buying carbon credits is a bit like a serial killer paying someone else to
\X/ have kids to make his activity cost neutral." -The BOFH falu.nl@rhialto
Attachment:
signature.asc
Description: PGP signature