pooplex, more like

Posted by Dick on April 16, 2007

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

roam if you want to

Posted by Dick on April 06, 2006

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

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

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

NAS flash

Posted by Dick on April 03, 2006

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

wpa for freebsd

Posted by Dick on January 23, 2006

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.

.local hero

Posted by Dick on November 21, 2005

The other day I grumbled about the WRT54G lacking static DHCP and an embedded DNS server.

So to shell into the the mac I first have to ping the network address to see what boxes are up, then shell into each of them in turn (telling them all my password if they ask, of course). Like a fricking caveman.

So, what to do?
Nessus mass OS fingerprinting seems a bit rude, host files are ridiculous. But I really want to see how far I can push my server-free lifestyle. BIND is out.

mDNS has looked interesting for a while, and here’s my excuse to try it.
Security had put me off before, but now we’re locked down tighter than a gnats chuff.
This was the whole point of having services elsewhere, I get to play around with relative impunity.

I found someone in an uncannily similar situation who’d setup mDNSresponder. That isn’t in Debian anymore (not even ‘non-free’) because of a licensing bunfight . (IANAL but this is what I hate about Debian – On NetBSD, ACCEPTABLE_LICENSES takes care of this ).
Luckily, I’ve already stomped off in a huff to use Ubuntu…

zero conf

On Breezy (edgy too – see below), enable universe. It’s what all the cool kids do.

sudo apt-get install mdns-scan

If I run ‘mdns-scan’, I can see all the Macs services (mostly iTunes related),
so it looks like the Linksys passes multicast between its wired and wireless VLANs
(your also firewall needs to allow UDP to 224.0.0.251 (multicast) port 5353).

$ sudo apt-get install libnss-mdns
$ # add 'mdns4' to the 'hosts' line in /etc/nsswitch.conf

Now macshostname.local resolves.

For an encore:

sudo apt-get install avahi-daemon

Now myhostname.local resolves to my public IP.

(UPDATE: on Edgy, avahi is now in main, but after a looong argument it turns out you’ll need to edit /etc/default/avahi-daemon and change 0 to 1. I’m not sure they really got the whole ‘zeroconf’ concept…)

NB: the readmes suggest sticking ‘mdns4’ after ‘dns’ in /etc/nsswitch.conf. This means that queries for .local go off to the DNS system before falling back to avahi. I think the other way round is better – avahi only responds for domains in /etc/mdns.allow anyway, so it’s no less secure.

(update: as of v0.8, nss-mdns has an extra module, libnss_minimal, that will only handle .local domains and zeroconf IPs (169.254.x.x) to address this)

next steps

This is so much better suited to my needs than fixed DHCP entries and BIND I am gobsmacked.
Feels like the jump from Java to Ruby.

Unless I have this back-asswards:

  • it doesn’t matter what IP the boxes get assigned, you can still find them
  • you can find boxes whether they’re connected over ethernet or wireless
  • you don’t need to update anything if new machines are installed
  • there is no single database/point of failure (BIND dying makes everything go tits up in my experience)

Of course, rogue boxes can spoof hostnames, but frankly if you do
host-based authentication you’re in no position to be lecturing anyone on security.
Servers/clients can of course use whatever secure mechanisms you want (unit tests vs. static typing :) )

If this sounds like something you could use, I can’t recommend the
O’Reilly zeroconf book highly enough. Or just watch Stuart Cheshires zeroconf Techtalk on Google Video .

My head is already buzzing with potential uses for Avahi’s DNS service discovery.

Sadly, the WRT54G only has a radiobutton to enable uPNP, a rival framework which makes Jini look lightweight….