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 6:12 AM, Rhialto wrote:
> On Sun 12 Dec 2021 at 14:33:07 +0100, Anders Magnusson wrote:
> > Hm, it was much different threads in this discussion, and I'm not sure what
> > the problem is.  Please correct me if I got something wrong.
> 
> This issue I observed was that broadcast packets were not received by
> NetBSD, unless something like tcpdump put the interface in promiscuous
> mode. While you were writing your mail I was writing another with an
> experiment that shows that.
> 
> > The qt driver comes from 2BSD, and I imported it with very little changes to
> > the original (new config etc...).
> > I currently do not have any VAX Qbus hardware with qt, but I do run
> 2.11BSD
> > with the qtdriver and it has worked flawlessly for many years :-)
> >
> > About broadcast; if someone ARPs for the qt machine it will be broadcast,
> so
> > if broadcast do not work it would be impossible to connect to the machine.
> > That would have been noticed immediately :-)
> >
> > So, what am I missing? :-)
> 
> Perhaps nothing :) I'm not an expert on hardware. It can still be that
> the qt driver is fine but the simh emulation isn't. Perhaps it should
> receive broadcasts unconditionally. What it seems to do currently is to
> apply the multicast filter to them. I think this is the relevant code in
> simh, sim_ether.c:

Hmmm... Maybe.

> [...]
> Actually, I'm starting to be fairly certain that the emulation is
> imperfect. I looked the the Digital DELQA-Plus Addendum to DELQA Users
> Guide, Part# EK-DELQP-UG-001_Sep89.pdf which is mentioned at the top of
> pdp11_xq.c:
> http://www.bitsavers.org/pdf/dec/qbus/EK-DELQP-UG-001_Sep89.pdf
> Searching for broadcast, I find on page 6-21 about the MODE field:
> 
> MR[15] PRO Promiscuous Mode
> 			    o =  disable promiscuous mode;  that is,
> 			    enable reception from  the LAN of only
> 			    those packets that match the physical
> 			    address (PADR)  or logical  address filter
> 			    (LADRF)  fields  in the init block,  or that
> 			    are broadcast packets.

Hmmm...  I somehow missed those last 3 words when I implemented 
the DELQA-T (aka DELQA-Plus).  I remember specifically thinking about
the broadcast case, but all testing was done with VMS and the VMS 
driver very explicitly provided a multi-cast hash which always included 
the appropriate bit to match the broadcast case.  I remember testing
that explicitly.  I therefore concluded what I had said previously.

We never got any complaints from any other DEC operating system, 
but many/most/all of these may never have attempted to put the 
device into DELQA-T mode and just ran the device as a vanilla DEQNA.

I have fixed this.  I need to test that I haven't broken something else 
and my current network setup was good enough to test the NAT 
dhcp since that didn't involve other hosts, but a few more steps 
are needed here.  I will commit to the master branch when tested.

> Still, I think that in any case the NetBSD qt driver lies when it says
> it supports IFF_MULTICAST.  It doesn't even support IFF_ALLMULTI (in the
> above code represented by all_multicast).

I would think that would be a problem in NetBSD...

- Mark