BSD 2.11 networking on PiDP11 new install not working

[Richard McDonald]

This is probably something I munged, but for the life of me I can't find the problem.

I started with a Bookworm RPi OS image install on a Pi5 with an NVME drive WITHOUT Oscar's hardware front panel.

I have tried to use Terri's new installation scripts (https://github.com/Terri-Kennedy/pidp11) which yield a working PDP11 simulation from which I can start 211BSD+.  

All seems fine until I configure the networking, where the only thing I can ping with a return is 127.0.0.1 and localhost.  

When I ping any other host in /etc/hosts, the appropriate address is resolved but no return.

Cheers,

Rich

[Johnny Billquist]

Did you build a 2.11BSD kernel matching your hardware?

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> pidp-11/970ab017-f4e4-47ac-95f4-db584ae8ddean%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/970ab017-f4e4-47ac-95f4-
> db584ae8ddean%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Richard McDonald]

Hi Johnny,

No, I haven't done anything on the BSD side, other than configure /etc/hosts, /etc/resolv.conf, and /etc/netstart as indicated in the installation instructions.  

I was under the impression that the simh took care of providing the proper devices, so I did compile the simh binaries on the RPi5 as part of the installation script.

Cheers,

Rich

[Johnny Billquist]

This (unfortunately) don't have anything to do with simh as such.

Depending on the 2.11BSD kernel, of course. If you have some prebuilt
system specifically configured for some hardware, you might be all good.
However, if you are just running the GENERIC kernel, it has no ethernet
drivers included.

Check with "uname -v" and see what the path to the kernel is (last part
of the output).
My machine says:
simh:/sys/conf> uname -v
2.11 BSD UNIX #63: Fri Mar 14 17:29:28 CET 2025
b...@simh.BQTnet.SE:/usr/src/sys/Test
simh:/sys/conf>

which means it was built from a system configuration called "Test". If
yours say "GENERIC", then you will need to do a build.

In the configuration file for GENERIC (/usr/src/sys/conf/GENERIC), it
looks like this:

NPTY 0 # pseudo-terminals - GENERIC sys needs NONE

NEC 0 # 3Com Ethernet
NDE 0 # DEUNA/DELUA
NIL 0 # Interlan Ethernet
NSL 0 # Serial Line IP
NQE 0 # DEQNA
NQT 0 # DEQTA (DELQA-YM, DELQA-PLUS)



You need to say a "1" on the type of ethernet controller you have. And
then probably tweak a few other numbers in there as well. Check the
whole file.
And once that's done, run config over it, and build the kernel.


If you are not on GENERIC, then you need to make sure that simh is
configured to match the kernel that you are running. The primary
question is if you're a Unibus or Qbus system, since the ethernet
controllers are completely different between those systems.

netstat -i

is another good command to use, to check what interfaces you have that
the kernel knows of. If you are on Unibus, you hopefully would have a
"de0", and if Qbus hopefully a "qe0" or "qt0".

You can then do a "ifconfig de0" (or whatever interface) to see if it's
up, running, and reasonably configured.

On my machine:

simh:/sys/conf> netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
de0 1500 192.168.1 simh 200603 0 31488 0 0
lo0 1536 localnet localhost 10 0 10 0 0
simh:/sys/conf> ifconfig de0
de0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
inet 192.168.1.30 netmask 0xffffff00 broadcast 192.168.1.255
simh:/sys/conf>



Then you also should check /etc/netstart. There you have parameters like
what IP address to use, gateway and all such stuff, as well as you
should uncomment the line matching your interface name.


Again, maybe you have a system that have all been set up, and all this
is already in order. I don't know, so I'm trying to give all possible
steps and potential sources of problems.


Finally, I hope you are not using WiFi and just directly connect simh to
your network interface, because that is also problematic.


Johnny

On 13/01/2026 18.43, Richard McDonald wrote:
> Hi Johnny,
>
> No, I haven't done anything on the BSD side, other than configure /etc/
> hosts, /etc/resolv.conf, and /etc/netstart as indicated in the
> installation instructions.
>
> I was under the impression that the simh took care of providing the
> proper devices, so I did compile the simh binaries on the RPi5 as part
> of the installation script.
>
> Cheers,
> Rich
>
> On Tuesday, January 13, 2026 at 8:12:45 AM UTC-8 b...@softjar.se wrote:
>
> Did you build a 2.11BSD kernel matching your hardware?
>
> Johnny
>
> On 13/01/2026 16.23, Richard McDonald wrote:
> > This is probably something I munged, but for the life of me I
> can't find
> > the problem.
> >
> > I started with a Bookworm RPi OS image install on a Pi5 with an NVME
> > drive WITHOUT Oscar's hardware front panel.
> >
> > I have tried to use Terri's new installation scripts (https://

> > github.com/Terri-Kennedy/pidp11 <http://github.com/Terri-Kennedy/
> pidp11>) which yield a working PDP11 simulation

> > from which I can start 211BSD+.
> >
> > All seems fine until I configure the networking, where the only
> thing I
> > can ping with a return is 127.0.0.1 and localhost.
> >
> > When I ping any other host in /etc/hosts, the appropriate address is
> > resolved but no return.
> >
> > Cheers,
> > Rich
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "[PiDP-11]" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to pidp-11+u...@googlegroups.com
> > <mailto:pidp-11+u...@googlegroups.com>.
> > To view this discussion visit https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > pidp-11/970ab017-f4e4-47ac-95f4-db584ae8ddean%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/pidp-11/970ab017-
> f4e4-47ac-95f4- <https://groups.google.com/d/msgid/pidp-11/970ab017-
> f4e4-47ac-95f4->
> > db584ae8ddean%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> e712b466-72bd-4c50-bfd0-337eb17750e5n%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/e712b466-72bd-4c50-
> bfd0-337eb17750e5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Clem Cole]

below.

On Tue, Jan 13, 2026 at 12:43 PM Richard McDonald <ranc...@gmail.com> wrote:

I was under the impression that the simh took care of providing the proper devices, so I did compile the simh binaries on the RPi5 as part of the installation script.

It does >>if<< you tell it to. From the Raspbian shell prompt: 

cd /opt/pidp11/systems/211bsd

using an editor, more or cat, look at the boot.ini file in that directory, and look for these lines:

set xu enabled
set xu type=delua
attach xu eth0
;attach xu tap:tap-simh0

sh xu
sh eth

Assuming you have those lines to configure the device in your boot.ini file, then simh has a DELUA Ethernet controller in its configuration SIMH device 'xu'

The first line is assuming that simh can open the real Ethernet; the second version assumes the tap driver.   Read Section 2.12.1 Ethernet Controllers in the pdp11_doc.doc file and look at the file: 0readme_ethernet.txt for more details of how to configure Linux and SIMH to play nice.

Assuming you have access to eth0 or a tap0 device, the issue is ensuring that UNIX finds the DELUA and starts networking, which is running in a different mode (Supervisor) than the kernel (Kernel).

[Richard McDonald]

Thanks all, some understanding gained, if not progress.

The PI5 has a hard-wired ethernet connection to a switch grabbing a DHCP address locked to the PI5s MAC address.  The PI5 shows ...

pi@kodi5-mh-rpios64:/opt/pidp11/systems/211bsd+ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d8:3a:dd:cf:55:e4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.17/24 brd 192.168.111.255 scope global dynamic noprefixroute eth0
       valid_lft 81402sec preferred_lft 81402sec
    inet6 fe80::6f12:59ef:1f19:6791/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether d8:3a:dd:cf:55:e5 brd ff:ff:ff:ff:ff:ff

 My boot.ini has ...

set xu ena
set xu type=delua
; set to your network interface
att xu eth0

as the relevant entries.  Your ( cl...@ccc.com's ) example shows additional entries of ..

sh xu

sh eth

Are these 2 lines relevant?

A couple of years ago, I had to make some adjustments to share the one ethernet with both the RPi OS and the SIMH connection.

Cheers,

Rich

[Charles Ess]

Hi all, 
I was also having the same trouble, despite the usual great help from here as well as directly from Flavio. For whatever reasons, however, the instructions in the manual  and Flavio's variations just were not working; nor, as it turned out, was it necessary to rebuild the kernel. The key connection point - de0 - was already in the "stock" 211bsd+ kernel - but needed enabling to make the rest work.

It took a lot of guessing from both the stochastic parrot and me, with both of us sometimes wildly off. But the end result is fairly straightforward: recipes and notes attached.

It also works without an ethernet cable plugged in, FWIW.
This approach uses a different networking model - and it may well be that Johnny and others will have strong reasons to advise against it. Will be genuinely interested in and grateful to hear.
Looking forward to comments and suggestions for alternatives and improvements.

- charles

[Johnny Billquist]

Basically, that works just fine, and I've touched upon it before.
There are only a few caveats:

. This does not work for the PiDP unless you drag it forward to use a
"modern" version of simh. The one normally used by the PiDP-11 does not
have the NAT functionality. So you might need to choose between
networking this way or have a working front panel.
. You will not be able to connect from externally into the 2.11BSD
system, as it is behind a firewall. (This can be partially solved with a
little more configuration in the simh ini-file).

. Using 8.8.8.8 as DNS means any local machines you might have, which
your own DNS server knows about will not be knows.


Your recommendations for the netstart content, while not broken, are
sortof "weird". Just putting correct information in the variables are
just fine. Why rework the file extensively to just do the same it
already does anyway. Assign the correct values, and make sure the de0
line is uncommented. Your suggestion might actually lead people to even
remove the configuration for the lo0 interface, which certainly can
cause issues for them.



And a couple of other comments (sortof only half-related). This solution
might be a bit unsatisfactory for people using other OSes than 2.11BSD,
because this solution will basically make DECnet and LAT not usable. You
can still tunnel DECnet out if you are running RSX, but beyond that,
this solution is basically TCP and UDP only (not even ICMP works, if I
remember right).


But I think the primary issue is basically that the simh version used by
the PiDP-11 does not have this functionality. :-D

Johnny

>     inet 127.0.0.1/8 <http://127.0.0.1/8> scope host lo

>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host noprefixroute
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP group default qlen 1000
>     link/ether d8:3a:dd:cf:55:e4 brd ff:ff:ff:ff:ff:ff

>     inet 192.168.111.17/24 <http://192.168.111.17/24> brd

> using an editor, more or cat, look at the boot.ini filein that

> directory, and look for these lines:
> set xu enabled
> set xu type=delua
> attach xu eth0
> ;attach xu tap:tap-simh0
>
> sh xu
> sh eth
>
> Assuming you have those lines to configure the device in your

> boot.inifile, then simh has a DELUAEthernet controller in its

> configuration SIMH device 'xu'
> The first line is assuming that simh can open the real Ethernet;

> the second version assumes the tap driver.   Read*Section 2.12.1
> Ethernet Controllers* in the pdp11_doc.doc <https://github.com/
> open-simh/simh/blob/master/doc/pdp11_doc.doc> file and look at
> the file: 0readme_ethernet.txt <https://github.com/open-simh/
> simh/blob/master/0readme_ethernet.txt> for more details of how

> to configure Linux and SIMH to play nice.
>

> Assuming you have access to eth0or a tap0device, the issue is

> ensuring that UNIX finds the DELUA and starts networking,which
> is running in a different mode (Supervisor) than the kernel
> (Kernel).
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> c9bf9640-5066-4709-885c-e54dd951d720n%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/c9bf9640-5066-4709-885c-
> e54dd951d720n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Charles Ess]

Great - many thanks on all fronts, and, as usual, you've inspired me to go back and try some alternatives in the directions you're suggesting, starting with fiddling with the DNS and the lo0 interface. (I also thought it was weird and arbitrary at points - it says something about the limits of LLMs such as ChatGPT that even I can notice when it's heading off in odd directions and/or is flat out wrong.)

FWIW: I didn't do anything to tweak the SIMH that came with the most recent install, so I'm not sure what might be going on in this direction? 
For that, the front panel lights are working as they should.
In all events, again, many thanks as per usual and looking forward to tinkering more in the coming days.

all best - c.

[Johnny Billquist]

Maybe someone can clarify what the status of simh in the PiDP-11 is
then? Because it used to be based on a pretty old version of simh which
lacked a lot of more recent development.
But if it works for Charles, then it would seem that the PiDP-11 have
been updated to a more recent simh?

Johnny

> >     inet 127.0.0.1/8 <http://127.0.0.1/8> <http://127.0.0.1/8

> <http://127.0.0.1/8>> scope host lo
> >        valid_lft forever preferred_lft forever
> >     inet6 ::1/128 scope host noprefixroute
> >        valid_lft forever preferred_lft forever
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> > state UP group default qlen 1000
> >     link/ether d8:3a:dd:cf:55:e4 brd ff:ff:ff:ff:ff:ff
> >     inet 192.168.111.17/24 <http://192.168.111.17/24>

> <http://192.168.111.17/24 <http://192.168.111.17/24>> brd

> pidp-11/ <https://groups.google.com/d/msgid/pidp-11/>
> > c9bf9640-5066-4709-885c-e54dd951d720n%40googlegroups.com
> <http://40googlegroups.com> <https://
> > groups.google.com/d/msgid/pidp-11/c9bf9640-5066-4709-885c-
> <http://groups.google.com/d/msgid/pidp-11/c9bf9640-5066-4709-885c->
> > e54dd951d720n%40googlegroups.com?

> utm_medium=email&utm_source=footer <http://40googlegroups.com?
> utm_medium=email&utm_source=footer>>.
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/74c98aef-9fce-4c45-8812-57605d96490an%40googlegroups.com
> <https://groups.google.com/d/msgid/
> pidp-11/74c98aef-9fce-4c45-8812-57605d96490an%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[terri-...@glaver.org]

On Friday, January 30, 2026 at 9:11:13 AM UTC-5 b...@softjar.se wrote:

Maybe someone can clarify what the status of simh in the PiDP-11 is
then? Because it used to be based on a pretty old version of simh which
lacked a lot of more recent development.
But if it works for Charles, then it would seem that the PiDP-11 have
been updated to a more recent simh? 

You can't tell, because neither simh/simh nor open-simh/simh  appear to produce 

"releases" in any sense of the word that you or I would understand.

Right now, my PiDP-11 development fork reports itself as:

sim> sh ver
PDP-11 simulator V4.0-0 Current  REALCONS build Jan  4 2026
[...]

git commit time: $Format:%aI$

Ignore the build date because that's the last time I built the kit, and if you select

the compile option you'll get whatever time  you compiled.

About all I can say is it is likely an old branch of simh (not open-simh), but I have

no idea when the code was forked. The "git commit time" is a complete bork.

Neither group is interested in reproducible builds, apparently considering them

a fad not worth pursuing, despite the security implications.

And I have no idea how on earth a "git clone" could produce a monstrosity of

a version string like:

PDP-11 simulator Open SIMH V4.1-0 Current git commit id: 6e9324e0+uncommitted-changes

What could "+uncommitted-changes" possibly mean when cloning from a git

repo? They are either commits or they aren't. This is standalone open-simh,

not part of the PiDP-11, BTW.

At least that build reports:

git commit time: 2025-09-10T21:52:47+0300

So at least we know what code base it came from.

That's a build I did that forces reproducible builds, though it seems unlikely

that either upstream will implement that in their respective repos.

My plans for the PiDP-11 (which Oscar appears to agree with) are:

V2: New installer, updated installation procedures, more available options, more

       bugfixes
V3: Updated simh based on open-simh du jour with realcons mods

V4: Fixing the terminal emulators

Although V3 and V4 may swap. But I think having a modern simh is more

important overall than working terminal emulators (very few people have

complained that the terminal emulators have been broken since Oscar's

move to GitHub - which coincided with the "start inside screen" borrowed

from the PiDP-10).

[Johnny Billquist]

Well, my question wasn't about simh versions as such, but what PiDP-11
is using. Which, if someone have made a newer version than what the
PiDP-11 have been at for ages, should be possible to tell. Even if an
exact version can't be pinpointed. (And yes, I agree about the git
version strings, completely unreadable, and not easy to make sense of.)

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/7581cf31-325c-46fb-89c9-2b12efd9d3e5n%40googlegroups.com
> <https://groups.google.com/d/msgid/
> pidp-11/7581cf31-325c-46fb-89c9-2b12efd9d3e5n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Anton Lavrentiev]

> What could "+uncommitted-changes" possibly mean when cloning from a git repo?

It means that after cloning the repo, you changed something in your
local copy (and haven't committed the changes back) prior to building
the executable files.
Basically if "git status" doesn't show that your local tree is up to
date with the repo, you'll get the "uncommitted changed" appendage in
the version output.

> --
> You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/7581cf31-325c-46fb-89c9-2b12efd9d3e5n%40googlegroups.com.

[terri-...@glaver.org]

On Saturday, January 31, 2026 at 10:41:44 AM UTC-5 Anton L. wrote:

> What could "+uncommitted-changes" possibly mean when cloning from a git repo?

It means that after cloning the repo, you changed something in your
local copy (and haven't committed the changes back) prior to building
the executable files. 

I believe I got that version string before I changed anything on my end to make the build

reproducible (just "git clone' and 'make'), but it was quite some time ago. Doing it using

today's open-simh repo doesn't introduce that, so I guess I'm wrong.  

[terri-...@glaver.org]

On Saturday, January 31, 2026 at 5:41:10 AM UTC-5 b...@softjar.se wrote:

Well, my question wasn't about simh versions as such, but what PiDP-11
is using. Which, if someone have made a newer version than what the
PiDP-11 have been at for ages, should be possible to tell. Even if an
exact version can't be pinpointed. (And yes, I agree about the git
version strings, completely unreadable, and not easy to make sense of.)

Understood. I was just trying to (unsuccessfully) point out that neither of

the two possible parent projects update their version numbers, so you

can't tell what simh commit (that was modified into the REALCONS and

then modified some more and distributed with the PiDP-11) was.

We can guess that it was simh and not open-simh based on the version

number, but that's just a guess - the open-simh repo doesn't have any

backpointers to the simh repo (its GitHub page doesn't show it as a fork

of simh).

And since development of both the REALCONS and its PiDP-11 offspring

were done outside of GitHub, there's no commit history until the PiDP-11

code went back to GitHub (after I'd bugged Oscar for that for ages), so

again all commit history was lost. There were very few commits to the

obsolescence/pidp11 GitHub (mostly "Update README.md)" since it went

back to GitHub. I asked Oscar about a few things (for example, there's a 

comment in a source file saying "fixed bug with front panel going dead

except for knobs" (or something like that) that also appears as a GitHub

commit, but the matching code change didn't make it in and Oscar doesn't

remember what he changed.

That's why the plan is to keep everything in GitHub with a full version

history maintained (from the point Oscar handed maintenance to me).

At the point where I import open-simh + REALCONS (which will likely be in a

separate repo for cleanliness of version tracking) we'll be able to track my

changes to the REALCONs fork and its changes from open-simh, so it will

be easy to see "this branch is X commits ahead/behind" of its parent and

keep things up-to-date in the future. A separate repo also makes sense as

many people want to just download and get "on the air" and the source

code is just extra stuff they don't need. But for those who want it, it will be

available as an option. But that's an installer V3 thing. I want to get the V2

installer done with the current codebase. I'm just waiting for some external

events to happen (while continuing development on the installer in the

meantime).