number 9

Welcome, Googlers

For the second time this millenium, I’ve had to persuade a server to trust the LDAP server
in the corner. The one with an SSL certificate written in crayon.

Eventually I found a fix – my own, from a few years back, on a mailing list archive (I never got round to restoring my old inbox after my mailserver died). As usual, I’m dumping it here for me and Google to find next time.

how do i brewed home

I use my own SSL Certificate Authority (CA) to sign server certificates. My SSL clients (browsers, JVMs, etc.) trust this CA certificate, so they automatically trust SSL certs it creates.

It’s a small improvement on self-signed certificates (that you have to load individually).

Exims LDAP lookup library (like lighttpds) doesn’t support homegrown CA certificates.

(Well, it does now, because I hacked in a fix and Ceri was good enough to polish it into something we could push upstream without being laughed at too loudly . But the point stands.)

documentation, you say? OpenLDAP set_tls_options() is confused.

If you try to bind over ldap:// (with startTLS) or ldaps:// against an LDAP server with a home-signed certificate, you’ll get the helpful LDAP error ‘-1′.

If you’re lucky, you can tell your client to load a custom CA cert.
Apache has the LDAPTrustedCA option, OpenLDAPs CLI tools read TLS_CACERT from ldap.conf, pam_ldap and nss_ldap use ‘tls_cacertfile’, etc.

If you’re unlucky, you need to patch your client.
This is easily fixed by throwing this into your C code somewhere:

ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, "/path/to/ca.crt");

(note that first argument is NULL, not a specific LDAP connection)
This only works for OpenLDAP, and the hard bit (that I did for lighttpd and Ceri did in his exim patch) is turning that hardcoded path into support for a config file option.

Just a quick ‘note to self’.

I noticed my NIC ( iprb0 ) is running in half duplex mode (autoneg doesn’t work with our switches):

vera # kstat iprb:0|grep duplex
   duplex                          half

A google finds very out of date information. I finally found the answer in the manpage, of all places

man iprb(4) says you need to edit /kernel/drv/iprb.conf

and set ForceSpeedDuplex to ‘4’ (for 100Mbit full dup):

vera # echo 'ForceSpeedDuplex=4;' > /kernel/drv/iprb.conf

(if you have more than 1 iprb NIC, you’ll have to set them all – see the manpage for details)

Then do a reconfigure reboot:

vera # reboot -- -r

after the reboot:

vera # kstat iprb:0|grep duplex
   duplex                          full

UPDATE: I’ve gone off the idea. I don’t roam, I don’t want all the family to have to know the WPA passphrase to use their laptop account, and I like wmii , where applets don’t really make any sense. I prefer the system-wide way of doing WPA myself.

Here’s the Ubuntu Dapper (or better) ‘WPA Howto’:

$ sudo apt-get install network-manager wpasupplicant
$ # edit out the NICs in /etc/network/interfaces
$ # that you want to be managed by NM
$ sudo reboot
$ # after reboot, run up 'nm-applet'

NetworkManager is great. The daemon runs in the background, watching for HAL events, and uses the best connection it can.

Plug in ethernet, it uses ethernet. Yank it out, it scans for WLANs.

If it needs help (e.g. unlocking the WPA-PSK or WEP keys stored in your keyring) it asks the user via a GNOME or KDE applet². It uses a local DNS forwarder and can notify apps (over DBUS) of network state changes.

This setup has a few implications. The most obvious is that you don’t get online until after you login to the GUI.
It also assumes the user is the one with the knowledge, not (whoever is root on) the laptop (suppose that’s how other OSes handle it anyway, just feels odd).

I imagine if you run many non-DBUSed servers that need a network at boot, or have hardcoded IPs in your firewall, it might piss you off a bit. But would you roam with that setup?

Although the applet is by default the font of all knowledge, you could easily run a non-GUI userland component as part of the usual boot If ubuntu-installer had one, WPA wireless users could net install at last.

¹ seems 256Mb isn’t enough RAM (!) to hibernate. Shut down firefox first and it’s fine.

² the applet works in fluxbox (and other window managers I presume) too, but it’ll ask you for the passphrase every boot. You can Google up some gnome-keyring voodoo if that drives you mad.

Flashing openlink went alright (takes ages though. It’s not kidding about doing it over a crossover cable and it’s terrifying doing it from XP).
Somehow /dev/console isn’t created, which has, er, interesting consequences but is easily fixed .

Adding NFS was a doddle (keeping uids in sync is another story but what’s new).
Multicast DNS works when it feels like it (mDNSresponder ships with a handy admin tool called ‘kill -9’); might play with the toolchain and have a go at rolling my own.

Disappointed that the eMac doesn’t do NFS service discovery – that looked like a really neat hack. Perversely, the Mac seems to find and mount Samba more easily than Appletalk so I’ve given in; once I shovel a few Gb of MP3s out of the way I’ll Tiger it up and see if that’s any smarter.

(UPDATE: it is. NFS is way faster than Appletalk or CIFS too.)

Despite our ups and downs, for me there’s still
only one choice for a server OS .

Luckily, FreeBSD 6.x now has WPA supplicant in the base,
along with ipi/ipw (Centrino 802.11b/g support), and word is
the 5.x wrinkles are ironed out.

So I thought I’d do a BSD version of the
WPA howto
I wrote the other day.

0: ingredients:

• FreeBSD 6.0
• a WPA capable supported wireless NIC (mainly 802.11g kit). I’m using a Cardbus NEC WL54AG - piece of crap but supported by ath and only 20 notes on ebay. Replace ath0 with ipw/ipi/ndis as appropriate.
• a computer
• an access point (should work on ad-hoc WLANs, too)
• a rootprompt

1: patch your kernel

Sod’s law -
since we’re securing our WLAN you might as well do it right.

2: get your modules on

If your card doesn’t show up in ’ifconfig -a’, check dmesg. Mine said:

cardbus0:  at device 0.0 (no driver attached)

until I kldload if_ath, then I got:

ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413)
ath0:  mem 0x88000000-0x8800ffff irq 12 at device 0.0 on cardbus0
ath0: Ethernet address: 00:0d:00:1d:41:1b
ath0: mac 5.9 phy 4.3 radio 3.6

3: setup /etc/wpa_supplicant.conf

If you’re accessing a pre-shared key WPA network, you should only need
to tweak the ‘psk=’, ‘proto=’ lines.

For anything else, read the (excellent)
wpa_supplicant.conf
manpage.

 # used by wpa_cli(8) (see 'troubleshooting' below)
 ctrl_interface=/var/run/wpa_supplicant
 ctrl_interface_group=0

 # boilerplate, essentially. see the example for a walkthrough
 eapol_version=1
 ap_scan=1
 fast_reauth=1

 # 'network' is a group of APs sharing a SSID
 network={
         ssid="YOURSSID"
         # 'RSN' == 'WPA2'
         proto=RSN WPA
         # that's 'pre-shared key'
         key_mgmt=WPA-PSK
         # lists ciphers to try. CCMP is AES
         # pairwise is for client <-> AP traffic, group is for broadcasts
         pairwise=CCMP TKIP
         group=CCMP TKIP
         psk="hail beastie, baby"
 }

4: setup your AP

(the faint-hearted should probably check they have ethernet access to it first)

You want to enable WPA-PSK and broadcast your SSID. On the WRT54G that goes:

• under ‘wireless’ → ‘basic wireless settings’
  • enable “SSID broadcast” (no need for security by obscurity)
• under ‘wireless’ → ‘wireless security’
  • set ‘security mode’ = ‘WPA2 personal’ (’enterprise’ needs a RADIUS server)
  • WPA algorithms = ‘AES’ or ‘TKIP + AES’ (I went for plain AES)
  • shared key = choose a long passphrase (it’s not like you’ll type it much)

Check you have everything you need (before you lose connectivity) and ‘save settings’.

5: gentlemen, start your NICs

As root, try this:

/etc/rc.d/wpa_supplicant forcestart ath0
/sbin/dhclient ath0 # or just 'ifconfig ath0 .....'

and hopefully you’re back online.

Since I told my supplicant to try CCMP, then TKIP (the ’pairwise=…’ .conf line),
I was asked to kldload
wlan_ccmp
and restart the supplicant. If it fell through to TKIP it presumably want
wlan_tkip
.

6: automatic for the people

Assuming our /etc/wpa_supplicant.conf was good, we now want this
to start at boot.

First the loader has to pull in our modules. For my case, that’s

 cat >> /boot/loader.conf
 if_ath_load="YES"
 wlan_ccmp_load="YES"
 wlan_tkip_load="YES"# can't hurt
 EOF

Now you just flag the interface as using WPA and DHCP:

 cat >> /etc/rc.conf
 ifconfig_ath0="WPA DHCP"
 EOF

7: troubleshooting

wpa_supplicant will give you more detail than you could possibly want if you pass it
a ’-dd’ argument. A ’ps awwux|grep supplicant’ should give you the full command you’re
using, just add ’-dd’ to those arguments.

That should give you some idea where it’s failing, or at least get you a string to google for.

I also highly recommend
wpa_cli
for those who a) don’t want to hardcode a PSK in a cfg file, b) need to debug their connection or c) like talking to network processes for some reason.

8: homework schools out

Laptop users might want to play with devd and have the start_if.ath0 script run when you insert your NIC should be pleased to find you can now just plug in your card and devd will fire it up correctly for you. It even kills off wpa_supplicant and dhclient neatly when you eject the card.