Back from EuroBSDCon

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

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).

EuroBSDCon 2007

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!

The MetaGeek Wi-Spy 2.4x

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.

Wi-Spy and Wi-Spy 2.4x

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.

Wi-Spy vs. 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.

Working around buggy java applets

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.

Using GPRS/UMTS under FreeBSD

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.

Tweaking your kismet.conf

The default configuration of Kismet, the de facto 802.11 wireless network sniffer for UNIX and UNIX-like operating systems, comes with a “safe set” of channels known to work with most 802.11abg radios out there.

If you, like me, have a non-American 802.11abg radio the standard kismet.conf file is not quite enough for using your radio to the full potential.

To come across this you first need to find out which channels your 802.11abg radio actually supports. Under FreeBSD this is easily accomplished by running ifconfig IFACE list chan (or ifconfig IFACE list active if you have limited the number of channels in your configuration).

Example output from my Intel PRO/Wireless 2915ABG:

$ ifconfig iwi0 list chan
Channel   1 : 2412  Mhz 11g          Channel  36 : 5180  Mhz 11a          
Channel   2 : 2417  Mhz 11g          Channel  40 : 5200  Mhz 11a          
Channel   3 : 2422  Mhz 11g          Channel  44 : 5220  Mhz 11a          
Channel   4 : 2427  Mhz 11g          Channel  48 : 5240  Mhz 11a          
Channel   5 : 2432  Mhz 11g          Channel  52 : 5260  Mhz 11a          
Channel   6 : 2437  Mhz 11g          Channel  56 : 5280  Mhz 11a          
Channel   7 : 2442  Mhz 11g          Channel  60 : 5300  Mhz 11a          
Channel   8 : 2447  Mhz 11g          Channel  64 : 5320  Mhz 11a          
Channel   9 : 2452  Mhz 11g          Channel 149 : 5745  Mhz 11a          
Channel  10 : 2457  Mhz 11g          Channel 153 : 5765  Mhz 11a          
Channel  11 : 2462  Mhz 11g          Channel 157 : 5785  Mhz 11a          
Channel  12 : 2467  Mhz 11g          Channel 161 : 5805  Mhz 11a          
Channel  13 : 2472  Mhz 11g          Channel 165 : 5825  Mhz 11a

To use the full set of channels in Kismet you will need to modify the existing kismet.conf to read something like this:

defaultchannels=IEEE80211b:1,7,13,2,8,3,14,9,4,10,5,11,6,12
defaultchannels=IEEE80211g:1,7,13,2,8,3,14,9,4,10,5,11,6,12
defaultchannels=IEEE80211a:36,40,44,48,52,56,60,64,149,153,157,161,165
defaultchannels=IEEE80211ab:1,7,13,2,8,3,14,9,4,10,5,11,6,12,36,40,44,48,52,56,60,64,149,153,157,161,165

While this will make kismet scan all the available channels, this is hardly ever what you want (no need for scanning 802.11a channels when you know the network you’re debugging is on 802.11g). To deal with this you can add the following lines to kismet.conf:

source=radiotap_bsd_ab,iwi0,ABG
source=radiotap_bsd_b,iwi0,BG
source=radiotap_bsd_a,iwi0,A
enablesources=BG

This will cause Kismet to channelhop on the previously defined 802.11bg channels by default, but still allow selecting only e.g. 802.11a channels by starting Kismet with kismet -C A.

Wi-Spy spectrum analyzer usable under FreeBSD

I managed to put the Wi-Spy spectrum analyzer donated to me earlier this year by Ryan Woodings of MetaGeek working under FreeBSD.

I promptly submitted my work – a small kernel patch and a port for Mike Kershaw’s wispy-tools to FreeBSD for inclusion. Luckily both were accepted by the FreeBSD developers :)

Hopefully MetaGeek will soon release more information about their upcoming Wi-Spy version with RP-SMA connector for external antenna connections as mentioned in a one of their recent newsletters…

Newflash at 11: GNOME Fallout Yet to be Fixed?

Looks like the FreeBSD ports tree will remain frozen for a few more days in preparation for the upcoming FreeBSD 6.2 release.

Hopefully this will give the needed time for the remaining fallout from the move of GNOME (and therefore GTK+ et al) from X11BASE to LOCALBASE. The move affected and broke many packages, some which have not yet been fixed…