Someone decided to punish me with a commit bit for FreeBSD Ports – ironically, that same person decided to punish himself by being my mentor :)

Erwin even handed me a sealed envelope containing a piece of paper with a large ’1′ printed on it at our latest aarhus.pm meeting – I must admit, it took me a while to figure out that it was a ports commit bit!

Anyways, as FreeBSD Ports is in a freeze right now, preparing for the upcoming 6.3 and 7.0 releases, I guess I won’t be committing anything interesting for now…

Here’s a quick HOWTO for updating a Soekris net4801 BIOS using cu(1) and lsx(1) from comms/lrzsz under FreeBSD.

First, establish contact to the BIOS using something like ‘cu -l /dev/ttyU0 -s 19200′ adjusted to fit the device node and speed used in your setup. Then follow these steps:

1. Press Ctrl+P to enter the Soekris BIOS monitor
2. Type download -
3. Press ~C
4. Type lsx /path/to/b4801_131.bin

If the XMODEM transfer was successful, continue with the following steps:

1. Type flashupdate
2. Type reboot
3. Press ~. to exit cu(1)

That’s it! The BIOS should now be updated :)

Some time ago I got my hands on a bunch of more or less broken Linksys 802.11 APs and wireless routers. They have been sitting in my closet until recently, when I decided to mock a bit with one of the WRT54G models.

First things first – I had to establish contact with the onboard firmware. Since the board didn’t respond on any of the ethernet interfaces I set out to construct an RS-232 level converter to use with the onboard 3.3V TTL serial interface.

Judging from google, people use all kinds of weird and somewhat complicated (not to mention quite expensive) circuits in order to convert the voltage levels of the WRT54G serial interface to RS-232 levels. I decided to go with my own simple, cheap and effective design based on the Maxim MAX3232 as shown below:

The pinout of the IDC connector on the Linksys WRT54G – X3 in the diagram above – is as follows (thanks to Rod Whitby for posting information on the pinouts, saved me a bit of trial-and-error):

The onboard firmware of the WRT54G provides a console on ttyS0 at 115200 1N8. Since the above pinout lacks RTS/CTS lines we have to rely on software flow control.

To connect to the console one might use a command like cu(1):

$ cu -l /dev/ttyU0 -s 115200

Below is a couple of action-shots of the circuit in use:

The next logical step is to get FreeBSD/mips up and running on this thing ;-)

Several people have asked me about the system monitor running on the root window of my ThinkPad X60s’ X11 desktop – not many of them had spotted that is was actually just conky with an advanced configuration and a custom wallpaper:

My ~/.conkyrc can be downloaded from here. The panel at the bottom center is from FluxBox, my window manager of choice. The panel to the left is fbpager, a desktop pager for use with FluxBox.

This years EuroBSDCon was great fun! It was the second time I attended EuroBSDCon, and it was great meeting up with – what has come to my understanding is – the “usual crowd” again.

The talks this year were very high quality and the social and networking aspect was very enjoyable – ranging from Robert Watson’s talk about the TrustedBSD enhancements to the traditional Unix security model to my ZFS debug session with Pawel Jakub Dawidek.

I took a few, muddy photos at the conference – they can be found at the usual place. See you all next year in Strasbourg!

EuroBSDCon 2007 starts in a few days. It will take place in Copenhagen, Denmark this year, so my travel time is greatly reduced compared to last year (where it took place in Milan, Italy).

I am especially looking forward to Sam Leffler’s talk about long distance wireless networks, Robert Watson’s talk about FreeBSD security features and Kirk McKusick’s talk about the BSD fast filesystem – and, of course, networking with other *BSD enthusiasts.

Erwin kindly offered me a ride on his bike to get there, so hopefully the weather gods wont be too agry the next couple of days ;)

Oh, and remember to bring two government issued photo IDs if you want me to sign your PGP/GPG key or a CACert Web of Trust form.

See you in Copenhagen!

Ryan Woodings, Chief Geek at MetaGeek, LLC kindly donated a Wi-Spy 2.4x spectrum analyzer to me, thus allowing me to work on getting it supported in FreeBSD like I did with their earlier product. Thanks!

I must say, the Wi-Spy 2.4x simply rocks. It’s resolution is much better (3x) than that of 1st generation Wi-Spy and the external antenna is of course a nice addition as well. Below is a photo of my two Wi-Spys for comparison.

Here’s a screenshot of the current development version of spectrum-tools (formerly wispy-tools). The top graph is from my new Wi-Spy 2.4x, the bottom graph is from my 1st generation Wi-Spy – you can clearly see the improved resolution and amplitude range of the Wi-Spy 2.4x.

The yellow line is the current signal level, the green is the average signal level and the blue is the peak signal level.

My patch which adds support for the Wi-Spy 2.4x to the FreeBSD kernel can be found in usb/116057.

After having heard so much about LinkedIn from friends, family and former colleagues I finally decided to get my own profile there – and wow, what a system. A truly great way to visualize your social and professional networks!

My public profile can be found here.

Having recently upgraded to FreeBSD 7-CURRENT, and therefore no longer able to use the precompiled java/diablo-jdk15 port, I had to bite the bitter apple and pollute my FreeBSD installation with a Linux emulation layer in order to bootstrap the java/jdk15 port.

The installation went pretty smooth, but it turned out my home banking applet failed to load with this Java SDK. The error was a result of a java.io.IOException: open HTTP connection failed – the applet was unable to dynamically load its class files over HTTP.

After a bit of investigation it turned out the home banking applet didn’t support IPv6 properly. While it is possible to build java/jdk15 without IPv6 support, this seemed a bit overkill just to get one buggy applet working…

Luckily, the solution turned out to be pretty simple. Setting the following in ~/.java/deployment/deployment.properties makes the JVM prefer IPv4 over IPv6, thus bringing the buggy applet back to life:

deployment.javapi.jre.1.5.0-p4.args=-Djava.net.preferIPv4Stack=true

Don’t forget to restart your browser or java application after setting this value in order for it to have any effect.

I have a Motorola E1000 3G phone, which I occationally use as a modem to get one of my FreeBSD-based laptops online from non-wifi covered locations using either a bluetooth link or an USB cable.

As it seems many people find it difficult to set up ppp(8) I decided to share my simple configuration example here – hopefully someone will find it useful.

Start by finding the bluetooth address of your mobile phone:

# hccontrol inquiry
Inquiry result, num_responses=1
Inquiry result #0
        BD_ADDR: 00:11:22:33:44:55
        Page Scan Rep. Mode: 0x1
        Page Scan Period Mode: 00
        Page Scan Mode: 00
        Class: 52:22:04
        Clock offset: 0x3485
Inquiry complete. Status: No error [00]

You can put a host entry in /etc/bluetooth/hosts – this is like /etc/hosts for bluetooth devices/commands:

00:11:22:33:44:55       MyPhone

Next, put an entry in /etc/bluetooth/hcsecd.conf and launch hcsecd using the /etc/rc.d/hcsecd rc script:

device {
        bdaddr  00:11:22:33:44:55;
        name    "My Phone";
        key     nokey;
        pin     "1234";
}

Replace the PIN code “1234″ with something of your liking and make sure the /etc/bluetooth/hcsecd.conf is not world readable. You will need this PIN code when pairing your phone with your laptop.

Finally, you need to tell ppp(8) how to connect to your ISP. Replace the content of /etc/ppp/ppp.conf with the following:

default:
        set log Phase Chat LCP IPCP CCP tun command

dialup:
        set authname
        set authkey
        set phone "*99***1#"

        set dial "ABORT ERROR \\
                  ABORT NO\\sCARRIER \\
                  ABORT NO\\sDIALTONE \\
                  ABORT BUSY \\
                  ABORT NO\\sANSWER \\
                  TIMEOUT 5 \\
                  \"\" ATZ \\
                  OK-AT-OK ATE1 \\
                  OK-AT-OK AT+CGATT=0 \\
                  OK-AT-OK AT+CGDCONT=1,\\\\\"IP\\\\\",\\\\\"internet\\\\\",\\\\\"\\\\\",0,0 \\
                  OK-AT-OK \\\\dATD\\\\T \\
                  TIMEOUT 30 \\
                  CONNECT"

        set login
        set timeout 1800
        enable dns
        resolv rewrite

        set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
        add default HISADDR

rfcomm:
        load dialup
        enable force-scripts

ucom:
        load dialup
        set device /dev/ttyU0
        set speed 460800

The above assumes that your phone appears as /dev/ttyU0 when plugged in using the USB cable. If you only intend to use bluetooth you can skip the “ucom” section all together.

Make sure to replace the string “internet” in the above with the APN (Acces Point Name) given to you by your ISP. The above works for connections made through the Danish ISPs Telmore and TDC Mobil.

Now it should be as simple as running rfcomm_pppd -d -a phone -C DUN -l rfcomm and presto (or maybe not presto, it takes a few seconds to establish the connection) – you’re online using GPRS/UMTS. You can replace “-C DUN” with the correct channel for the Dial-Up Networking service on your phone (the channel number can be found using sdpcontrol -a MyPhone browse) and save a Service Discovery Protocol lookup, if you want.

Should you instead wish to connect using the USB cable you just run ppp -foreground ucom, simple as that.

When you’re done using the connection you can just Ctrl+C rfcomm_pppd(8) or ppp(8) and the connection will be dropped.