Tag Archives: NetBSD

12″ PowerBook G4 PT5 – Electronic Battle Weapon

Preparation for a trip started off a little earlier this christmas. I planned to take my PowerBook on the road with me to Hamburg for 33c3. Previous attempts to use this machine as my primary system on the road in the past had been thwarted by leaving too little time to build & prepare before departure.
The system has been dual booting NetBSD & Mac OS X Tiger for some time now, recently I’ve been doing almost daily upgrades to NetBSD-HEAD on the system using the generated iso images from NYFTP.
My plan was to get the machine installed with a current build FireFox on NetBSD & bring the existing installed packages up to date. I managed to update the existing packages without any problems but it didn’t look like FireFox was going to build successfully. The package as-is currently in pkgsrc does not build on NetBSD/macppc. I was pointed to a patch in pkg/48595 which was pending commit and required testing. It cleared up the initial issue I ran into but the build still failed (see previous link on updates about the failure), though it took a little longer to fail in the day. After several days of failed build attempts I made sure I had an up to date copy of TenFourFox installed on Tiger and settled for Dillo on NetBSD instead.

My usage of Dillo stayed somewhat basic during the trip, despite having the Mozilla certificate bundle installed, I could see any obvious way to point Dillo to it & have it use it. Hence, any site using SSL I visited generated a certificate warning. Perhaps the config should’ve been done in wget?

www/dillo pkgdepgraph

Alexander Nasonov created packages for Dillo & Links-gui targeted for running under a minimal chroot but I did not get around to trying them out. There are chrooted browser packages for other browsers in his pkgsrc github repo. The screenshot above shows the www/dillo package’s dependencies, generated using pkgtools/pkgdepgraph

Moving on, the AirPort Extreme card in the laptop is based on a Broadcom chipset which has a flaw, it’s incapable of addressing memory above 1GB (30 bits) which means the driver needs to care for that or else the card doesn’t work. This is not unique to this Broadcom chipset, the BCM4401 10/100 ethernet interfaces which use the bce(4) driver also suffer from the same problem (unable to address memory allocated above 30 bits), the BCM580x ethernet interfaces which use the bge(4) driver suffer from not being able to address more than 40 bits. Going back to the wireless chipset, the bwi(4) driver which is used in the BSDs, originated from DragonFly BSD. This driver was put together by Sepherosa Ziehau using the documentation from a reversing effort in the Linux community. The bwi driver was then imported in to Free/Open/NetBSD and was eventually removed from DragonFly BSD. A new wireless subsystem was introduced in DragonFly which required change to drivers to work again and the bwi driver was never adapted. It now lives on in the other BSDs.

The version of bwi(4) driver came to NetBSD from OpenBSD, ported by Taylor R. Campbell back in 2009. At the time neither version of drivers could handle the 30 bit bug so you either ran with less than 1GB of RAM or used another card. In 2014 Stefan Sperling committed a workaround for this in OpenBSD. I wanted this fix in NetBSD so my wifi could also work & asked the NetBSD developers if such a change was appropriate in NetBSD. I was introduced to bus_dma(9) and the bus_dmatag_subregion() function, the bce(4) driver was my reference on how to use the function. Looked fairly straight forward, a single call this function and off you go, wasn’t too sure how it would fit into the bwi driver but I thought I’d have a go.

This was one of the things I was hoping to work on during my trip but It turned out to be the only thing I attempt. I happened to meet Stefan at 33c3 and we discussed the driver, the work around and the mighty days of the past when Damien Bergamini was hacking on the OpenBSD WiFi stack. In the OpenBSD driver Stefan had opted to deal with the issue of allocating memory in a specific region directly in the driver rather than adding a new interface to the kernel for  such a task so with a bit of thought about the past and a review of the driver, I was given a diff of the changes and suggestions about where I could start making changes.

I still don’t know yet if it’s possible to lift the changes from OpenBSD and apply them to the NetBSD version of the driver, because the DMA framework is different between the systems.
Partially implementing the change Stefan made without all the bounce buffers he’d added in the OpenBSD driver didn’t work and using the bus_dmatag_subregion() function didn’t work either. I pursued the bus_dmatag_subregion() path during 33c3 and didn’t get anywhere. At this point I started looking deeper in the system by looking at the implementation. It was at this point that I discovered this function was defined to EOPNOTSUPP on PowerPC based systems. No matter what I had tried with this function it was a waste of time^W^W^Wvaluable learning experience about keeping documentation up to date & consistent.

At this point I started looking into adding support for tagged subregions so I could make use of the function. The implementation is fairly simple, a public function for a developer to use which performs various tests and a private function which is called to deal with the memory allocation. Unfortunately there were some missing members from the data structure on the powerpc side of NetBSD which needed further investigation and I stopped there for the time being.

For the trip I relied on a tiny Realtek RTL8188CUS based wifi adapter to get me network access. The card worked on the 802.1x enabled SSID at 33c3 using wpa_supplicant(8) on NetBSD/maccppc.

urtwn0 at uhub4 port 5
urtwn0: Planex Communications Inc. GW-USNANO2, rev 2.00/2.00, addr 2
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address 00:22:cf:xx:xx:xx
urtwn0: 1 rx pipe, 2 tx pipes
urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

The driver for this card is now enabled by default in the GENERIC config file for NetBSD/macppc along with a group of other drivers for USB peripherals.

Thanks to Stefan for his help and advice with the bwi driver and Alex for the chrooted browser packages! 🙂

pkgsrcCon 2016 videos

The videos from some of the talks that took place at pkgsrcCon in Kraków, Poland during the Summer are now available on the Internet Archive.
This years conference drew speakers from many different project, not necessarily BSD related though Net/Free/OpenBSD were represented. Talks were on a pretty diverse range of topics around software but unfortunately not all talks were recorded. I had the opportunity to tag on Mateusz Kocielski’s slot on security & give a brief talk on the work of the pkgsrc security team (slides), whilst he covered the work of the NetBSD security team (see files security-team & flash-die).

The schedule for the conf is available here

A slow / low-end system capable of running most modern BSDs

I was looking to test a change related to buffering in cat(1) and wondered what was the slowest system I could use which was capable of running the current versions of NetBSD, FreeBSD, OpenBSD. An old PC and the ARM based BeagleBone Black sprang to mind immediately, then a PowerPC Mac? SPARC64?

Apart from a Sun Fire T1000, I do not have any SPARC hardware, sun4v is only supported on NetBSD & OpenBSD at present, FreeBSD/sun4v was only a pre-alpha rough cut from before the days of version 7 and sparc64 support may be going away in FreeBSD moving forward.

Considered the BeagleBone Black but currently NetBSD-HEAD does not boot on it port-arm/51380 and FreeBSD has issues with running DTrace bug/211389. So that was off the list.

A G4 based PowerPC Mac is supported between my choice of BSDs, unfortunately I couldn’t get a working disk burnt from the FreeBSD iso files to try it out on a 12″ PowerBook. bug/211488.

I settled on running i386 builds on a Alix 2c3 I have, it has 256MB RAM and a 500Mhz Geode CPU, currently running FreeBSD/i386 11-BETA3 without issue and has no problems with any of the other BSDs. It’s a little too “modern” and high spec though in my test.

Running FreeBSD / OpenBSD / NetBSD as a virtualised guest on Online.net

I’ve been running a mixture of FreeBSD / OpenBSD & NetBSD as guests on a dedicated server at Online.net. While getting the operating systems installed was fairly seamless, getting networking going was not.

  1. Client are not isolated in a layer 2 domain
  2. DHCPv6 config is broken

Clients not being isolated is not so much a problem itself and is typically what you’d expect if you plugged a bunch of computers into a switch with a single VLAN or unmanaged switched for example; but in a shared environment with untrusted tenants it can cause problems. Broadcast & IPv6 multicast floods aside, one is open to most of the attacks in something like THC-IPv6 due to lack of MLD snooping which would prevent a rogue IPv6 router.

Attacks via IPv6 are not so much of a problem as their use of non-RFC complaint timers settings in their DHCPv6 make it unfeasible to use the offered native IPv6 connectivity as clients will fail to renew leases. Depending on the DHCPv6 client used, the amount of time it takes fail to renew a lease will vary. dhcpcd for example now warns if detects a lease is not compliant with RFC 3315 section 22.4 “Identity Association for Non-temporary Addresses Option”.

Despite having a vast address range in IPv6 and a /48 subnet is allotted free of charge, you’ll need the equal amount of v4 address addresses as the v6 addresses you intend to use at Online.net. There is a way of using a /48 and allocating addresses yourself but it’s only possible using a version of Proxmox which they provide.

You can save yourself a lot of hassle both with configuration & trying to deal with their support  regarding IPv6 by using a Hurricane Electric tunnel. I actually found connectivity was also faster from Hurricane Electric than using the native connectivity.

For IPv4 connectivity on a guest (assuming you’re renting individual IP addresses & not a /27 prefix), you’ll need to use the default gateway IP address assigned to your host alongside the allotted IP address and a /32 prefix.

Assuming the network details are as follows
Default gateway on host:
Failover IP #1:, assigned to MAC address 00:50:56:00:01:AA
Failover IP #2:, assigned to MAC address 00:50:56:00:02:BB
Failover IP #3:, assigned to MAC address 00:50:56:00:03:CC

The MAC addresses need to be assigned to the tap(4) interface on the host.
If you’re using bhyve and your guest is using the interface tap0, this would be performed using the -s flag to configure the virtual PCI ethernet card, eg -s 1:0,virtio-net,tap0,mac=00:50:56:00:01:AA

It’s then onto configuring each OS to handle a gateway which is in a another subnet for IPv4 connectivity.


In FreeBSD you need to construct a route to reach the default IP address first, before you specify the default IP address, otherwise things will not work. So assuming we’re going to use Failover IP #1, your configuration in /etc/rc.conf would be as follows

static_routes="gateway default"
route_gateway="-host $gateway_ip -interface $gateway_if"
route_default="default $gateway_ip"

Note, the installer at present prevents network installs, you should use a iso image containing the distfiles, bug 206355 has more details.


On NetBSD, configure networking using /etc/netstart.local, entering the commands you’d enter at the console inside the file. Assuming failover IP #2 is going to be used for the NetBSD VM, the following would configure the guest to reach the outside world using, as discussed in the NetBSD Network FAQ

ifconfig vioif0
route add -net -link -cloning -iface vioif0
route add default -ifa


On OpenBSD, configure the networking from the ethernet interfaces configuration file hostname.if(5).

Assuming failover IP #3 is going to be used for the OpenBSD VM, the following will setup networking.


inet NONE
!/sbin/route add -net -netmask -link -cloning -iface vio0
!/sbin/route add default -ifa

It’s also possible to not specify the -cloning flag but a patch is required if you’re running 5.9 release.

The BSD family of operating systems

At OSHUG #46 I was given the opportunity to present the BSD’s to a group of open source hardware enthusiast & speak about why this family of operating systems would benefit the person running a flavour on their hardware. There was a recording made of the talk but it may be some time before it is made available online, so I thought I’d take the time to write something up to share in the meantime.

My slides.

This line of operating systems started out life as a series of patches to AT&T UNIX which was introduced to the University of Berkeley by Ken Thompson whilst on sabbatical in 1977.
From the 1BSD TAPE file included in the CSRG archive CD set

Berkeley UNIX Software Tape
Jan 16, 1978 TP 800BPI

The first release came with things such as the ex editor, ashell and Pascal compiler as an add-on for UNIX v7, running on a PDP-11. Over the life time of the CSRG they produced releases which included vi, csh, the IPv4 TCP/IP network stack, the virtual memory subsystem (the kernel being named vmunix, parodied by Linux as vmlinuz) and UFS.
The distribution tapes were only available to AT&T licensees; over time the code base of the distribution grew increasingly independent from AT&T UNIX. At the same time the cost of the AT&T license continued to increase as well. Starting out at a cost of $10000 and reaching north of $250000 in the late 80’s. According to Kirk McKusick there was pressure to release the independently developed components of the CSRG so the community could benefit from the use of things such as the network stack without purchasing a costly license. This resulted in several release, comprised mostly of the code developed outside of AT&T such as 4.3BSD-Net/1, Net/2, 4.4BSD-Lite & Lite2. “Mostly” in that with the release of Net/2 AT&T file a lawsuit against the University of California for alleged code copying and theft of trade secrets.
During its lifetime, BSD saw itself being run on several CPU architectures from the DEC PDP-11, VAX to the MIPS, HP 9000 and Motorola 68000 to name a few. These ports along with the  Power 6/32 helped to improve the portability of the code base. The code base was deemed to be 90% platform independent, the remaining 10% being mostly related to the VM subsystem which was platform specific. As with AT&T UNIX, portability & migration between different systems was part of the nature of the code base, from the beginning.

The 4.3BSD-Net/2 code base was used as the basis for a port to the Intel 386, resulting in 386BSD (free) & BSD386 (commercial) releases.

The Modern BSD variants
At the time of writing there are many BSD variants in existence, each with its own area of focus. Everything still leads back to 2 major variants.

NetBSD was the first of the modern variants that is still actively developed. It started out life as a fork of 386BSD. The focus of NetBSD is portability which not only makes porting to new hardware easier (currently supporting over 60 different ports across may CPU architectures).
Everything from a VAX, ARM & MIPS Windows CE based PDAs to a Sega Dreamcast and many other systems are supported and able to run the latest version of NetBSD. There’s even a toaster which run NetBSD
The focus on portability also makes reusing components on other operating systems easy. For example the packaging system (forked from FreeBSD (which we’ll talk about next)) supports over 20 operating systems.
This enables a consistent toolset to be used regardless of operating system.

Some of the highlights of NetBSD include ATF, unprivileged builds and portable build infrastructure using build.sh.

ATF, as the name suggests is used for automated tests of the source code to discover regression in the code base in an automated manner. Results can be found on the NetBSD release engineering page.

Unprivileged builds allow a user to not only build a copy of the operating systems without elevated privileged, but they can also build and install software from pkgsrc in a location they have write access to (by default, in a prefix under their home directory).

build.sh, the build framework, allows NetBSD to be built on any modern POSIX compliant operating system. Freeing the person to use a operating system of their choice to build releases.

04/05/2016- Note Ollivier’s comment, I made a mistake when I was gathering info and looked at the source for head and checked the history for the COPYRIGHT file there, not noticing the repository started with v2.0.

Forked from the 4.4BSD Lite code base, 6 months after NetBSD was started. The focus of FreeBSD was performance on i386 systems. Over time support was added for the DEC Alpha as this meant porting the code base to a 64bit systems and addressing any bugs which would prevent the code base from running on a 64bit system. Many years later the project branched out and introduced support for additional platforms. Today the project boasts support for CPUs such as ARMv8, RISC-V and BERI.

Forked from NetBSD, the focus of OpenBSD is security. The project is home to many components which see wider use outside of OpenBSD, such as OpenSSH, PF (firewall), LibreSSL and others.

Forked from FreeBSD, the focus of DragonFly BSD is scalability & performance. Taking the operating system in a new direction with regards to how SMP is implemented and from there, developing a new files system called HAMMER.

No matter the flavour, documentation is a key part of the development process for the BSD’s.
Whether it is the Design & Implementation series which started with covering 4.3BSD in 1989 and more recently FreeBSD 10 in the fourth instalment of the series, or each projects own set of documentation. Documentation is important as it distinguishes intent & implementation as well as save a lot of question and answers emails.
FreeBSD has handbooks, NetBSD has guides, OpenBSD has FAQs and all projects make their man pages available online as web pages. There is even  a teaching course based around the  The Design and Implementation of the FreeBSD Operating System, 2nd edition.

Frameworks for building embedded images
Each operating system release is a complete, self contained bundle, containing the documentation and necessary toolchain required for building a copy of the operating system from source. release(7) on FreeBSD & NetBSD, release(8) on OpenBSD, nerelease(7) on DragonFlyBSD

For the purpose of embedding the operating system it may not be desirable to build a full blown release. Depending on the choice of variant, either the functionality is built in as standard or a project exists to assist with generating customised images with ease.

FreeBSD had PicoBSD which is now superseded by NanoBSD.
OpenBSD has flashrd and resflash.
NetBSD has a target for generating an image in build.sh, customisations controlled by variables set in mk.conf.
DragonFlyBSD has nrelase.

RetroBSD / LiteBSD
RetroBSD is a port of 2.11BSD (originally targeted for the PDP-11) to the MIPS M4K core found on the PIC32 micro-controllers. LiteBSD is a port of 4.4BSD to the PIC32MZ micro-controllers with a MIPS32 core. Due to the limited resources available, RetroBSD does not offer a network stack, Of the 128KB of RAM, 96KB are available for user space applications. A compiler, editor & various utilities come bundled with the OS so software could be developed on the PIC itself. Variants of common software titles are available to extend the system, such as an Emacs like editor.
LiteBSD is based on a more recent version of BSD, taking advantage of the availability of more RAM (512KB) and MMU on the targeted micro controller. It features a network stack.

Projects such as these take advantage of prior effort and offer the user a consistent environment from the microcontroller to desktop to server. With the extensive documentation and availability of source history, it is possible to realise at which stage in the evolution of the code base the currently running system is and if a desired feature is implemented.

The development of BSD is closely tied with that of the internet. BSD’s modern variants are some of the oldest communities who have collaborated over the internet to develop a software project. The workflow of the projects has transpired to become the standard way of developing open source software on the internet, whether it’s adhering to a style guide or developing with a publicly accessible source repository or holding a hackathon.

For a newcomer interested in an operating system to run on your hardware, it is a great opportunity to be a part of a tech savvy community working to evolve an idea started almost 40 years ago.

As a business, each project produces a mature and robust operating system that has seen many applications from running on devices such as game consoles, mobile phones, cars, satellites and the international space station. Nearly all projects are backed by a non-profit foundation which can act as a liaison for businesses and assist with enquiries regarding development.

Hipster keyboard layout on NetBSD

Each of the major BSD’s have a different way of handling keyboard layouts on the console & X11. On OpenBSD X11 inherits the setting from wscons by default, on FreeBSD the console keyboard config is separate to the X11 config & depending on if you go down the hald route or not, you may find yourself writing XML to configure your keyboard. For NetBSD which I’ll cover here, wscons configuration is again separate from X11 configuration but everything is configured as per usual via the xorg.conf keyboard layout.

The snippet below is from xorg.conf which sets the keyboard model as a ThinkPad T60 (it should apply to X60 series apart from issues with media buttons), US Dvorak layout with the crtl & caps locks switched.
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbRules" "xorg"
Option "XkbModel" "thinkpad60"
Option "XkbLayout" "us"
Option "XkbVariant" "dvorak"
Option "XkbOptions" "ctrl:nocaps"

I didn’t know about the ctrl:nocaps option and I happen to stumble across it in the X section of the NetBSD guide.

To apply the same layout to the console, edit /etc/wscons.conf and set encoding to us.dvorak.swapctrlcaps followed /etc/rc.d/wscons restart.

Not sure how hipster this all is, managed to get sidetracked into NetBSD desktop config as I was working on updating a package in pkgsrc and remembered the tweet above. Seems like a common thing in the emacs world.


Last week I attended a conference on open source software called FOSDEM in Brussels, the two day event has lots of tracks, based on either specific projects or topics such as Java or securiy.

I attended the following talks
On Saturday
XMPP 101
The Open Observatory of Network Interference
Practical Security for developers, using OWASP ZAP
The future of X.org on non-Linux systems
Declarative style GUI programming
How to build an Identity Management System on Linux

On Sunday
The Lua Scripting Language in the NetBSD Kernel
Supporting the new C and C++ standards in FreeBSD
Improvements in the OpenBSD IPsec stack

My favourite talk of the event was the OWASP talk on Saturday by Simon Bennetts who did a great job of clearly explaining what ZAP can do & how it is of use for testing the security of your web application.
The XMPP 101 talk gave an overview of what the protocol can do, the OONI talk had a very late start & laptop issues, didn’t get much from the talk but it does seem like an interesting project from the info on the website. Matthieu Herrb  talked about the progress of running X.org on UNIX, conclusion “Tough times for non-linux systems”. Marc Balmer gave two talks on using Lua, first in GUI programming & the second on the lua(4) subsystem in the NetBSD kernel, allowing users to explore the system easily & doing rapid prototype without the initial steep learning curve of learning C & kernel internal, making the system internals easily accessible. The last talk on the Security track was on FreeIPA, luckily the slides were quiet detailed as it was impossible to hear the speaker because the mic was hanging too low off  his shirt collar.

The BSD track on Sunday was where I spent most of the day. David Chisnall spoke about the C & C++ standards & the mistakes made by the standards groups which we have to live with. I spent the lunch break talking with David about FreeBSD, how I struggle with doing buildworld on my X61s, what can be done to speed up buildworld, why the buildworld process takes so long & the tools Juniper has developed which allow you to track the dependency path for building each component in FreeBSD base.
Mike Belopuhov spoke about the IPsec stack & NAT64 support in OpenBSD, I had an opportunity to ask Mike about dead peer detection, in my previous site to site VPN deployment I had issues where if the connection dropped at either site, the tunnel with not be re-established, needing manual intervention, It was good to hear that this was a problem with the isakmpd & not necessarily a configuration issue.

There were a lots of projects & businesses with stands, Oreilly had a stand selling books, Google were in the recruitment section, Oracle with three big banners for java, mysql & something else, the lady on the stand was very friendly, telling me about how Oracle participates in open source software such as Java, the penny then dropped about the update 13 release.
It was good to see CAcert had a stand and were looking very busy with assurances. I visited the mozilla stand & had the opportunity to try out the firefoxOS on a nexus s?
I’m strongly considering moving to it as I’d rather go with firefoxOS than android, the lock down of iOS is very painful for sharing data between my own devices & makes it frustrating for getting content from several devices to a single place.
I visited the google stand to talk to the recruiters there, I was curious to learn about their recruitment process, since 2007 I have been approached by Google on 3 different occasion, the most recent being back in July last year. I always assumed they had drives every so many years & I’d just been lucky to have been listed on three separate occasions, it turns out actually that once you’re on their radar, they will make contact every once in a while to see if your situation has changed & if have developed sufficiently since last time to be able to pass the interview tests.
I spoke with others regarding this, with those now employed by them & those who have also been approached in the past, discussing why systems folks are sought after & what options you have should you wish to no longer be contacted (supposedly under Californian law, if a person requests a company to never be contacted again, the company has to comply?).

Over the weekend I spotted a few OpenBSD tops (more hoodies than t-shirts) & met my first MirBSD user/developer, Benny Siegert who was the organiser of the BSD track at FOSDEM.
I also had the opportunity to meet up with/bump into folks from communities such as MetaBUG, OSHUG, LOSUG, Brighton 2600, London *BSD, it was good to catch up.

USB & Firewire support for NetBSD/cobalt 4.0

The GENERIC kernel for NetBSD/cobalt 4.0 does not support USB or Firewire out of the box, I’ve created a set of patches (sourced from various threads on port-cobalt@) to add support.
You can grab the patches here
Once you have built & installed your new kernel, you will need to make a new MAKEDEV script.
cd /usr/src/etc

& place the new copy of the script in /dev
then generate the device files for the newly supported devices by running
sh MAKEDEV usbs
I’ve successfully used 5 rs232 > USB on my Qube2 via a PCI ALi chipset USB & Firewire card on NetBSD 4.0.
ohci0 at pci0 dev 10 function 0: Acer Labs M5237 USB 1.1 Host Controller (rev. 0x03)
ohci0: interrupting at irq 9
ohci0: OHCI version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Acer Labs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ohci1 at pci0 dev 10 function 1: Acer Labs M5237 USB 1.1 Host Controller (rev. 0x03)
ohci1: interrupting at irq 9
ohci1: OHCI version 1.0, legacy support
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: Acer Labs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ohci2 at pci0 dev 10 function 2: Acer Labs M5237 USB 1.1 Host Controller (rev. 0x03)
ohci2: interrupting at irq 9
ohci2: OHCI version 1.0, legacy support
usb2 at ohci2: USB revision 1.0
uhub2 at usb2
uhub2: Acer Labs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 10 function 3: Acer Labs M5239 USB 2.0 Host Controller (rev. 0x01)
ehci0: interrupting at irq 9
ehci0: BIOS has given up ownership
ehci0: EHCI version 1.0
ehci0: companion controllers, 2 ports each: ohci0 ohci1 ohci2
usb3 at ehci0: USB revision 2.0
uhub3 at usb3
uhub3: Acer Labs EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
fwohci0 at pci0 dev 10 function 4: Acer Labs product 0x5253 (rev. 0x00)
fwohci0: interrupting at irq 9
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:90:e6:xx:xx:xx:xx:xx
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
ieee1394if0 at fwohci0: IEEE1394 bus
fwip0 at ieee1394if0: IP over IEEE1394
fwohci0: Initiate bus reset

uplcom0 at uhub4 port 1
uplcom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 3
ucom0 at uplcom0
uplcom1 at uhub4 port 2
uplcom1: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 4
ucom1 at uplcom1
uplcom2 at uhub4 port 3
uplcom2: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 5
ucom2 at uplcom2
uplcom3 at uhub4 port 4
uplcom3: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 6
ucom3 at uplcom3
uplcom4 at uhub0 port 2
uplcom4: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 7
ucom4 at uplcom4

Cisco Aironet 350

I normally wouldn’t say this about a Cisco product, but WOW, the 100mW transmit power on the arials means I can get coverage everywhere in my house with this card plugged into my workpad, I struggle with most spots on my Axim, PowerBook or ThinkPad with a Orinocco plugged in.
The only problem I’ve ran into so far is a bug in NetBSD 3.0 (& OpenBSD 3.9 aswell aparently). It seems that once you upgrade to the recent versions of the firmware for this card (5.60 series), the AN(4) driver fails to attach & complains about the record buffer being too small
an0 at pcmcia0 function 0: <cisco Systems, 350 Series Wireless LAN Adapter>
pcic0: port 0x15000440-0x1500047f
ISA IRQ 3 -> vrgiu0 port 9, level high through
pcmcia0: card irq 3
an0: record buffer is too small, rid=ff00, size=198, len=258
an0: read caps failed
an0: failed to attach controller
an0 detached

Once I downgraded to version 5.41 the problem went away!! 🙂

an0 at pcmcia0 function 0: <cisco Systems, 350 Series Wireless LAN Adapter>
pcic0: port 0x15000440-0x1500047f
ISA IRQ 3 -> vrgiu0 port 9, level high through
pcmcia0: card irq 3
an0: Cisco Systems 350 Series (firmware 5.41)
an0: 802.11 address: 00:0f:90:xx:xx:xx, channel: 1-13
an0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps

Checking the NetBSD gnats database I found a PR which has a fix attached though I haven’t had a chance to try it out yet.

There is a patch for OpenBSD here which I presume is included in 4.0

Running Chillispot on OpenBSD, NetBSD & Mac OS X

*** 08/07/06 – Update, the patch just allows Chillispot to build successfully, tun.c needs some more patching before chillispot will work. Sorry 🙁 ***

I have made a patch which will enable Chillispot compile & run on OpenBSD, NetBSD & Mac OS X.

The patch has been tested working on the following versions of O/S’s
OpenBSD 3.9
Mac OS X 10.4.7
though it should work on previous versions aswell.

To build Chillipot 1.0 first download & extract Chillispot.
Then copy the patch into the Chillispot directory & issue:
patch -p1 < chillispot -1.0.patch

You should get the following result:
patching file src/chilli.c
patching file src/dhcp.c
patching file src/redir.c
patching file src/syserr.c
patching file src/tun.c

For NetBSD & OpenBSD:
Now run ./configure with the relevant switches e.g.
./configure --sysconfdir=/etc --localstatedir=/var
then for OpenBSD: run make install chilli_LDFLAGS=""

For Mac OS X:
Run make install chilli_LDFLAGS="-lcrypto -lresolv"
If compiling fails with the following error:
redir.c: In function 'redir_accept':
redir.c:1400: error: nested functions are not supported on MacOSX
redir.c:1406: error: nested functions are not supported on MacOSX
make[2]: *** [redir.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

then you’re using GCC 4.0.1, use gcc_select to switch to GCC 3.3 by running gcc_select 3.3 then rerunning make. When you’re done you can switch back to GCC 4 by running gcc_select 4.0 surprise surprise!!! 🙂