[Simh] VAX-11/780 DEUNA Ethernet problems with 4.3BSD

Fri Aug 15 16:09:36 EDT 2008

Well, the ethernet source address of aa:fd:00:00:00:00 is a DECNET-style
address, so it indicates decnet is running.
When decnet starts, it *does* change the hardware mac address to the
decnet address. So i'm not sure that that behavior is wrong.
There is a strong warning by HP/Compaq/Digital to start decnet before
other protocols to prevent various networking issues related to MAC
identification.

No one has ever really debugged the SIMH DEUNA/DELUA driver ("XU"), or
has given me reproducable test cases to examine.
The XU driver has just been noted as "working" by those who have tried
to use it, usally with TCP/IP only.
I personally have not gotten the more-difficult DECNET or SCS
(Clustering) protocols working on it under OpenVMS.

If you can give me some more information about your entire
host/client/network configuration, and about the behavior that you're
seeing, I''m willing to help you try to resolve it.
Having NO experience with UNIBUS machines, though, it was hard for me to
infer the hardware behavior of the XU DEUNA from the specs.
Assuming the aa.xx.xx.xx.xx.xx decnet mac address is correct, the log
seems reasonable (without in-depth analysis).

The TCPDUMP log looks like it has other packets in it, such as from your
PC, with the 00:0c:29:01:67:5a address, so you might be seeing the
common "reflection" of packets by using WinPCAP. The XQ controller can
understand the reflections and compensate for them to a limited extent,
but I'm not sure if reflection compensation was ever written into the XU
controller. A possible way around this is to load a pseudo-ethernet TAP
adapter (see the FAQ) attach the SIMH VAX to it, and bridge it to the
real ethernet adapter, so that they don't appear to share MAC addresses.
One of the most significant problems with using SIMH networking is the
WinPCAP reflection issue; using a linux host will get rid of the
problem. Reflection can supposedly be supressed in the latest WinPCAP,
but the SIMH ethernet drivers have not been updated to depend on the
latest WinPCAP yet.

What system are you ARPing from? If it's from the Windows host, you
might see some strange results (see the FAQ [2.10?] for ethernet hosting
issues). Try ARPing from another system..

Dave Hittner
SIMH Ethernet developer

________________________________

From: simh-bounces at trailing-edge.com
[mailto:simh-bounces at trailing-edge.com] On Behalf Of roy hills
Sent: Friday, August 15, 2008 2:09 PM
To: simh at trailing-edge.com
Subject: [Simh] VAX-11/780 DEUNA Ethernet problems with 4.3BSD

I'm running 4.3BSD on the SIMH VAX-11/780 emulator, and I'm having some
issues with the emulated DEUNA Ethernet adapter.  I'm using SIMH version
3.8 on Windows XP.

I've got two issues:

1.  The Ethernet adapter does not appear to respond to broadcasts (i.e.
destination address ff:ff:ff:ff:ff:ff), so the system does not answer
ARP requests.

Here's an example tcpdump output.  The client is at IP address
192.168.1.57, and the 4.3BSD machine is at 192.168.1.70:

18:27:03.623364 00:0c:29:01:67:5a > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 42: arp who-has 192.168.1.70 tell 192.168.1.57
18:27:03.725393 00:0c:29:01:67:5a > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 42: arp who-has 192.168.1.70 tell 192.168.1.57

2.  The Ethernet adapter responds to packets sent to its own address,
but replies from seemingly random source addresses.

Here's an example of an ARP request sent to the SIMH system's MAC
address of 08:00:2b:12:34:56.  We see that it replies with the correct
MAC address in the ARP packet, but the source address in the Ethernet
frame is aa:fd:00:00:00:00

18:29:48.059696 00:0c:29:01:67:5a > 08:00:2b:12:34:56, ethertype ARP
(0x0806), length 42: arp who-has 192.168.1.70 tell 192.168.1.57
18:29:48.060160 aa:fd:00:00:00:00 > 00:0c:29:01:67:5a, ethertype ARP
(0x0806), length 60: arp reply 192.168.1.70 is-at 08:00:2b:12:34:56

Sending another directed ARP request gets a reply with a different
source MAC address:

18:32:05.439533 00:0c:29:01:67:5a > 08:00:2b:12:34:56, ethertype ARP
(0x0806), length 42: arp who-has 192.168.1.70 tell 192.168.1.57
18:32:05.445380 ab:b1:00:00:00:00 > 00:0c:29:01:67:5a, ethertype ARP
(0x0806), length 60: arp reply 192.168.1.70 is-at 08:00:2b:12:34:56

If I put a static ARP mapping on the client, I can telnet to the SIMH
system and login.  The telnet session also uses random source addresses
in the ethernet header, but surprisingly still works OK:

18:38:19.567264 00:0c:29:01:67:5a > 08:00:2b:12:34:56, IPv4, length 74:
192.168.1.57.4658 > 192.168.1.70.23: tcp 0
18:38:19.574243 33:00:00:00:07:00 > 00:0c:29:01:67:5a, IPv4, length 60:
192.168.1.70.23 > 192.168.1.57.4658: tcp 0
18:38:19.574287 00:0c:29:01:67:5a > 08:00:2b:12:34:56, IPv4, length 54:
192.168.1.57.4658 > 192.168.1.70.23: tcp 0
18:38:19.576378 00:0c:29:01:67:5a > 08:00:2b:12:34:56, IPv4, length 78:
192.168.1.57.4658 > 192.168.1.70.23: tcp 24
18:38:19.589707 00:00:00:00:00:00 > 00:0c:29:01:67:5a, IPv4, length 60:
192.168.1.70.23 > 192.168.1.57.4658: tcp 3
18:38:19.589795 00:0c:29:01:67:5a > 08:00:2b:12:34:56, IPv4, length 54:
192.168.1.57.4658 > 192.168.1.70.23: tcp 0
18:38:19.598110 27:ff:fd:05:07:00 > 00:0c:29:01:67:5a, IPv4, length 81:
192.168.1.70.23 > 192.168.1.57.4658: tcp 27
18:38:19.598160 00:0c:29:01:67:5a > 08:00:2b:12:34:56, IPv4, length 54:
192.168.1.57.4658 > 192.168.1.70.23: tcp 0
18:38:19.599593 00:0c:29:01:67:5a > 08:00:2b:12:34:56, IPv4, length 65:
192.168.1.57.4658 > 192.168.1.70.23: tcp 11
18:38:19.609339 1e:01:00:00:c0:a8 > 00:0c:29:01:67:5a, IPv4, length 107:
192.168.1.70.23 > 192.168.1.57.4658: tcp 53
18:38:19.609920 00:0c:29:01:67:5a > 08:00:2b:12:34:56, IPv4, length 60:
192.168.1.57.4658 > 192.168.1.70.23: tcp 6
18:38:19.616475 1e:01:00:00:c0:a8 > 00:0c:29:01:67:5a, IPv4, length 61:
192.168.1.70.23 > 192.168.1.57.4658: tcp 7

The DEUNA configuration in the SIMH config file is:

set xu enabled
set xu mac=08-00-2B-12-34-56
attach xu \Device\NPF_{A390A62C-E18B-45FC-A99F-FB039C5B4032}

The SIMH system sees the DEUNA at boot, and gets the correct MAC
address:

de0 at uba0 csr 174510 vec 120, ipl 15
de0: hardware address 08:00:2b:12:34:56

And ifconfig shows the device OK:

de0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 192.168.1.70 netmask ffffff00 broadcast 192.168.1.255

I'm running the original 1986 vintage 4.3BSD from the CSRG Archive CDROM
installed on a virtual RA81 disk.  Apart from the DEUNA issue, it's
working fine.

Any ideas?

Roy

________________________________

Find out how to make Messenger your very own TV! Try it Now!
<http://clk.atdmt.com/UKM/go/101719648/direct/01/>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20080815/8177975e/attachment-0003.html>