DELUA on Ethernet
We're still under SimH!
My 11/44 has a DELUA network card (M7521 AA). It is brand new: youngest chip date on it is 1990!
2.11BSD accepts it without trouble: I build a kernel with
NDE 1 # DEUNA/DELUA
...
INET YES # TCP/IP
NETHER 1 # ether pseudo-device
in the configuration file, and on next boot it complained a lot about register and reset problems with the newtwork device.
The status LEDs on the DELUA indicated a “LANCE external loop back test”. After I connected the DELUA to an external bulkhead with BNC transceiver and plugged it onto a well-terminated BNC cable segment, the LED codes were good and 2.11BSD came up without any errors.
The DELUA appears as device “de0”.
Network setup on SimH
To get a network card in SimH, you have to compile it with USE_NETWORK=1 and install the PCAP libray. (PCAP means “packet capture” and allows low level access to network traffic). Tests on WinXP with WinPCAP failed, I let SimH run on an Ubuntu instead.
Before you compile, install “libpcap.a”:
- Install the packet “libpcap0.8-dev” to get a libpcap.a in /usr/lib.
-
$ sudo ln -s /usr/lib/libpcap.a /usr/local/lib
-
$ make USE_NETWORK=1 pdp11
Edit the SimH startup script:
sim> set xu enabled
sim> set xu type=delua
sim> sh xu eth ;(list network cards, check network support of SimH)
sim> att xu0 eth0
sim> sh xu mac
Start SimH with administrator rights:
$ sudo ~/simh/pdp11 script.sim
Now boot into 2.11BSD. The boot message should show connected network devices de0 and lo0:
2.11 BSD UNIX #3: Fri Jun 9 04:13:24 PDT 1995This email address is being protected from spambots. You need JavaScript enabled to view it. :/usr/src/sys/SYSTEM
attaching de0 csr 174510
attaching lo0.
I had to relink /vmunix, else netstat will no run
rm /vmunix
ln -s /unix /vmunix
Networking parameters
You must define a few values, I give you mine:
device of network adapter = “de0”
hostname = “pdp1144”
name of local network = “intern”
address of the PDP-11: 192.168.1.44
address of my router, which is also nameserver: 192.168.1.10
address mask = 255.255.255.0
So this should work:
# ifconfig de0 netmask 0xffffff00 192.168.1.44
# ifconfig de0
de0: flags=43
inet 192.168.1.44 netmask ffffff00 broadcast 192.168.1.255
If this worked once, edit “netstart” and set these parameters there.
hostname=pdp1144
netmask=255.255.255.0
broadcast=192.168.1.255
default=192.168.1.10
“default” is your router, the address of my one is 192.168.1.10 (see below)
And make sure, the enabled “ifconfig” statement works on “de0” !
netstart is executed when the system enters multi user level.
You should also write your router’s address into “/etc/resolv.conf”. My “resolv.conf contains this:
domain intern
search intern
nameserver 192.168.1.10
And edit /etc/hosts:
FTP server
ftpd is started by default by a line in /etc/inetd.conf.
arp Troubleshooting story
First test where, good, but soon I noteced a problem:
My 11/44 lost connectivity to other host on the local network in irregluar intervals. This happened in SimH and on the physical machine, so a lot of influences could be ruled out. Problem must be related to the 2.11BSD installation alone.
I bought the TCP/IP book (yes, O’Reilly’s) and looked at packets with WinShark. The problem turned out to be missing ARP responses from my 11/44.
Lets call the PDP-11/44 “pdp1144” and another test host “bigfoot”.
ARp protocoll guarantees that every local node has the ethernet address of every host it needs to send packets to. If “bigfoot” pings “pdp1144”, it recognizes from ip-mask that tey are on the same ethernet, and it can send them enterhent packets directly, if it knows its ethernet MAXID. If bigfoots arp cache is aged out, it first sends an arp-broadcast ethernet packet to get “pdp1144”’s MAC-ID again. If “pdp1144” does not answer, connectivtiy to it is lost. The aging tim is between 2 Minutes for Windows hosts and 20 Min for my LANCOM router .... so I lost local connectivitys after 2 minutes and remote connectivity after 20 minutes ... very irritating for five days!
Arp has one intelligent feature: in apr requests the sender transmit also its ehternet address. So if pdp1144 requests from bigfoot the MAC-ID, it tells bigfoot its MAC-ID at the same moment. So if the arp-cahe on pdp1144 is deleted, and then pdp1144 pings bigfoot, bigfoot receives an arp request from pdp1144, and knows pdp1144 MAC-ID in the same moment.
So apparently pdp1144 re-establishes a connection to bigfoot, even if pdp1144 does not answer bigfoot’s arp requests. Logical, but hard to debug.
I made a test in SimH: I switched from simulated 11/44 with DELUA to an 11/73 with DELQA. Then arp responses got answered! So the bug is related in the DELUA driver in 2.11BSD. Its source is sitting in /sys/pdpif/if_de.c.
I found the DELUA drivers for 2.11BSD in /sys/pdpif/if_de.c and peppered them with “printf()”. Ethernet broadcast with “ARP” request did not triggered interrupts on the sumualted DELUA, so I suspected broadcast packets to get eaten inside the DELUA.
I also switched network debugging on in SimH:
set xu debug
set cons debug=stdout
I did a “ping pdp1144” from “bigfoot, and saw arp request in wireshark. But I never saw packets with “dst: broadcast” in the SimH log.
Diving into the simulated DELUA
I explored the simulated DELUA in SimH and found that on every received packet eth_callback() in sim_ether.c was called. If you #undef USE_BDF, packet filtering is done here (and not in thep pcap layer). Soon I found that adding this code
int is_broadcast ;
for (is_broadcast =1, i=0 ; i < 6 ; i++)
is_broadcast &= (data[i]==0xff) ;
if (is_broadcast) to_me = 1 ;
into ether_callback() let my 2.11BSD answer arp requests! So the problem narrowed down to:
“Why does DELUA not respond to ethernet broadcasts?”
Patching the DELUA in SimH was no option, beause: my real DELUA had the same behaviour. The 2.11BSD driver did not setup DELUA right!
Filtering code in SimH’s “eth_callback()” consists of three terms:
for (i = 0; i addr_count; i++) {
if (memcmp(data, dev->filter_address[i], 6) == 0) to_me = 1;
if (memcmp(&data[6], dev->filter_address[i], 6) == 0) from_me = 1;
}
/* all multicast mode? */
if (dev->all_multicast && (data[0] & 0x01)) to_me = 1;
/* promiscuous mode? */
if (dev->promiscuous) to_me = 1;
Each of “filter_address[]”, “all_multicast” or “promiscuous” could be ill configured by the 2.11BSD DEUNA driver in “if_de.c”.
1st approach: the code for managing of multi cast addresses is not active in 2.11BSD by default. This prohibits the kernel to set and delete multicast addresses in the DELUA. Maybe the kernel wanted to set the ethernet broadcast address FF:FF:FF:FF:FF:FF and could not do it?
I set DE_DO_MULTI in “pdpif/if_de.c”, recompiled the kernel, rebooted ... nothing changed, the broadcast address FF:FF ...FF did not occur in the simulated DELUA’s multicast table, so arp request were not answered.
2nd approach: the “all_multicast” flag. It is set in the mode register od DELUA. So auxilliary function code is “WSrite Mode register” = 15. In “if_de.c”, the code is FC_WTMODE. The mode ist only set in deinit(), the mode flag MOD_ENAL for “all_multicast” is not set in the line “ds->ds_pcbb.pcbb2 = MOD_TPAD|MOD_HDX;”, so lets OR it in. Recompile kernel, reboot .... andrenalin very high ... “ping pdp1144” ..... YAAHOO!
Was this the right patch? I checked the DELQNA code in if_qe.c, because the DELQNA run fine. DELQNA seems not to get the “all_multicast” flag set, it gets a list of target adresses defines in function qesetup(). As EQ-DEQNA-UG-002 states: “At least one address must be the node’s physical address, and one must be the broadcast address”.
So it would be better to set FF:FF:FF:FF:FF:FF as one multicast addr. With “all_multicast”, the system must filter out more ethernet pakets, if really other mutlicast pakets occupy the net, which is not very likely.
SimH community
Later I mailed this patch to the SimH community. The source file pdp11/pdp11_xq.c was updated ... search for the entry "10-Sep-09 DTH Added broadcast control to eth_filter" in the revision history.