the life of a sysadmin.
Carousel is a lie!

Linky:
[FSF Associate Member] LOPSA

Email: aardvark at saintaardvarkthecarpeted dot com

Working wireless for Linux on a Dell C400

Fri Oct 26 13:47:47 PDT 2007

Turns out you can get the built-in Broadcom wireless card in my laptop (Dell C400) to work, but it did take me a bit of effort.

First off, I'd been looking at the wrong web page for the BCM43XX project — the right one, as Prakash pointed out, is much more up-to-date.

Second, again at Prakash's suggestion (thanks for that!), I downloaded the drivers for the Dell 1370. Running the .exe in Wine extracted the .sys file successfully. However, when I pointed fwcutter at them I got this message:

Sorry, the input file is either wrong or not supported by b43-fwcutter.
This file has an unknown MD5sum 8d49f11238815a320880fee9f98b2c92.

So that .sys file was one not supported…at least, not for a while now. That commit message was one of the few I could find that mentioned this number. So I checked out revision 396 from the Subversion repo, compiled it and pointed at the sys file…success! Extraction!

Except that it still didn't work:

bcm43xx: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed.

Turns out it had extracted all the files to /lib/firmware/bcm430x_*, rather than /lib/firmware/bcm43xx_*. Quick little shell-fu:

for i in bcm430x_* ; do j=$(echo $i | sed -e's/bcm430x/bcm43xx/') ; sudo ln -s $i $j ; done

and it worked when next I inserted the module…working right now, in fact, despite lots of error messages like:

bcm43xx: WARNING: Writing invalid LOpair (low: 0, high: -115, index:
120)
 [<d0ba6ebb>] bcm43xx_phy_lo_adjust+0x1e6/0x223 [bcm43xx]
 [<d0ba7d04>] bcm43xx_phy_lo_g_measure+0x915/0xaeb [bcm43xx]
 [<c01eb6db>] bit_cursor+0x479/0x48e
 [<c02a4416>] __sched_text_start+0x686/0x73b
 [<d0b9dde4>] bcm43xx_periodic_work_handler+0x15c/0x407 [bcm43xx]
 [<d0b9dc88>] bcm43xx_periodic_work_handler+0x0/0x407 [bcm43xx]
 [<c0130260>] run_workqueue+0x7d/0x109
 [<c0133308>] prepare_to_wait+0x12/0x49
 [<c0130a5d>] worker_thread+0x0/0xc7
 [<c0130b17>] worker_thread+0xba/0xc7
 [<c01331f5>] autoremove_wake_function+0x0/0x35
 [<c013312e>] kthread+0x38/0x5e
 [<c01330f6>] kthread+0x0/0x5e
 [<c01049c3>] kernel_thread_helper+0x7/0x10

in the kernel log.

No idea why I had to go through so much rigamarole, but hopefully this will save time for someone else. Oh, and for the record: this is with Debian Etch, 2.6.22 kernel from backports.org.

(permalink) (comments)

OpenBSD wins this one…for now!

Sat Oct 20 21:11:21 PDT 2007

I ordered the 4.2 CD set of OpenBSD at work, in another optimistic step toward reorganizing the firewall there. In order to (ahem) road-test it, I installed it on my new laptop (which, you'll recall, is running Debian Stable) in a 5GB partition I'd left for just this purpose.

Onboard wireless, like with Debian, did not work, and I didn't expect it to; fuck you too, Broadcom. But my dad offered to send out a couple of wireless cards he couldn't use, and I figured one of 'em would have to work.

One was a Broadcom (op cit.), so that was out. The other, a DWL-650 (which appears to have umpty different versions over the years with not one change in model number) looked promising: a Realtek chipset, so should be good, right?

Well, it worked on OpenBSD — but not in Linux. There's no driver in the tree for it, and the outside project to make drivers for it had its last official release in 2005. What's more, the CVS version, for some reason, removes all of its source files when I compile it, then complains that there are no files left to compile. To be fair, I think this is because of a makefile included from /lib/modules/2.6.22-2-686/build rather than the code itself.

Update: Just read Tourrilhes' page on the RealTek driver, and learned something: there's a fork/resurrection of the project I'd looked at, and it appears to be relatively current. I'll have to take a look. SooperUpdate: the new project fixes the let's-delete-all-the-files problem. Score!

What OpenBSD does not do on this laptop is suspend…or more accurately, come back from suspension. This works reasonably well under Debian, which means that I still have one rose to give away to The Next Laptop OS for Saint Aardvark.

(permalink) (comments)

DS replication problems

Sat Oct 20 19:04:55 PDT 2007

My lack of experience with LDAP in general, and Sun's (iPlanet|Directory Server( Enterprise Edition)?) in particular, has proven to be a bit of a handicap of late.

Case in point: when I upgraded $big_machine to Solaris 10 at the end of August, I also upgraded its LDAP server from iPlanet 5.1 to DSEE 6 (same software, different name). At the time I had two problems: I was unable to get replication to $big_server (we have a multi-master configuration; not supposed to work with 5.1, but it does/did for us) working over SSL, and replication from $big_server to other machines did not work. There were a lot of things going wrong at that point, so I set up replication in the clear from $little_machine, another LDAP server on the LAN, and left it 'til I had more time. It wasn't ideal, but it would do.

The last two Saturdays I've been trying to figure out why replication wasn't working. I concentrated on getting replication to it working over SSL. This was tough, because the logs didn't tell me much:

Server failed to flush BER data back to client

I swear, this turned up more Googlejuice today than it did a few weeks ago, because this time it turned up the ever-excellent Brandon Hutchinson again. This time he had a truly great set of instructions on installing DSEE6. That lead me to this blog entry, very helpful, giving information about the different sorts of databases you can stick your SSL certs into. (Must learn more about SSL/OpenSSL…)

However, in the end it turned out to be a simple and moderately embarassing mistake: it's not enough, with DS6, to say dsadm add-cert and be done with it; you actually have to specify the certificate to use. As Brandon points out, you have to edit =dse.ldif= in order to do so (though I had to stop the server, edit the file and start it up again, rather than just edit and restart, in order to get it to work).

The other thing — replication from $big_server elsewhere — is still not working. I suspect this is my fault; in an attempt to get things working, I decided that the thing to try would be initializing $big_server from $little_server, then the other way around. This did not change things, and now $little_server is unable to push its changes elsewhere. I've since been told this is a mistake on my part; arghh.

Unfortunately, there were other things I screwed up in the original install of DS6 on $big_server — embarassing and rather pointless to record for Google right now — and I strongly suspect that I'm going to have to reinstall or reinitialize $big_server just to get things into a reasonably coherent state. Fortunately, there aren't that many changes that ever happen on it, so there shouldn't be many to lose or redo if it's wiped.

And thus my Saturday.

(permalink) (comments)

<snort>

Thu Oct 18 21:10:45 PDT 2007

This just made me laugh and laugh and laugh.

(permalink) (comments)

Milestone

Tue Oct 16 21:03:36 PDT 2007

Tonight, my 15.5-month-old son pointed at a hat and said "Hat!"

I said, "Yes, you're right. And what's that on the hat?"

"Guk?"

"It's a penguin. And what does a penguin say?"

"Inix."

It's a proud day.

(permalink) (comments)

Time for a change?

Thu Oct 11 12:48:16 PDT 2007

I came across Steve's blog compiler (wonderful phrase; he tells me it comes from wiki compiler) Chronicle t'other day, and I'm intrigued. It's a great deal more polished than what I've got; his Makefile alone inspires envy in me. It's easy to tell that he's an actual programmer…

Chronicle does Markdown or Textile, not AsciiDoc, but it should be simple enough to grab the guts of this and make it do the job. And in any case my love of AsciiDoc is at least half due to its nice CSS, which I could steal.

The one thing that might be nice is that, looking in the code, Chronicle seems to recompile/regenerate all the HTML, whether or not anything has changed; I'm using make for regenerating the pages here, so as to avoid that. Of course, I could be wrong — I've only given Chronicle a once-over — and in any case my crappy lack of server-side includes makes for many rebuilds when (say) I add another link to the sidebar.

(permalink) (comments)

It's here!

Sat Oct 6 19:53:54 PDT 2007

The laptop I bought off eBay arrived at work on Wednesday…which is my day at home with Arlo. Thursday I was off sick with flu. Yesterday I was back at work and slashing open the box it came in, eager to see what I'd got.

Well, I already knew: it's a Dell C400. 12" screen, 1.2GHz P3 (but running at 800MHz with SpeedStep and all), 256MB RAM and a 30GB drive. Not a whole lot of memory, and a bigger hard drive would always be nice, but I can always upgrade. There's no CD drive in this thing, and I hadn't plumped for the docking station, so I set up PXE booting to install Debian. It was a trifle slow, but it worked! (Especially the second time, after I'd accidentally overwritten Debian trying to install OpenBSD on another partition. :-)

I'm surprised at how much Just Works in this thing: X.org (no configuration needed, just start up XDM…man, that's nice), suspend-to-disk, ethernet (well, it's a 3c905; what do you expect?). Even the battery, which I'd written off in advance, appears to hold a decent charge — about four hours so far. The one thing that's dicy is the onboard wireless, a Dell 1370 from everybody's favourite company. But again, I'd written that off in advance.

Next up: I've ordered the OpenBSD 4.2 CD set, so I'll be installing that once it arrives. And Noah has shown the way to longer battery life; I'm getting my 2.6.22 kernel now from Backports. (Oh, the shame of not compiling my own kernel…)

On another note, I think someone had one too many Dilbert moments:

$ dig newcastle.edu.au mx

; <<>> DiG 8.3 <<>> newcastle.edu.au mx
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4
;; QUERY SECTION:
;;      newcastle.edu.au, type = MX, class = IN

;; ANSWER SECTION:
newcastle.edu.au.       11h59m12s IN MX  10 proactive.newcastle.edu.au.
newcastle.edu.au.       11h59m12s IN MX  10 synergy.newcastle.edu.au.

Perhaps they got the names from /dev/bollocks.

(permalink) (comments)

My quest for the perfect window manager continues…

Tue Oct 2 09:13:02 PDT 2007

The latest entry: Awesome, a rewrite of dwm that just hit the OpenBSD ports tree. May have to give it a try…

(permalink) (comments)