I’ve been working on getting ospf setup between a Cisco PIX 515E and a Netgear 7324 (Which I despise by the way). It just wasn’t working so I stopped working on it last night, with intentions to setup a sniffing bridge today.

For whatever reason, www.openbsd.org is giving 403s right now. It turns out openbsd.org works, but regardless I grabbed openbsd 4.1 from a mirror and threw it on the pxe server. Network installs are getting old hat at this point, so I figured it’d be good to have around. The key to this being to take the pxeboot file, and rename it to pxeboot.0 (or openbsd.0) and choose this in the KERNEL line in the pxelinux.cfg/default file. This will try to boot /bsd.rd from the tftp server. It’s worth noting that I fell back on the i386 files over the amd64, as I was getting an error from pxelinux regarding the amd64 boot image.

Anyways, with openbsd 4.1 in hand I did the usual bridging configuration. I used one interface for management. I had sshd running on it and it had an IP, all configured during the install. The other two interfaces re0 and re1 I left alone during the install.

ifconfig bridge0 create
ifconfig re0 up
ifconfig re1 up
brconfig bridge0 add re0 add re1 up

I saw a ton of vlan traffic and wandered through the netgear gsm7324 config for a bit to clean things up. Once I was reaccquainted with their wierd vlan configuration, progress stopped. There was no ospf traffic going across the link (I had since connected re0 and re1 between the two devices). I could belive that the PIX might be filtering the ospf traffic, and I could believe I had misconfigured ospf on the gsm7324, so I spent a bunch of time tweaking these. Eventually I was out of ideas though, and I hadn’t seen any ospf traffic at all.

I decided to give the interfaces ip address and run tcpdump against them instead of against the bridge to look for the multicast ospf traffic and I immediately started seeing ospf traffic across the bridge.

I rebooted the openbsd box and reconfiguring the bridge. No ospf traffic. I checked net.inet.ip.forwarding and net.inet.ip.mforwarding which I was pretty sure had to do with routing and not briding, and verified their settings didn’t effect anything. I had spent a bit of time starting at the ifconfig output looking for any variance, and this time noticed that there was an inet6 line but not an inet line. “ifconfig interface inet up” did nothing so I ran “ifconfig interface inet6 ipv6address delete” and I started seeing the ospf multicast traffic.

Make whatever assumptions you want from that. Annoying, but ospf is up now, and I’m moving on.

I around a bit getting audio working on a couple desktops here in the office. Most of the engineering workstations are Asus A8N-E or A8N-SLI boards. There’s a jumper block labeled FP_AUDIO on board for the front panel audio. You may have noticed in the past that some computers will disable the rear speaker output when you connect something to the front output, such as to automatically turn off the speakers when you plug in headphones. I find this nice. The catch is that this is usually done by routing the audio to the front panel and then back, using a mechanical headphone switch that allows the electrical path to continue back to the motherboard when there is no connector in the front panel, but opens the connection when you plug in.

There’s some decent specs here showing the connections. Basically, if you don’t have the right type of front panel audio connected, then your rear audio connector is disconnected. Alternatively you can jumper pins 9/10 and 5/6 to force audio back to the rear connector when not using a front panel. I have yet to see this done on any of my boards, but I get the impression that this is default.