<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<STYLE>.hmmessage P {
PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px
}
BODY.hmmessage {
FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>
<META content="MSHTML 6.00.2900.3395" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>Well, the ethernet source address of aa:fd:00:00:00:00
is a DECNET-style address, so it indicates decnet is
running.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>When decnet starts, it *does* change the hardware mac
address to the decnet address. So i'm not sure that that behavior is
wrong.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>There is a strong warning by HP/Compaq/Digital to start
decnet before other protocols to prevent various networking issues related to
MAC identification.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>No one has ever really debugged the SIMH
DEUNA/DELUA driver ("XU"), or has given me reproducable test cases to
examine.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>The XU driver has just been noted as "working" by those
who have tried to use it, usally with TCP/IP only.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>I personally have not gotten the more-difficult DECNET
or SCS (Clustering) protocols working on it under OpenVMS.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>If you can give me some more information about your
entire host/client/network configuration, and about the behavior that you're
seeing, </SPAN></FONT><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>I''m willing to help you try to resolve
it.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>Having NO experience with UNIBUS machines, though, it
was hard for me to infer the hardware behavior of the XU DEUNA from the
specs.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>Assuming the aa.xx.xx.xx.xx.xx decnet mac address is
correct, the log seems reasonable (without in-depth
analysis).</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>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.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>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..</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>Dave Hittner</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008>SIMH Ethernet developer</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff><SPAN
class=441373819-15082008></SPAN></FONT> </DIV>
<DIV dir=ltr align=left>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr align=left><FONT face=Tahoma><B>From:</B>
simh-bounces@trailing-edge.com [mailto:simh-bounces@trailing-edge.com] <B>On
Behalf Of </B>roy hills<BR><B>Sent:</B> Friday, August 15, 2008 2:09
PM<BR><B>To:</B> simh@trailing-edge.com<BR><B>Subject:</B> [Simh] VAX-11/780
DEUNA Ethernet problems with 4.3BSD<BR></FONT><BR></DIV>
<DIV></DIV>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.<BR><BR>I've got two issues:<BR><BR>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.<BR><BR>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:<BR><BR>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<BR>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<BR><BR>2. The Ethernet adapter responds to packets sent to
its own address, but replies from seemingly random source
addresses.<BR><BR>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<BR><BR>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<BR>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<BR><BR>Sending another directed ARP request gets a reply with
a different source MAC address:<BR><BR>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<BR>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<BR><BR>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:<BR><BR>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<BR>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<BR>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<BR>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<BR>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<BR>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<BR>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<BR>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<BR>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<BR>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<BR>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<BR>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<BR><BR>The DEUNA configuration in the SIMH config file is:<BR><BR>set xu
enabled<BR>set xu mac=08-00-2B-12-34-56<BR>attach xu
\Device\NPF_{A390A62C-E18B-45FC-A99F-FB039C5B4032}<BR><BR>The SIMH system sees
the DEUNA at boot, and gets the correct MAC address:<BR><BR>de0 at uba0 csr
174510 vec 120, ipl 15<BR>de0: hardware address 08:00:2b:12:34:56<BR><BR>And
ifconfig shows the device OK:<BR><BR>de0:
flags=63<UP,BROADCAST,NOTRAILERS,RUNNING><BR>
inet 192.168.1.70 netmask ffffff00 broadcast 192.168.1.255<BR><BR>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.<BR><BR>Any ideas?<BR><BR>Roy<BR><BR><BR>
<HR>
Find out how to make Messenger your very own TV! <A
href="http://clk.atdmt.com/UKM/go/101719648/direct/01/" target=_new>Try it
Now!</A> </BODY></HTML>