Ok, I've picked up two Soekris net4801s. Lovely little boxes!
Installing OpenBSD on them via PXE was trivial. One interesting point was that I was running them from a 6v power supply, since the thing requires from 6 to about 28 volts. Presuming this to mean there's a linear regulator within generating a 5v line, I ran it from 6v to reduce the losses in the linear reg.
Anyway, all was well, until the box started to refuse to reboot. I was puzzled for a while, then I increased the voltage on my (cheap, unregulated) power supply unit. At first I thought my cheap little power brick was probably undervolting, but when all power to the area went down (including the streetlights on the A127!), it occured to me that perhaps the mains power might have been a little under 240v anyway 🙂
I got two of them, one for the original transparent firewalling application, and another to play with that I've decided to use to replace my current home LAN router - a 486 desktop machine running NetBSD. I'm using Ethernet bridging to make it appear like a three-port Ethernet switch linking the DSL router, my DMZ network, and my internal network; the internal machines use a private IP range, while the DMZ network machines have both private IP and public IP addresses; the Soekris box acts as a packet-filtering transparent firewall between the three LANs, while also being a NAT router between the private IP range and a public IP address.
This all works fine, except that if a DMZ machine tries to talk to the internal IP address of the router (which runs a DNS server), the response comes back from the external IP of the router, and with a different source port, so isn't recognised by the DMZ machine as being a valid reply. I've worked around it by getting the DMZ machines to use the router's external IP as their DNS server, and telling the router to allow access to the DNS server via the external IP only from the DMZ, and moving more interface-dependent services like DHCP and broadcast NTP off of the router to a DMZ machine.
Oooh, while researching Proxy ARP for a transparent firewalls, I found out that the BSDs these days can do Ethernet bridging in-kernel. man brconfig, if you want more details.
Here's a handy writeup on using it to configure OpenBSD as a filtering bridge:
http://www.openlysecure.org/openbsd/how-to/invisible_firewall.html
You can use it to bridge across any number of interfaces, in effect creating an Ethernet switch. But don't try to do this with too many ports - x86 architectures don't tend to have the IO backplane bandwidth of dedicated switch hardware!
According to the man pages, NetBSD 1.6.1 doesn't actually let you use packet filtering, but OpenBSD does. OpenBSD is a good choice for a firewall anyway, since security folks like it and have tended to pump it full of useful packet filtering options.
So does anyone know a nice supplier of small computers that can run OpenBSD and have two or more Ethernet interfaces, a cool enough CPU to not need a fan, and a flash disk that can be made readonly in hardware? A packet filter is, by definition, a single point of failure in a system, so I'd like it to be a maintenance-free device. Particularly since, lacking an actual IP address, it can't easily be contacted to check its status all that often...
Everyone has their own favourite supplier of rack mount kit, but these folks have stood me well over the past few years, so I thought I'd reward them with a plug:
Fairchild Industrial Computers and Internet Servers
You see, as both a computer nerd and a machinery nerd, one place that sells ruggedised industrial PCs (both embedded and touch-panel) as well as rack mounting machines is a bit of a boon.
And it so happens that, coming from an industrial computing background, their rack mount kit is rather solidly built. The cases have enough fans in that they make a noise not unlike a jet fighter taking off, but in a data centre, having a louder rack than everyone else is a positive status symbol. And it means they keep those CPUs and HDDs cool, with cooling capacity to spare if a fan or two fail, which is quite important when you're putting 1U machines in on top of each other - there's a lot of heat generation per unit volume.
Read more »
Today my mate Mike and I made new crucible tongs.
Check out my dodgy welds:
Read more »
Spurred by a thread on comp.os.research, I've been reading up on the Synthesis OS design.
Wiki page about Synthesis
The original thesis
This looks like good work, insipring for ARGON; with HYDROGEN explicitly exposing runtime code generation primitives, like any good FORTH system, and the CHROME metaprogramming stuff is based around run time code generation.
I'd hoped to look at how to optimise the system using runtime generation for common stuff - but I expected to have to experiment later; luckily, this fine fellow has blazed a trail for me!
However, I can't help but feel this is more of a programming language issue than an operating systems issue. The author has written an OS in assembly language, and implemented much of it by generating specialised code on the fly rather than jumping to the general code that then has to analyse its dynamic context every time it's executed to decide which control path to take, and having to load data indirectly rather than having it as an immedate value. Surely this stuff should be generalised into a way of optimising all code, rather than just being used in an operating system? I don't see the fundamental technique as being particularly bound to operating systems - lots of applications could benefit from it.
For ARGON, I'd like to use the metaprogramming facilities I've already planned for CHROME to build a toolkit that makes runtime specialisation optimisation easier. Maybe even look into making it happen automatically, although I suspect that the tradeoff involved may require human intervention at heart. A lot of the benefits could be had anyway by just compiling the code in a custom environment containing the constants, which will be constant-propogated and constant-folded and the used as immediate values - but I think those cunning executable data structures need more thinking about...