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

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

On Friday, December 10, 2021 at 12:57 PM, Mark Pizzolato wrote:
> On Friday, December 10, 2021 at 12:07 PM, Rhialto wrote:
> > On Fri 10 Dec 2021 at 19:48:43 +0000, Mark Pizzolato - Info Comm wrote:
> > > I will track this down if you can provide me with a pointer to a disk image
> > > (hopefully compressed) that demonstrates the problem.
> >
> > Thanks! I was thinking in first instance it would be a NetBSD weirdness,
> > but maybe it isn't. I only tried the microvax3900, not other models.
> 
> It may be NetBSD weirdness, or it more likely a general weakness in the
> dhcpd in the simh NAT code.  The NAT code comes from what was originally
> slirp.  The NAT dhcp activities under simh haven't generally gotten much (if
> any) exercise since I think that only NetBSD has a dhcp client.  Maybe
> Johnny's RSX TCP stack also has a dhcp client, but users probably haven't
> been
> using NAT.
> 
> As I start to think about this and the digging you already did that observed
> that
> it worked when tcpdump put the qt interface into promiscuous mode, I'm
> thinking that the default QT initialization of the XQ device isn't configuring an
> appropriate MAC receive address that would match the destination MAC
> address of the slirp dhcp's DHCP response packets.  I haven't looked yet, but
> maybe the slirp dhcp response packets may have a broadcast destination
> address and the interface may not be yet configured with a broadcast
> address in its match list.
> 
> I'll let you know what I find.

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.  

Your configuration file has commented out XQ debug values which, if enabled 
and if global debug logging is also enabled (SET DEBUG STDOUT) show the 
appropriate activity.

DBG(282668943)> XQ REG: xq_wr_srqr_action(data=0x0002)
DBG(282668943)> XQ SETUP: XQ: setup> Turbo Initialization Block!
DBG(282668943)> XQ SETUP: XQ: setup> set Mode:
DBG(282668943)> XQ SETUP: XQ: setup> set Physical MAC Address: 08:00:2B:EC:99:45
DBG(282668943)> XQ SETUP: XQ: setup> set Multicast Hash: 00 00 00 00 00 00 00 00
DBG(282668943)> XQ SETUP: XQ: setup> set Options: INT
DBG(282668943)> XQ SETUP: XQ: setup> set Vector: 500 =0x1F4
DBG(282668943)> XQ SETUP: XQ: setup> set Host Inactivity Timeout: 0 seconds
DBG(282668943)> XQ SETUP: XQ: setup> set Boot Password: 00 00 00 00 00 00
DBG(282668943)> XQ SETUP: XQ: setup> set Receive Ring Buffer Address:  01AE28
DBG(282668943)> XQ SETUP: XQ: setup> set Transmit Ring Buffer Address: 01B028
DBG(282668943)> XQ ETH: Multicast Hash: 00-00-00-00-00-00-00-00
DBG(282668943)> XQ ETH: Filter Set
DBG(282668943)> XQ ETH:   Addr[0]: 08:00:2B:EC:99:45
DBG(282668943)> XQ ETH: BPF string is: |(((ether dst 08:00:2B:EC:99:45) or (ether multicast)))|

A little later we see:

qt0: executing `/libexec/dhcpcd-run-hooks' CARRIER
DUID 00:01:00:01:14:92:c8:77:08:00:2b:af:2c:e8
qt0: IAID 2b:ec:99:45
qt0: delaying IPv6 router solicitation for 0.8 seconds
qt0: delaying IPv4 for 0.2 seconds
qt0: reading lease `/var/db/dhcpcd/qt0.lease'
qt0: rebinding lease of 10.0.2.15
qt0: sending REQUEST (xid 0xa3c2c820), next in 3.6 seconds
DBG(320631487)> XQ REG: xq_wr(data=0x8000, PA=0x2000192E[ARQR], access=2)
DBG(320631487)> XQ REG: xq_wr_arqr(data=0x8000)
DBG(320631487)> XQ TRACE: xq_process_turbo_xbdl()
DBG(320631487)> XQ PACKET: xq-write  dst: FF:FF:FF:FF:FF:FF  src: 08:00:2B:EC:99:45  proto: 0x0800  len: 376  crc: F4D450B3
DBG(320631487)+> XQ ETH: writing  dst: FF:FF:FF:FF:FF:FF  src: 08:00:2B:EC:99:45  proto: 0x0800  len: 376  crc: F4D450B3
DBG(320631487)> XQ PACKET: 0000 FF FF FF FF FF FF 08 00 2B EC 99 45 08 00 45 00 ........+..E..E.
DBG(320631487)> XQ PACKET: 0010 01 6A 45 53 00 00 40 11 34 31 00 00 00 00 FF FF .jES..@.41......
DBG(320631487)+> XQ ETH: Select returned 1
DBG(320631487)+> XQ ETH: 1080: save_rfd=1, rfd=1
DBG(320631487)> XQ PACKET: 0020 FF FF 00 44 00 43 01 56 76 4B 01 01 06 00 A3 C2 ...D.C.VvK......
DBG(320631487)> XQ PACKET: 0030 C8 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . ..............
DBG(320631487)+> XQ ETH: received  dst: FF:FF:FF:FF:FF:FF  src: 52:55:0A:00:02:02  proto: 0x0800  len: 590  crc: 61211699
DBG(320631487)> XQ PACKET: 0040 00 00 00 00 00 00 08 00 2B EC 99 45 00 00 00 00 ........+..E....
DBG(320631487)> XQ PACKET: 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
DBG(320631487)> XQ PACKET: 0060 thru 010F same as above
DBG(320631487)> XQ PACKET: 0110 00 00 00 00 00 00 63 82 53 63 35 01 03 3D 13 FF ......c.Sc5..=..
DBG(320631487)> XQ PACKET: 0120 2B EC 99 45 00 01 00 01 14 92 C8 77 08 00 2B AF +..E.......w..+.
DBG(320631487)> XQ PACKET: 0130 2C E8 32 04 0A 00 02 0F 39 02 05 C0 3C 26 64 68 ,.2.....9...<&dh
DBG(320631487)> XQ PACKET: 0140 63 70 63 64 2D 38 2E 31 2E 39 3A 4E 65 74 42 53 cpcd-8.1.9:NetBS
DBG(320631487)> XQ PACKET: 0150 44 2D 39 2E 32 5F 53 54 41 42 4C 45 3A 76 61 78 D-9.2_STABLE:vax
DBG(320631487)> XQ PACKET: 0160 3A 76 61 78 91 01 01 37 0E 01 79 21 03 06 0C 0F :vax...7..y!....
DBG(320631487)> XQ PACKET: 0170 1A 1C 33 36 3A 3B 77 FF                         ..36:;w.
DBG(320631487)> XQ XBDL: completed processing write
DBG(320631487)> XQ TRACE: xq_setint() - Generate Interrupt
DBG(320631487)> XQ TRACE: xq_reset_santmr(enable=0, qsecs=0)
DBG(320631521)> XQ REG: xq_rd(PA=0x2000192C [SRR], access=0)
DBG(320631521)> XQ VAR: FES0 CHN0 NXM0 PAR0 IME0 TBL0 RS11 RS00
DBG(320631537)> XQ REG: xq_wr(data=0x0080, PA=0x2000192E[ARQR], access=2)

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'll look to fix this.

- Mark