• Please review our updated Terms and Rules here

A modern Linux hates (bridging) vintage BSD! Any old Ethernet experts know why?

S

stepleton

Veteran Member
Joined
Jan 1, 2020
Messages
533
Location
London, UK
We all knew the rivalry was real! (Heck, netcraft confirmed it!) (old joke)

For months I've been connecting my mid-1980s 4.2BSD box (one of these) to the Internet (in a very limited way!) through a Raspberry Pi (acting as an Ethernet bridge) and an Amazon AWS host. This has allowed me to serve webpages to the open internet from the ancient machine, which was good fun.

A recent update to the Pi's OS has changed all this. The Pi will happily be a bridge for a modern Linux box, but it refuses to pass along Ethernet frames from the old BSD machine! I've tried to understand the problem but have not had much success.

If you think you know your Linux networking, then I have a challenge for you! https://unix.stackexchange.com/ques...ackets-from-a-vintage-bsd-machine-but-packets
I've done some pretty detailed investigating there --- check it out if you like a nice ASCII-art diagram.

But it could be that the crucial knowledge lies in the wisdom of the retro community. Can anyone think of any difference between the commodity Ethernet frames of 1986 and the ones we get today? I've done some hexdumps of ping exchanges involving the old machine (see the link above for more context, though), and they don't really look any different to me to exchanges with a modern computer!

In other words, just looking at ping packets and their data link (Ethernet) headers, I can't even tell how Linux on the Raspberry Pi is detecting that the old BSD machine is any different from a new computer. But maybe you know: is there a difference that I'm missing somehow? Some change to Ethernet over 3.5 decades that's made it possible to discriminate? This has been a real mystery!
 
stepleton said:
The Pi will happily be a bridge for a modern Linux box, but it refuses to pass along Ethernet frames from the old BSD machine! I've tried to understand the problem but have not had much success.
Click to expand...

How does it know?

Why would it care?

Have you tried routing something else besides the BSD box in the same way? Another R Pi, perhaps?
 
Network communication can be very complicated, and details are very important.

It could be something as simple as BSD setting or not setting some bit where it really shouldn't matter, and suddenly a "modern" TCP/IP stack filters it out, interpreting it as a potential denial or service attack or exploit attempt.

First I would double check all the standard settings involved.

I would check and see if anything related to fire walling has changed and needs configuration.

I'm not familiar with whatever OS this PI runs, but if there are archived nightly builds, you might try narrowing down when things broke, and inspect change logs.

You might have to get down to the packet sniffing level and see what is different between a Linux box.
 
Perhaps my own experience (and frustration) might shed some light.

Some time back, I had a great idea of using an Orange Pi Zero as a Wifi-to-ethernet bridge. The thing was cheap ($10), fast (1.2GHz quad-core) with 512K of memory and had Wifi built in as well as an ethernet connection. Ideal, right? Just toss on a "wall wart" for power and Bob's your uncle. Or so I thought.

I loaded up Armbian (Buster, I think, but I'd have to check) and got down to work. No soap with declaring a bridge to Wifi; dnsmasq wouldn't do it. I eventually gave up after I could find nobody using that release of Armbian with a working configuration.

I invested in a couple of $15 Wifi Range expanders (with ethernet jack) and got them to work within minutes as bridges to Wifi. Still using them today.

Just saying that if this involves Wifi and Armbian, it may not be you.
 
Thanks for the thoughts, all.

Just to get the website back up, I've abandoned the Ethernet bridging approach for now and settled for a chain of reverse web proxies. There's a proxy that runs on the AWS host, which calls on a proxy that runs on the Raspberry Pi, which calls on the webserver running on the old BSD machine. As such, http://mg-1.uk:31132 rides again!

This is probably all fine --- the old computer is surely the slowest link in the whole chain, so another proxy server won't be impacting performance too much.
Now, I'd like to get true Ethernet bridging working again, but I guess this will do for now.

I'm inclined to suspect SomeGuy's interpretation is correct --- that some bit somewhere is messed up. lowen's suggestion that it could be something to do with Ethernet II vs 802.3 frames is interesting: I think we're dealing with Ethernet II frames; you can see what looks like a good match in the ping exchange hexdumps I linked to.

Those hexdumps are the most frustrating thing... there aren't many bits that aren't accounted for in them, and everything looks pretty reasonable if you manually decode the hex. I can see nothing suspicious. From what I can tell, only the Ethernet frame's preamble, start-frame delimiter, and CRC are missing.

I'm finding it hard to tell online, but there's a chance that the start-frame delimiter differs between 10BASE-T (which the old machine uses) and 100BASE-T (which my modern Linux box uses). If that's so, then it's one possibility for a distinction between the two machines. I suppose I could force my Linux box to use 10 MBit networking and see if that affects anything.

ETA: I think the start-frame delimiter can't matter. The NIC doesn't share it with the operating system, so if the Ethernet frame is already making it into the bridge (it is), then it can't be a factor. Also, I'm even more certain that we're dealing with Ethernet II frames.
 
Last edited:
If you want to connect to the internet, just use the RasPI. Doesn't that make the most sense?

IT'S A JOKE

I haven't a clue what that box is. But it looks astounding. Shock and awe.

Ok, it would seem you're using a flat panel for output. I'm less impressed and hurt. A workstation like that deserves a mondo monochrome crt. It's only right.

ok, perusing the docs you provided. Holy crap. I'm impressed again. You really should source a crt though :)
 
Last edited:
Never fear, we have the original CRT. But it draws power from the computer over the same cable as the video signal, and it has no off switch. Since the MG-1 is running all the time these days (it could wind up serving literally dozens of HTTP requests each week), using the CRT would mean having it be on all the time. Also, the computer's GUI has no screensaver.

TL/DR: I'm conserving the CRT by using the flatscreen instead.
 
They're pretty rare. I don't know that they made all that many, and all of them shipped with NiCd batteries that have had predictable consequences today. It also sounds like contemporary workstations (Sun etc.) got faster fairly quickly, so people may not have wanted to hold onto the machines so long.

Originally they shipped with a version of GENIX (4.1BSD) that National Semiconductor made for the NS32016 processor. Eventually they replaced it with a custom 4.2BSD variant called 42nix. Both OSs gave the user a pre-X Windows GUI, as far as I can tell. (I've only ever used 42nix.)

(They were big fans of Hitchhiker's Guide, so "42"nix. Also, MG in MG-1 stands for Milliard Gargantubrain, or so they say.)
 
You must log in or register to reply here.
Back
Top