Toys,_freedom,_technocracy


title: Toys, Freedom, Technocracy date: 2005-02-19 11:13:27

I haven't posted in a while about work, so I thought I'd put in some updates here. Plus, I've come down with a cold, so I'm too sick to think hard about checksums for router firmware right now. :-)

I've been on the receiving end for some fun toys of late. First off, I've taken delivery of three HP Procurve 2650 managed switches; these are going to replace our dumb (and problematic, though a lot less so since I've been making it a policy to get rid of cheap-ass switches bought from London Drugs) Dlink switches. Not a moment too soon, either; we have 96 ports right now, and I think there are about four free. I think I'm going to have to get some shelves to install them in our current rack; it's one of those telecom ones, so they'd be hanging out behind, and I suspect they'd tip it right over. It'll be nice to be able to do VLANs, track traffic, and so on. My MRTG page is already getting big; this'll push it up to 11.

Next, I've received two Adaptec SCSI cards and some rack rails. Doesn't sound like much fun until you combine it with the Promise RAID array and the new four-post rack that's coming next week (allegedly). This'll take care of our disk space problems for a year or two; right now, I've got the home directories of our Windows users spread over four disks in two servers, and I'm running out of room on all of them. There's some stuff that could be cleaned up, but for the most part it's needed; we've got some wicked big log files for regression tests that, for example, have taken up the lion's share of a 200GB disk. The Promise array holds, what, 15 disks? At the very least I should be able to get a couple terabyte, which should be good for a while. (I did some calculations a while back; for as long as I've been at this company (2 years in April), our storage requirements have doubled about every 6-8 months, and there's no sign that it's slowing down.)

After that, we've got an evaluation copy of VMware 5. Just like the last time I checked out VMware, I'm using it to try out some Windows changes. Right now I'm trying out Daisy, a GPL'd automatic patch applier thingy for W2K. (XP support past SP2 will come with version 3; we're nearly all W2K, so it's not a big deal right now.) For the most part, I'm happy. There's a couple little things that are funky (W.Update sez no patches needed, Daisy sez 4 are needed) but it's a fuck of a lot better than going in every month and running W.Update manually (yeah, I know). So far I've been spending my time downloading all the fucking patches (<rant> Why the fuck doesn't MS have some sort of pattern for patch URLS? WTF is with these random strings of letters between "download.microsoft.com" and "W2K-patch-ENU.exe"? And why the fuck did they wait so long to standardize switches for non-interactive, non-forced rebooting application? </rant>); the next step is seeing how well Daisy works w/o interaction. (Probably just fine, from what I've seen.) Man, it'll be nice to drop patches on the FTP server, then tell everyone their computer will reboot at midnight...

As for VMware itself, it's a huge help. It's absolutely amazing to be able to revert to a snapshot; I don't even want to think about how long it'd take to duplicate that with a real machine, even if I had a fully automated install (which is my next goal after automated patch management). Aside from the little oops (and hey, it's beta), I've got no complaints at all about VMware as a program. I'm not really stress-testing it, though, so I don't know how well it'd do for some of the bigger programs we need to run at work. Of course, I don't really have any way of finding out, either; the EULA sez "You may not disclose the results of any benchmark test of the Software to any third party without VMware's prior written approval." Ah, proprietary software...

...which segues nicely into another toy I got this week: my membership package from the Free Software Foundation. I got my LNX-BBC-based bootable membership card (#2961!), plus another CD with the source code...of course. Browsed through it just to look at the code, since it seemed like I really should (and also because I wanted to see if I could understand the source code for cksum...at 10 o'clock at night while waiting for cold medicine to kick in. Uh-huh).

I also got my copy of Larence Lessig's Free Culture, a welcome letter that spent its first paragraph talking about the tax implications of that free book and looked like it was typeset with Tex (interesting -- it reminded me so much of everything I saw that came out of the University of Waterloo's math department...tests, newsletters, for-sale posters, everything), and the last two newsletters, including one with a picture of a very unimpressed-looking Bradley Kuhn (who has a poker journal. Who knew?) posing for the camera with SCO's subpoena.

I admit to being a bit unsettled reading one of RMS' essay/editorials for the newsletter, in which he said we were all working toward a future where all software would be Free. The religious overtones were hard to avoid, not to mention the similarities to exhortations from the left about when the workers would overthrow the shackles of capitalism. I'm NOT saying "RMS is a commie" or anything like that; it's the...I don't know, the feel of a small group of people desperately trying to make changes they believe in that's familiar. I used to get the same feeling when I came across the Technocracy newsletters at the library. (Bring back the Technocracy fliers, whoever you are...they're sorely missed.)

But then I remember EULAs like VMware's, or like the one for a program we use at work that said something like "Despite whatever rights you have under law, you give them all up by using this software" and "You're not allowed to tell anyone the terms of this EULA" (fuzzy on that last one, so don't quote me -- but I'm pretty sure it was something like that). And I realize just how much Freedom I take for granted, how much of it is due to the FSF and many others, and how that freedom is important enough to be capitalized.

Anyhow...qemu booted the membership card very nicely. It seemed astonishingly quick to start, until I realized that it wasn't simulating the usual BIOS check -- I hadn't thought before about how long that can add to boot times. Memory check, disk detection (IDE), disk detection (SCSI), bootloader...it adds up. One of these days I'd love to get some real server hardware to play with; I've heard very good stuff about Sun machines, and it'd be interesting to play with some non-x86 hardware (besides the router, I mean). I really should go see Cal and get a SparcStation...of course, they are a lot cheaper on eBay.

I also got a desktop machine of my own at work. Ever since I started, I've been using a machine that's been used as many different servers: spam filtering, backup NIS, backup, FreeBSD source code repository... I'd put in a request for a machine of my own, but (since I'm the one who had to buy it) nothing much got done.

A couple of weeks ago, I got a request for a developer sandbox, so I ordered it in, got it set up, then was told that it was no longer needed. Well, sweet! It's a Shuttle, P4, 1GB of memory and a 200GB hard drive. This means a) I can run stuff like VMWare on Debian and b) I no longer have to start full backups on the weekend to make sure my desktop is actually usable on Monday: I can just start full backups on Monday morning, and continue hitting refresh on Slashdot. Oh yeah!

Finally, my wife got a toy too: a new LCD monitor. She had been using this 15" CRT I picked up at a swap meet for $50, but it had started to make ominous brrrZZAAP! electrical noises. Picked up a Benq (you know it's a Benq because when you turn it on, it says "Benq!" for a second or two before you get your desktop) 17" FP 731 on sale after reading the reviews (cheap but decent seemed to be the consensus). No complaints so far, and man I can't belive how big it looks.

Damn tempted to get one for myself...but I think I might order one of these instead while I still can. The situation in Canada doesn't seem quite so dire as down there, but then again where the hell am I going to pick up a Canadian made HDTV encoder card?

...Good god, 1500 words. Post this puppy.

Tags:

New_theme,_upgrade


title: New theme, upgrade date: 2005-02-18 07:30:03

I've upgraded Wordpress to the newly-released 1.5, and the Obsidian theme. 1.5 seems nice; there's a lot of new features, including some neat-sounding spam-fu, so I'm curious to see how it'll work. The upgrade was stupid easy. As for the theme, Obsidian is nice, but there are still some things I'm messing around with. I hate playing with CSS, though -- such a time-sink! -- so if I can't make it work easily I'll just go back to the default theme.

Tags:

Oh,_man


title: Oh, man date: 2005-02-17 20:01:24

From Gentoo's security advisory:

Synopsis VMware may load shared libraries from an untrusted, world-writable directory, resulting in the execution of arbitrary code. 2. Impact Information Background VMware Workstation is a powerful virtual machine for developers and system administrators. Description Tavis Ormandy of the Gentoo Linux Security Audit Team has discovered that VMware Workstation searches for gdk-pixbuf loadable modules in an untrusted, world-writable directory. Impact A local attacker could create a malicious shared object that would be loaded by VMware, resulting in the execution of arbitrary code with the privileges of the user running VMware. 3. Resolution Information Workaround The system administrator may create the file /tmp/rrdharan to prevent malicious users from creating a directory at that location.

And sure enough, a quick Google for VMware and rrdharran turns up the guy's profile on their support forums, where he's listed as a developer. I'd laugh, but this just makes me paranoid about what I might miss...

Tags:

NWR04B: Checksum for original firmware

Okay, so I think I've figured out the checksum for the original, available-from-ftp.networkeverywhere.com firmware (NWR04Bv1.02D1220.dlf).

First, the file has two parts: there's what I'm calling bootloader (probably a huge misnomer), and then there's a gzip archive file called archive.bin.gz. splitgzip.pl will pull out the latter; simple math and dd will extract the former. The length of application.bin.gz is 743898 bytes; in hex, that's 0x000b59da. The sum of all the bytes in application.bin.gz is 0x05fc5b7c.

Both of these numbers can be found (allowing for little-endianness) at 12 bytes and 8 bytes from the end of bootloader, respectively:

``` ```
00004ed0 02 00 00 00 da 59 0b 00 7c 5b fc 05 20 03 00 00 |.....Y..|[.. ...|

So this works for the NE firmware. However, loading this has caused problems before, so I'm reluctant to use it as a basis for uploading new firmware. And the pattern does not seem to hold for the Runtop firmware I've used to resuscitate the dead router; I still have to figure out how they're doing it.

Finally, even if I do figure out how to get the checksum working, will this let me boot Linux? Sure, I can upload a new filesystem, but how will I hand control to it? No idea. Still...fun puzzle!

Tags: nwr04b

NWR04B: Not so easy

The continuing saga of the NWR04b, um, continues.

As I mentioned, I was looking at using the rmem command on the NWR firmware to read out memory and maybe figure out the checksum code. I came up with a small expect script (well, grabbed rddmm.exp and butchered it 'til it did what I wanted) to do just that, but it seems to be a little buggy: after a while, the output freezes. If I fire up minicom, I get a whole crapload of memory output from the serial port -- the stuff the expect script had been reading all along. It continues until I reset the board, but after that the characters from the board are all messed up: you can see where the menu and prompts are, but every other character or so is wrong. If I exit minicom then start again, letting it reset the serial port in the process, everything's fine. This makes me think my expect script is maybe going too fast, or not grabbing the output fast enough, or something else that just messes up the state of the serial port temporarily.

I was going to work on it a bit and give it the option of starting at a particular offset (which would've taken a while, since I'm almost completely new to expect), but got distracted when I found the NWR's SEEKRIT MENU! At power-on, you see this prompt:

Got the 6HYNIX_16bits Flash ROM ADM5106
Boot:

Welp, turns out that if you hit the space bar three times right then, you get this menu:

Loader Menu ================
(a) Download POST ...
(b) Exit
Please enter your key :

Woohoo, a quick way to download ARMboot! Or so I hoped. (I did try UP LEFT UP LEFT RIGHT RIGHT DOWN RIGHT UP LEFT to see if that would run Linux automagically, but no.)

First, a cross-compiling toolchain was needed. I found this page, which had both a fully-compiled toolchain ready to download, or a script that would build everything for you and required lots of mysterious patches to be downloaded in advance. Since I'm more manly than smart, I went for the script. (Though obviously I'm not that manly, since I was depending on a script in the first place...) I ran into troubles with uClibc, though -- for some reason, the script would just refuse to build it. Eventually, I just gave up and downloaded the pre-compiled version.

Now, on to the actual compiling of ARMboot. Codeman, the original hacker, posted a bunch of files that included (I think) a modified version of ARMboot for the chip on the NWR. A quick make cx84200_config and make CROSS_COMPILE=/path/to/arm-uclinux-tools/bin/arm-uclinux- all worked, with a couple hiccups along the way. First off, I got this error:

cc1: error: invalid option `short-load-bytes'

A quick Google turned up this message from the CrossGCC project, saying that this option had been renamed alignment-traps. A bit of script-fu took care of that:

find . -type f -exec grep -l short-load-bytes {} ; | xargs perl -i.bak -pe's/-mshort-load-bytes/-malignment-traps/'

God, I love Unix.

I tried make again, and came up with this error:

flash.c: 181: error: label at end of compound statement

The code in question looked like this:

default:
    printf("Unknown Chip Typen");
    goto Done;
    break;
}
/* Some stuff I'm leaving out... */
printf ("n");
Done:
}

I moved the Done: label to before the last printf statement, and everything seemed to work fine: ARMboot compiled, and I had armboot.bin ready to go. Doubtless there's a better way of doing that, but this seemed to work well enough for now.

Now to try uploading:

Loader Menu
================
(a) Download POST ...
(b) Exit
Please enter your key : a
Downloading............PASS
Verifying file......file corrupt -- FAIL

Well, crap: I was able to upload it by Xmodem, as I suspected, but it's still checksumming the thing, which means I was busted again. I'm still not giving up, though. I'm hoping to figure out the checksum; I found this page, which has a lot of pointers on how to do it. I think I'll try some of the things he talks about and see if I can figure out more about the checksum.

Tags: nwr04b

I_don't_even_have__words__for_this_crap


title: I don't even have words for this crap date: 2005-02-09 06:56:11

From here:

In one of the documents released last year, the Justice Department even blacked out a quote from a 1972 Supreme Court decision, reading in part: "The danger to political dissent is acute where the Government attempts to act under so vague a concept as the power to protect 'domestic security.'" Judge Marrero later ordered the quote restored.

Tags:

A power bar you can SSH to

I was shopping for a new rack and the necessary accessories, when I came across the power bar you can SSH to. That's right: not only does it have a digital readout on the thing that lets you know how much power/current you're drawing (and oh man, does that ever make this thing worth it; I'm scared to plug in new machines right now for fear I'm gonna trip a breaker), but you can ssh to the damn thing. There's even a "how to recover a lost password" procedure.

Tags: hardware

Feh


title: Feh date: 2005-02-06 20:48:17

Holy crap, there were precisely three and a half funny moments during American Dad. What the hell happened to Seth McFarlane? I hope the new Family Guy episodes are going to be better than that. I may stick around to see more, but not if they don't shape up soon.

Tags:

NWR04B: Back from the dead!

Welp, thanks to a suggestion from Mike and Varu,I managed to rescuscitate the dead NWR04B router. It had gone silent and unreponsive -- no web server, no response to pings -- after applying the firmware on the Network Everywhere FTP site. (Some upgrade!)

Today, I picked up some header pins at the closest thing to a local electronics store. After a bit of work -- getting the solder out of header pins is tricky -- I got them attached, and sure enough the serial port worked fine. It was stuck at the bootloader menu, with this message:

Verifying product code...FAIL
* WARNING *
Need to reprogram the flash.

That reminded me of the bit on this page on the Linksys WAP-11. Apparently, firmware for other products using the same hardware would work much better than the Linksys firmware. To prevent this sort of thing, the bootloader was changed to check for a product code, to make sure it wasn't another company's firmware. Almost makes me wonder if that's what happened with the NE firmware. Pretty huge screwup, though...

So I tried uploading the Runtop firmware to the router via Xmodem...and it worked! I got the usual command line back, and everything seemed fine. I didn't try the web pages yet, but I don't expect any surprises there. I've checked the Runtop firmware with splitgzip, and it has the same kind of embedded Gzip archive the NE firmware does. It'll be interesting to compare the rest of it.

I've also tried fooling around with the rmem (read memory) command, and I think this might be promising. You can run "rmem 0 400", and it'll print out 0x400 bytes of memory, nicely formatted, starting at address 0. 0x400 seems to be the biggest chunk it'll print, but you can incrmement it and keep going. (Managed to crash it, too, by running "rmem 99900000 400"...the command line was completely unresponsive, and one of the LEDs on the front started flashing rapidly. Fortunately, the reset button set everything right.)

I'm thinking that this might be a way of reading out (what I hope will be) the bootloader code, and thus maybe getting the checksum code out of there somehow. I should be able to hack together an Expect script that'll cycle through the memory, capture the formatted output to a file, then turn that into a copy of the memory suitable for passing to a disassembler. And if that works, maybe we can look at overwriting flash with the wmem command...

Tags: nwr04b

The_wine_of_boot


title: THE WINE OF BOOT date: 2005-02-04 20:32:18

Came across a couple of interesting problems this week. The first was getting our bran' spankin' new dual G5 Power Mac running Gentoo Linux to boot without a monitor. It turned out to be surprisingly difficult. Of course, I found this out just before I was going to move it into its permanent location; it simply hadn't occurred to try beforehand and make sure it wasn't an issue. (Glad I tried this before moving it, though; it's got to be at least 800kg.)

As near as I could tell (no serial port), the thing simply would not boot with the monitor detached. It'd power on, give the little boot chime, and then...nothing. It wouldn't respond to pings, it wouldn't use the monitor once I plugged it back in, and it would go into airplane mode after a few minutes (fans full blast...man, this thing has got some serious cooling), which suggested it wasn't even getting into Linux.

What was truly strange was that it seemed to be sending out multiple DHCP requests, asking for a new address every few minutes. It never responded on those addresses, nor did any other traffic come from them. I asked the Mac guy at work about it. "It shouldn't do that," he said. Well, okay, good to confirm that, but what do we do now? Didn't know: we knew of the Xserve machines, and figured headless booting shouldn't be a problem, but couldn't figure out what the next step would be.

There turned out to be a great deal of silence on the issue; neither one of us could find anything remotely like this in Google. Oh sure, there were the Old World Macs where you had to use cross-connect a couple pins on the video cable (or buy a dongle that'd do it for you) because the things depended on a monitor (ugh!), but nothing about New World machines like this. I found out about nvsetenv, the command that shows you the environment variables that are set in the Parameter RAM for Open Firmware, and hey! this looks interesting:

skip-netboot: false

Well, okay then! Set that to true, that'll keep it from trying to do DHCP, right? Skip right on over to the Linux kernel, and that's that! Save, reboot, and -- no. Doing the same godammn thing. Back to square one.

Finally, I came across a mailing list message from one of the Yaboot developers that gave me a clue. I started looking at ofboot.b, the file used by yaboot to (hope I'm getting this right) feed Forth commands to the Apple Open Firmware in order to get things to boot. And then the Mac guy at work pointed out this ofboot.b file, from a page on YellowDog Linux' site about headless booting. Woohoo, off to the races!

...Yeah, right. Have you ever worked with Forth? I certainly haven't. I scratched my head, looked at the two versions of ofboot.b, then decided to sit down at the Open Firmware prompt (splat-alt-o-f) and do a bit of experimenting. It wasn't bad, actually; once I figured out "hello world" and simple addition, I was starting to understand what I'd seen.

I narrowed it down to two problem areas in Gentoo's version. The first was right up at the top: : .printf fb8-write drop ; This was a subroutine called printf being defined as two steps (I think): fb8-write and drop. Compare and contrast this with the usual way of printing stuff in Forth ("type"). I tried modifying this to read: : .printf type ; Gave it a try...and no, same problem.

Well, what about that dump-stdout bit from YDL? I tried that from the OF prompt and nothing: it complained that it was an unknown keyword. Okay, they're probably defining it somewhere else. Rather than bother looking it up, I moved on to the next bit, also close to the beginning of the file: " screen" output When I did this at the OF prompt, I got a seizure-inducing flicker followed by a prompt at a clear screen. Certainly doesn't seem good...so I tried removing that line, and success! I was able to boot without a monitor!

It's still strange to me that I haven't seen this mentioned anywhere. I guess it's possible no one's tried to boot one of these headless before, but I suspect that all my searches for "headless g5" were just too swamped in speculation about the Mini Mac. 'Tany rate, I'll submit a bug to Gentoo about this, and maybe send off something to the Yaboot folks as well.

The other problem was with Wine; we use it for a couple of Windows command-line tools as part of our compile. We had a guy whose instance of wine couldn't find a file in his PWD: wine -- "c:foo" bar.c
Error: can't find file bar.c
And of course, bar.c was right fucking there, just waiting to be turned into an object file. So WTF, right? WINEPREFIX: yep, set correctly. Other tools able to find the file: yep, no problem there. Move the file to /tmp and try there -- aha, works!

Now I knew what was going on. We've had recurring problems with amd on FreeBSD (and lo, this was most assuredly a FreeBSD workstation): there is some kind of symlink caching going on (and amd is all about the symlinks, baby) in the FreeBSD kernel that amd finds itself unable to cope with. We'd upgraded amd to a later version on our workstations and found that our problems went 'way down -- only looks like I missed one. I set it up, told him to reboot, and patted myself on the back for a job well done. Only it didn't change anything: wine was still unable to find the damn file. Well, fuck.

In desperation I tried moving his directory (~jdoe/cvs) to another place (~jdoe/test), on the assumption that a different inode or something would convince amd to just find the damn file. Yeah, I know -- but it worked. I did some more dances, embarrassing to relate, and gradually convinced myself that whatever amd's failings, they were not relevant to this problem. Nothing else for it; time to pull out the big guns: wine --debugmsg +all -- "c:foo" bar.c Holy crap, does that every present a lot of debugging info: piped to a file, it was around 600KB. A quick look showed that most of it was boring Wine/Windows intialization stuff, but I was able to narrow it down by grepping for "bar.c".

And this is where I found the interesting bit:

DOSFS_FindUnixName 'foo.c' not found in '/home/jdoe/CVS

In order to find a file, Wine needs to know what Windows drive it's on. The usual practice is to set up a drive for your home directory, and that's what we'd done with F:. But what was it doing looking in the wrong directory? This guy doesn't have anything named CVS -- -- except that he does, and this was confusing Wine: it was running in Unix and was case-sensitive (starting at the diretory called "CVS", which comes before "cvs"), but it was simulating Windows and so it was case-insensitive (it couldn't tell the difference between F:CVS and F:cvs). Not only that, but it was stopping at the first failure, giving up on the F: drive, then moving on to other drives, then throwing an error when it couldn't find the file. No wonder it would all work if I renamed the directory!

It took me a day and a half to figure this out (I wish that were a lie), but I got to look like a minor hero when I showed him the solution: mv CVS somewhere_else With any luck, this little tale will save someone else a day and a half of their life.

And holy crap: here's a link to a guy who's hacked the freaking BIOS in his IBM T-41. Disturbingly, it would not let him use the wireless card he's bought for it -- he'd gone aftermarket, rather than official IBM -- and it kept saying "Please remove unauthorized card". Given IBM's geek-friendly rep, I'm surprised something like this hasn't got more play. Maybe I'll submit this to Slashdot and see what happens.

Tags:

Network Everywhere NWR04B: Serial port working!

At last! Paul has turned out to be a great help: he successfully hooked up a serial port to his NWR04B today and was able to get a shell on there. And after getting a lot of help from a couple coworkers of mine (thanks, Jim and Wayne!), I was able to duplicate his success! The embarrassing part is that it turns out the main reason I wasn't seeing anything from the serial port is that I wasn't powering the damn chip. For some reason I figured that the 3232 (from the good folks at Sipex Heavy Manufacturing Concern) would draw power from the serial port, or the board itself, or, I don't know, the luminiferous ether that surrounds us all. Jim set me straight on that. Quick transcript:

Got the 6HYNIX_16bits Flash ROM ADM5106 Boot: NetMall System Boot Copyright 2002 ADMtek, Inc. CPU: ADM5106 Home Gateway Processor POST Version: 2.00.0176 Creation Date: 2003.07.10 Press <space> key three times to stop autoboot... 0 Verifying product code......PASS Boot Product Code!!! DHCPS:DHCP Server Started. Enabled NAT mode ======================================================
Mars project:
Command Line Interface. 1.18.0001 v.2003.10.16
======================================================
cmd> update
Entered INIT state.
MAC failed to BOOT...
CardStop is called
Entered WAIT_OFFER state.
Timed out in WAIT_OFFER state.

Fascinating, isn't it? :-) So yeah, lots of updates about to hit the wiki page. Next step is maybe to try uploading Armboot, the way CodeMan did, or maybe go for the gusto and try uploading a Linux filesystem image. Of course, there's lots of stuff to be found out just by poking around in the command line, too...

Tags: nwr04b

Network Everywhere NWR04B: Still no serial port

I'm still having no luck getting a serial port going on this thing. I thought it might be because I was using a MAX 232 chip, instead of a MAX 3232 ("...and an extra 3 cubits for Linus, whose kernel this is...").

I also took the time to try to make a more permanent assembly by doing it up on a bit of perfboard -- so now I've got yellow wires (distinguishable connectors are for the weak!) poking out from perfboard instead of from breadboard. And still, nothing...not a goddamned peep, excep for a weird y-plus-umlaut character that pops up every now and then in Minicom and I'm blaming on either noise or acid flashbacks.

I'm at a loss here. As far as I can tell the connections are good (my three bits of electronics equipment are a soldering iron, a plastic box with many subdivisions, and a multimeter), and the circuit looks more or less like the circuit listed at the HRI site. That leaves connecting at the wrong place on the board, or maybe grounding. Not sure.

But hey! I got an offer to collaborate from pck; his electronic skills would be nice. And I'm going to shoot off an email to the guy who got it running in the first place to see if, a year later, he can help out.

Tags: nwr04b

Wireless at last!

Well, sweet. I brought the iBook to work today, and at last I've found a place to get wireless access: turns out that [Trees Organic Coffee][1], in beautiful downtown Vancouver, not only offers free wireless access to its customers but! also allows SSH. I'm able to check my email from home and post this. Good thing I set up https for my site last night...too bad I've not generated my own certificate yet.

And advice for those who follow: the tables against the front window are really, really cute but they're up high enough to make my wrists cry out in pain. People are staring. And the signal's not great here either, though I'm sure it's better elsewhere in the shop.

Finally got the dual G5 box at work set up with Gentoo. Nice OS, I gotta say. I cheated and went with the stage 3 install on the assumption I wouldn't have enough time to play around, so I can't tell you how fast it was at compiling. But as an OS, it's nice. Very minimal; I felt like I was back in the days before I'd automated the workstation installs, doing minimal FreeBSD installs by hand and wondering how to fix the nine things that weren't working.

Emerge is cool; I definitely like the idea of using shell script functions for the various stages of adding a port (download, unpack, compile and so on). I've always thought that the FreeBSD set of Makefiles was needlessly obscure...but then, I'm probably betraying my complete and utter lack of 133+ by saying that. I want a Mister Muffin t-shirt. Piro, are you listening?

[1]: http ://vancouver.wifimug.org/index.cgi?TreesOrganicCoffee

Tags:

World's most awful hack

Problem: You are behind a FreeBSD firewall using natd. You are listening to an Internet radio station with a limited number of streams. It has taken you six tries to get in, but at last you're there. Suddenly it's time for lunch, though, and you want to take your laptop (which you've been using to listen) with you. When you come back, you'll need to try connecting all over again.

Solution: natd is just a userland program. Hack it so that, upon receiving a certain signal (USR1, say, or maybe something sent over a listening Unix or TCP socket), it will remap a certain connection to another incoming point. End effect: instead of the radio stream being directed to your laptop, it'll be redirected to your workstation where you'll have netcat or something similar to grab the stream and keep things going. Switch back once you're back from lunch.

Tags: networking

Network Everywhere NWR04B: serial port || firmware info

I've put in a few hours tonight working on the Network Everywhere NWR04B, with mixed results. (The NWRO04B is the 802.11b router I picked up for $18 on sale; I'm trying to duplicate this guy's luck getting Linux to work on the thing.

I took the time tonight to get a slightly more permanent version of the RS232 adapter put together. Previously I've been putting stuff together on a breadboard, with wires all over the place; tonight I soldered things together and put wires all over the place. I tried to be careful, and all the connections seemed good, but I still had no luck: I saw absolutely nothing over the serial port at all, and from what I've read it should be pretty damned obvious. I'll have to ask some people at work about this.

One thing I'm still trying to figure out is how to treat all the different ground connections; I'm assuming that they all get connected together, and together with pin 5 on the DB9 connector, but I'm not sure. (If anyone's got any hints, please chip in.) That was about two hours tonight, and if that was it I'd chalk it up to experience and go to bed. But I did manage to find this page, which had a Perl script which extracts GZip archives from files. And guess what? It works on the NWR04B firmware! Woohoo!

It's embarrassing how simple this script is; I've been trying to figure out some way of doing exactly this, once I'd figured out that there was an archive in there. I want to understand how this works, but in the meantime it's exciting (hoo, what a life) to see all the stuff in there. strings | fmt | less shows tons of stuff going on: HTML, a reference to /dev/uart0, clitask (some kind of command-line interface, or just a dirty joke?), an XML UPNP description of the device...all sorts of information. And that's enough for now. I've got just enough energy to eat something, then go to bed.

Tags: nwr04b

Upgrades!

1.2.2, here we come!

Tags:

You know it's a good day...

You know it's a good day when you're demonstrating Unix pipes to someone, and suddenly you can see the light dawning, and they say, "Oh man, I've been wasting my time with Windows." Score one for the good guys.

Tags: unix

The headers of doom

Had an interesting couple of problems at work this week.

First thing was a FreeBSD system where, suddenly, ipfw didn't work anymore. Only "suddenly"'s not exactly true: this happened after a kernel upgrade. And "didn't work" is a bit inaccurate too: it would list firewall rules -- it just couldn't add them. (Good thing this machine had "default accept" as its firewall policy...) So, like, WTF?

First I tried adding a very simple rule: /sbin/ipfw add 100 allow all from any to any Nope, didn't work: ipfw: getsockopt(IP_FW_ADD): Invalid argument I tried that rule on another machine to make sure my syntax was okay -- no problems. Well, what about the command itself? The MD5 checksum of /sbin/ipfw on both machines was the same. I considered briefly blaming the problems on 3133+ cR5><0rZ who'd found an MD5 collision in ipfw, but decided not to try that on my boss. (I did copy the command from the working machine to the stupid machine just to be sure...yep, same result. So much for superstition.)

Hey, wait a minute -- hadn't we patched the kernel on the stupid machine? Sure we had! So that means...well, I don't know what. I had a look at the patches (very simple stuff, so I was able to follow along), and couldn't see what might be causing the problem. I mean, yes they did change the firewall functionality, but...well, maybe we should chase that up, yes? Yes.

And here I fell down a rabbit hole: I started to wonder if maybe the fact that FreeBSD compiled modules for everything (sure seems that way) despite the functionality being included in your KERNCONF file maybe meant that said functionality might still actually reside in the modules -- that the kernel wasn't being statically compiled at all, or at least for this particular bit, but there were Secret! Invisible! Modules! that actually had the bit of code we were looking for. Oh sure, kldstat doesn't show them, but that just shows how tricky those damn FreeBSD kernel developers are, right? And yeah.

Since the stupid machine'd had its kernel copied over by hand -- ie, we did scp foo@bar:/kernel / (I KNOW, I KNOW) and rebooted, and didn't copy all those Secret! Invisible! Modules! over along with /kernel, why, sure we were gonna run into problems! Of course! It all makes sense now! It was the Freemasons all along!

Lemme tell you, I was yea close to copying over /modules/ipfw.ko and trying that (I did go so far as to try ldd /kernel (I KNOW, I KNOW), but it turns out that ldd actually tries to execute a file in order to figure out what libraries it uses, so it just gave me a smack for being such an idiot), but for some reason had another look at the patches we'd made. Okay, yep, that bit in here, that bit over there, and not one bloody file in /usr/src/sbin/ipfw/ipfw.c, so why the...

Oh. Header files.

  1. We'd changed a header file
  2. that was used in /sbin/ipfw's compilation
  3. and I hadn't thought of that.

Well, crap. But hey, easy to test and easy to fix: patch the header file, recompile ipfw, and ha! Working! All I had to do was compose a suitably superior-sounding email about the dangers of passing /kernel files around willy-nilly, and all was well again.

Coming up next: Gentoo on a dual G5. Woohoo!

Tags: warstory

Argh


title: ARGH date: 2005-01-08 17:06:37 tags: nwr04b

So I went out today and got a MAX 232CPE and a MAX 232N, plus assorted wires and whatnot, in an attempt to get a serial port connection to the NWR04B. Got a couple wires soldered to the board, hooked up a CPE to a breadboard with some capacitors, distressed a null modem cable, and....

Well, results were decidedly mixed; minicom eventually showed some chatter, but nothing intelligible, and only when I rubbed two wires together. (Cue jokes here.) At least I know the level shifter is working (I was worried I'd picked up the wrong size/value/faradicitousness of capacitor), but it's frustrating not to see anything I can recognise (like, you know, some ASCII, or "press 1 to boot Linux"). Plus, I suspect I'm only seeing static coming from the connection, rather than anything from the damn board.

Argh. Hints more than welcome, but dumb them down; this is about the sixth time I've soldered anything.

Tags:

Holy crap, pf rocks

Sat down tonight to create a firewall for a new OpenBSD web server I'm setting up, and holy crap is pf ever good. I got to test the firewall syntax before loading it, and as a result I had a working firewall the first fucking time I loaded it. That's never happened before; I full expected that this time, as every other time with a new firewall (let alone a new firewall language!), I'd have to reboot or log in with a keyboard or serial cable, or something.

But no: not only did I not lock myself out, not only was this the first time (well, nearly) that I'd read the FAQ, the firewall does everything I wanted it to: no extra packets in, no extra packets out. Wow.

Alioth was right: pf just rocks.

Tags: openbsd