RE: qt multi- and broadcast (was Re: dhcpcd not working in simh-vax with xq0:nat networking)

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

On Sunday, December 12, 2021 at 10:54 AM, Rhialto wrote:
> On Sun 12 Dec 2021 at 18:24:13 +0000, Mark Pizzolato - Info Comm wrote:
> > How does NetBSD generally handle multi-cast?  What interfaces exist to
> > NIC drivers to express the desire to receive all or particular multi-cast
> > packets?
> 
> I think a good example to look at would be the "qe" driver, i.e. for
> DELQA-normal:
> https://github.com/NetBSD/src/blob/trunk/sys/dev/qbus/if_qe.c
> Starting at line 641 is the ioctl function, which handles the
> SIOCADDMULTI and SIOCDELMULTI requests. I don't think there is something
> similar to request receiving broadcasts; afaik they are always assumed to be
> enabled. If any multicast address is added or deleted, a new init packet
> is sent.

This sounds completely reasonable.  Is there anything in the qt driver 
which deals with these ioctl functions?  The code which handles that in qt 
should be common with (or copied from) other drivers which use LANCE chips...

> From line 790, the init packet is set up. It looks like it sets every
> filter entry to the broadcast addr; leaves slot #0 alone, and then
> overwrites slot #1 with its own address (j seems to be the slot number).
> Then from slot #3 on it fills in multicast addresses, and if there are
> too many it falls back to "all multicast" mode (which is actually
> implemented as promiscuous mode; Maybe the driver writer didn't see
> EK-DELQA-UG-002.pdf where page 3-31 mentions the C<00> All Multicast
> address filter)

QE Broadcast packet reception must be explicitly enabled as mentioned  
at the end of paragraph three in 3.6.2.4:
     The broadcast Ethernet address (all Is) may be optionally enabled.

> It looks like the DELQA-normal init packet sets too many bytes to 0xFF
> and doesn't heed "reserved bytes should be set to zero"; slot #0 looks
> like being part of the reserved bytes apart from the "MOP flag"; page
> 3-33.

I don't see "reserved bytes should be set to zero" anywhere.  I do see: 
  " Any columns not used should be set to the physical address (for better 
    protection against mischievous Ethernet traffic)."
It would seem that setting the broadcast or the desired device MAC 
address would be equivalent addresses since that value is already in the list.

Either the broadcast address or the device's MAC address doesn't affect 
performance in the simulator since duplicated addresses are only 
considered one time by sim_ether.

BTW, I've committed the change to the XQ device so that DELQA-T 
mode will receive broadcast packets.

- Mark