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

Fri Aug 15 17:40:21 EDT 2008

David,

aa:fd:00:00:00:00 does look a bit like a DECnet physical address, but I think that's a red herring because 4.2BSD Unix doesn't run DECnet (just TCP/IP) and the source MAC address keeps changing to what appear to be random values.  Anyway, I think DECnet addresses should start with aa:00:04:00.

My testbench configuration consists of two physical machines, both running Windows, connected to an Ethernet switch.  On one of these systems I'm running 4.2BSD under SIMH 780 (we'll call this system "simh") and on the other I'm running Debian Linux under VMware workstation (we'll call this "linux").  The tcpdump sniffing is run from the linux system.

The network address configuration is:

Linux: MAC 00:0c:29:01:67:5a, IP 192.168.1.57
simh: MAC 08:00:2b:12:34:56, IP 192.168.1.70

Here is part of a Telnet conversation between "linux" and "simh" (copied from the earlier email):

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

We see that "linux" always has the MAC address 00:0c:29:01:67:5a, and always sends to "simh" at 08:00:2b:12:34:56.

We know "simh" receives traffic directed to 08:00:2b:12:34:56, because it responds and the telnet session works.  However, simh uses all sorts of different source addresses in the Ethernet frame header.  In this example, we see:

33:00:00:00:07:00
00:00:00:00:00:00
27:ff:fd:05:07:00
1e:01:00:00:c0:a8 (twice)

Note that in the last address, the last two octets are c0:a8, which is 192.168 in decimal, which is the first two octets of the IP address.  That's probably not a coincidence.

My guess would be that it's referencing the wrong bit of memory to read the address from, but that's just a guess.

Roy

Subject: RE: [Simh] VAX-11/780 DEUNA Ethernet problems with 4.3BSD
Date: Fri, 15 Aug 2008 15:09:36 -0500
From: david.hittner at ngc.com
To: royhills at hotmail.com; simh at trailing-edge.com

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! 

_________________________________________________________________
Win a voice over part with Kung Fu Panda & Live Search   and   100’s of Kung Fu Panda prizes to win with Live Search
http://clk.atdmt.com/UKM/go/107571439/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20080815/763f77b0/attachment-0003.html>