<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Mark,<br><br>Many thanks for taking the time to look into this and determine the problem.<br><br>Your explanation fits the symptoms I'm seeing, as I suspect that the 4.3BSD DEUNA driver is not initialising<br>the source address part of the Ethernet frame, and this therefore contains some random data which then<br>gets used as the source address.<br><br>If the DEUNA uses its own device MAC, how does it work with DECnet which changes the MAC<br>address to AA-00-04-00-xx-yy? This is not an issue for me, as I only want to use TCP/IP, but it might<br>be for people running VMS.<br><br>Did you manage to look at the second issue that I found, namely that the DEUNA appeared not to<br>pass broadcast traffic to the OS? I found that the system would not respond to ARP requests, and it<br>looked like the OS was never seeing the broadcast frames.<br><br>Roy<br><br>> Date: Mon, 15 Sep 2008 15:49:32 -0700<br>> From: mark@infocomm.com<br>> Subject: Re: [Simh] VAX-11/780 DEUNA Ethernet problems with 4.3BSD<br>> To: royhills@hotmail.com<br>> CC: mark@infocomm.com<br>> <br>> Roy,<br>> <br>> There is indeed a problem here. You can use a combination of Wireshark on the simh Windows machine to verify the same unusual source mac addresses without the specific need for a distant tcpdump agent.<br>> <br>> The odd thing is that networking works at all. <br>> <br>> The DEUNA, being a very early ethernet NIC, is somewhat unique. All modern NICs provide a means for a host computer (the VAX780 running any OS) to send and receive complete ethernet frames. The host presents the complete packet for transmission (including the destination and source MAC addresses). The NIC is responsible for computing and providing the frame CRC while transmitting the packet on the wire, and for checking it on received packets, but it doesn't mess with the source/destination MAC addresses in the packet header on packets sent or received. <br>> <br>> The DEUNA/DELUA, as I said above, being early NIC implementations are unique in that they actually insert the device MAC address in the source address part of the outgoing packet (instead of counting on the host driver software to perform this operation). The bug is that the original code presumed that the OS would provide the MAC address. The fix is for the emulated DEUNA to insert it into the source address of the outgoing packet like the DEUNA/DELUA documentation says in section 4.6/4.8.<br>> <br>> I've got a working fix. I'll submit this, along with several other changes I've been working on for inclusion in a simh future version. I'm trying to get these changes built cleanly across the platforms I can test on, so I'm not ready to submit these. I'll see if I can zip up the changed files and send them to you in the next few days.<br>> <br>> - Mark<br><br><br /><hr />Get Hotmail on your mobile from Vodafone <a href='http://clk.atdmt.com/UKM/go/111354028/direct/01/' target='_new'>Try it Now</a></body>
</html>