Hi Paul,
The main test environment I am using is with 1 PC with 2 ethernet NIC’s each
connected to a separate IP router – with one being on the main Internet router
with a 192.168.0.x subnet UNA-0 and the other UNA-1 being on the private router
with the 192.168.10.x subnet. This hopefully should not be an issue in my case.
Thanks for the heads up though – and I will still need to check to see if I can
identify what MAC addresses XU, XUB do have – but as I have confirmed that the
NIC’s are on different segments I should be safe.
I also usually never ran up the DECNet software fully with just loading the
$CEX environment without starting DECNet Then the BQTCP code connects to each
device via ETHACP and initializes the IP interfaces – so I usually never ran
the DECNet Phase IV networking software side of things as I didn’t have a
second DECNet node to communicate with.
When I couldn’t get anywhere with XUB I shutdown the unibus simh environment
and created the separate Qbus system – with the 2 x DEQNA with just the $CEX
subsystem loaded and with XQ, XQB loaded found that both ethernet interfaces
worked ok with the 2 x DEQNA’s.
It was only after I had created the 2 independent simh configs with their own
unique disk sets that I realized that they should be able to communicate with
each other through winpcap via attaching XU with eth6 (internet router) and XUB
with eth5 (private lan router) with the qbus simh system attaching XQ with eth6
and XQB with eth5 the 2 systems overlaying the 2 system Network Interfaces
under Windows 10 That was done only as check to confirm the DECNet Phase IV
networking comms was fully working – and works with UNA-0, QNA-0, QNA-1 but not
UNA-1. I suspect that with only $CEX loaded in each simh RSX system that the
driver’s hard-coded MAC address applies with the XU and XQ drivers each having
unique MAC addresses (as do XUB and XQB) preventing the duplicate MAC address
problem occurring when on the same subnet.
If I restrict the unibus system to just loading $CEX (to activate the ethernet
interfaces (but not DECNet) and then startup the BQTCP software with DEBUG
enabled at separate times for each ethernet device I should be able to at least
work out what XUB is meant to be doing versus what it is doing by comparing
DEBUG from XU and XUB and maybe identify the underlying issue.
As both ethernet interfaces are configured to be initialized at a TCP/IP level
acquiring an IP address lease via DHCP there should be an initial sequence of
almost identical messages for each of the XU, XUB drivers which may provide a
further clue to this puzzling issue.
Thanks for your help – you’ve given me another aspect of the drivers that I
need to check to see what MAC addresses each interface has in this simh
environment plusconfirm that this is not the cause of XUB driver not working.
Regards
Geoff
From: Paul Koning <paulkon...@comcast.net>
Sent: Sunday, 28 July 2019 00:45
To: Geoff Conway <gcon...@bigpond.net.au>
Cc: simh@trailing-edge.com
Subject: Re: [Simh] Issue #731 - simh PDP11 RSX11M-PLUS Unibus 11/94 system
with 2 DEUNA ethernet device XUB not working
I haven't tried 2 UNA at all, and don't know RSX, but one thing to watch out
for: don't put two Ethernet interfaces on the same LAN if you're running DECnet
(Phase IV). The reason is that they will both set the same Ethernet address,
from the DECnet node address, so you have a duplicate address condition. If
both are connected to the same LAN segment this will make for a mess; if they
are connected to different segments of a switched Ethernet then many packets
will be lost as the switches keep changing their mind about where that address
is located.
paul
On Jul 26, 2019, at 11:26 PM, Geoff Conway <gcon...@bigpond.net.au
<mailto:gcon...@bigpond.net.au> > wrote:
Hi All,
I have just raised an Issue in simh #731 where when recent testing with a simh
PDP11/94 Unibus system with 2 DEUNA interfaces it was found that device XUB did
not initialize. Device XU worked normally. I have not yet been able have XUB
start fully – no matter what CSR/VEC combination I have tried. I believe the
current CSR & VEC are correct as they have been assigned – just that there
appears some internal disconnect within the XU driver where XUB channel just
does not do anything.
In the equivalent simh PDP11/93 Qbus system with 2 DEQNA both XQ, XQB worked
normally.
The details of the actual system configuration is in the Issues log. With the
absence of any messages from XUB it appears to be dead in the water – although
when running the simh environment with DEBUG enabled in both XU, XUB I found
that XUB stayed in xu_process_local() while the XU device had a lot of activity
– which was expected since XU was working normally whereas XUB was not.
Unfortunately as I am not familiar with the XU driver code I have not been able
to determine why the xub interface is not initializing correctly.
Regards
Geoff
_______________________________________________
Simh mailing list
<mailto:Simh@trailing-edge.com> Simh@trailing-edge.com
<http://mailman.trailing-edge.com/mailman/listinfo/simh>
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
