Amanda report format

Add this to amanda.conf to get better formatted reports:

columnspec "Disk=1:18,HostName=0:10,OutKB=1:10,DumpRate=1:10,TapeRate=1:10"

Tags: backups

NWR04B: Update

It's been a while since I posted, so it's time to catch up on what I've been doing.

I got frustrated with not being able to write to flash memory, possibly because I was unable to figure out what the datasheet was telling me. I decided to have a look at the firmware itself (the part that prints the initial menu, gives you a chance to load your own firmware, then boots the thing) and see if that would tell me what was going on. Seemed like a good thing to try -- after all, it writes to flash when you upload a new image, so it's got to have the secret knocks in there somewhere, right?

Well, damned if I could find it. There are parts in the firmware where it wants to print a message to the screen, and the way it does it by:

1. Loading a memory address
2. that contains a pointer to a text string
3. into a register
4. and then calling the print routine

So I was looking for something similar in a let's-write-to-flash routine:

1. Loading a memory address
2. that contains a pointer to a secret number
3. into a register, or possibly a memory address
4. that unlocks or erases flash memory

But I simply couldn't find it, nor could I find any obvious constants in the firmware itself. The datasheet gives the steps and numbers needed -- 0x00000555, 0x00000aaa, and so on -- and I just could not see them anywhere. So that left trying to track execution of the firmware itself.

I was able to track down the place where the firmware printed the menu that allowed you to upload more firmware. From there, I could see the jump-off points to receive the firmware, then the checksum, then -- aha! -- erasing and writing to the flash memory. But keeping track of what was going on after that was just too much; I'm not used to thinking in assembly, there were lots of jumps that depended upon the state of registers (which I coudn't figure out), and again there was nothing obvious that showed me what was being written where. I may try again with the second-stage firmware -- the original, visible firmware from the manufacturers that I'm replacing with Linux -- but I'm not much more optimistic.

Okay, so what next? Well, the MTD subsystem has been rewritten extensively since the kernel version that I've got, and they're no longer supporting version 2.4 of the kernel. But the uClinux people have backported their work to the 2.4 version of uClinux, and maybe that'll work. Jumping to the 2.6 kernel seems a little too scary, but upgrading to the latest 2.4 shouldn't be too bad, right? Heh. It may not be too bad if you know what you're doing, but for me it's a little more challenging. I've spent a week on this so far, and I'm finally at the point where it fails at the final link. Since I've done little more than copy files over wholecloth, this is indeed progress.

Of course, there's probably going to be a lot to go through once I get the final linking done; it took a while for me to get Linux printing to the screen, let alone successfully booting. And after that, I don't think there will be a driver for the flash -- at least, I can't see one in the current tree. What I'm hoping is that the updated MTD tree will allow for better probing of the flash's abilities using the Common Flash Interface, or at least I'll be able to ask for help without being ignored.

Tags: nwr04b

Stick_that_in_your_.bashrc_and_smoke_it.

title: Stick that in your .bashrc and smoke it. date: 2005-10-20 18:11:44

function tv () { i=$(echo ${@} | sed -e's/.*\(...\)$/\1/') ; case $i in bz2) tar tvjf ${@} ;; *gz) tar tvzf ${@} ;; *) tar tvf
${@} ;; esac }

function xv () { i=$(echo ${@} | sed -e's/.*\(...\)$/\1/') ; case $i in bz2) tar xvjf ${@} ;; *gz) tar xvzf ${@} ;; *) tar xvf
${@} ;; esac }

Tags:

NWR04B: Secret Knocks

So I came to the the realization that I've been including the driver for the wrong damn flash chip. This came straight from Codeman's tree, which in turn is based on (I think) the HRI tree. Codeman's .config file for uClinux included drivers for the SST39V flash chip, which just plain isn't right for this router. It's possible that he had a different revision of the board or some such, but I suspect that since he wrote to the flash using the JTAG interface, the issue just never came up.

I grabbed the datasheet for the Hynix chip, and it's not that different from what's in the SST driver...but it's just different enough that it's causes problems. First of all, you've got to give the secret knock before writing a byte to flash -- apparently to keep electrical noise (or some such) from accidentally erasing important data. In the SST driver, it looks like this:

map->write8(map, 0xaa, 0x5555)
map->write8(map, 0x55, 0x2aaa);
map->write8(map, 0xa0, 0x5555);

But according to the Hynix datasheet, it should look like this:

map->write8(map, 0xaa, 0xaaa);
map->write8(map, 0x55, 0x555);
map->write8(map, 0xa0, 0xaaa);

Okay, easy enough to change. Still didn't work, though, when I tried to copy the jffs2 image to /dev/mtd1; the writes just keep on failing. But then I remembered that only an erase can turn on a particular bit -- ordinary writes can only flip 'em off.

Just for fun, I tried copying an image where, compared to what was in flash already, bits would only have to be turned off -- and sure enough, that worked. Didn't survive a reboot, though...weird.

On, then, to the bit of the datasheet that deals with erasing. There's the secret knock for erasing, but that was easy enough to fix. The last part of the secret knock tells the chip which 0x1000-byte sector to erase. With the SST driver, it looks like you just use the beginning of the 0x1000 byte sector you want to erase, making sure that it's on an erase boundary (ie, some multiple of 0x1000).

The Hynix, though...I'm having trouble figuring it out. The sector I'm trying to erase starts at 0xf0000, so I'll use that as an example. The datasheet has a table listing what address to write the final command, and it says that the addres should be binary 01111??? -- the last three bits don't matter. But this table also seems to say these should be bits 19 through 12 (counting from zero). If that's the case, then we're just shifting the address over by one, which means writing the final command to 0x78000. But that doesn't seem to work.

In another part of the datasheet, it seems to imply that the sector address is just 8 bits long -- in which case, we're shifting the address right by 13 bits. That seems like a very strange number. It works out to a write to 0x78, and that doesn't work, either. The only thing that I can think of is that flash memory is supposed to be mapped to 0x20000000, so maybe it's 0x2f000000 that should be shifted as necessary. But that doesn't make any sense to me.

And the fact that the bits I managed to flip don't survive a reboot makes me suspicious -- am I trying to write to RAM or some such rather than flash? If anyone out there knows this sort of thing, I'd be grateful if you could take a look at the datasheet and see if you can figure out what I'm doing wrong.

Tags: nwr04b

Holy_crap.

title: Holy crap. date: 2005-10-11 18:35:40

From the ever-excellent Secrecy News comes this. I am agog.

Tags:

Sparcstaionlx:_netbsd_a_go!

title: SparcStaionLX: NetBSD a go! date: 2005-10-10 10:21:33

Picked up a 25-to-9 pin adapter yesterday, and in combination with a 9-pin null modem cable I finally managed to get at the Sun firmware prompt, and thus to install NetBSD over the network. Very nice, very simple install; the only problem I had was this one: the option root-path "/home/aardvark/netbsd-sparc/nfsroot" was too long, and the DHCP server just did not hand out that option -- no complaints or anything. Not good. Just starting up SSH for the first time right now, and holy crap it's taking a while to generate the host keys. --Only 24MB of RAM...huh, thought for some reason these things came with 96MB. Should probably just give up and generate host keys for the thing.

Tags:

NWR04B: Look at the board, dumbass

Okay, so if you look at the goddamned chip on the NWR04B, you see it's a Hynix HY29LV160-BT, which is not nearly the same as an SST39VF08. I've got the datasheet, at least, so I can look and see if there's maybe some simple change to the driver I'm using to make it work.

That's ugly, though (but no uglier than my debugging code...ugh), and I need to make that better. The MTD folks are no longer supporting the 2.4 kernel; however, looks like the uClinux folks have backported the MTD stuff. Which means I might try upgrading to the latest uClinux version and see if I can port my changes over...although frankly, I'm scared that I'll just be back at square one with this project and trying to figure out why the hell I can't print to the screen.

Yeah, it's an irrational fear, but if I can just break this out into a separate driver I'll be happy. Anyhow, it doesn't look like this particular chip is supported yet by the MTD people, so that's less of an incentive to move up. Or more of an incentive...maybe the closest I'll come to getting a patch into the Linux kernel tree. :-)

Tags: nwr04b

cfengine classes and shellcommands

cfengine is great, it really is. But there are some things that tripped me up. Often you want to set up a daemon to run The Right Way, which involves changing its config file. After that, of course, you want to restart it. What to do? The naive way (ie, the first way I tried) of doing things is:

control::
        sequence ( editfiles shellcommands )

editfiles::
        debian:
                { /etc/foo.conf
                        BeginGroupIfNoLineMatching "bar"
                                AddLine "bar"
                                Define restart_foo
                        EndGroup
                }

        freebsd:

                { /usr/local/etc/foo.conf
                        BeginGroupIfNoLineMatching "bar"
                                AddLine "bar"
                                Define restart_foo
                        EndGroup
                }

shellcommands::
        debian.restart_foo:
                "/etc/init.d/foo restart"

        freebsd.restart_foo:
                "/usr/local/etc/rc.d/foo restart"

However, the correct way of doing this is:

control::
        sequence = ( editfiles shellcommands )
        AddInstallable = ( restart_foo )

editfiles::
        debian:
                { /etc/foo.conf
                        BeginGroupIfNoLineMatching "bar"
                                AddLine "bar"
                                DefineInGroup "restart_foo"
                        EndGroup
                }

        freebsd:
                { /usr/local/etc/foo.conf
                        BeginGroupIfNoLineMatching "bar"
                                AddLine "bar"
                                DefineInGroup "restart_foo"
                        EndGroup
                }

shellcommands::
        debian.restart_foo:
                "/etc/init.d/foo restart"

        freebsd.restart_foo:
                "/usr/local/etc/rc.d/foo restart"

Without both the enumeration of all your made-up classes in AddInstallable and the enclosing of that class in quotes, cfengine will fail to do what you want -- and will do so quietly and with no clue about why. God, that took me a long time to find.

Tags: cfengine

First SuSE!

Got my first SuSE machine at work (well, not mine, but I'm setting it up), and I'm running into a weird problem with ypbind. If I call ypbind on its own -- no arguments -- it'll work. man page sez it's parsing /etc/yp.conf, which has the line "domain foo broadcast", and sure enough it broadcasts on a nice privileged port and binds to the server for domain foo. If I call ypbind with the -d argument, it stays in foreground, prints debuggin messages and fails like so:

do_broadcast() for domain 'foo' is called
broadcast: RPC: Can't encode arguments.
leave do_broadcast() for domain 'foo'
Signal (2) for quitting program arrived.

Well, crap. That's weird. After some searching, found [Debian bug

231593]1, which sounds pretty similar. They're blaming it

(tentatively, but) on libc. And but so there's these other bugs from, you know, Novell/SuSE, which also sound similar. And holy crap, where the hell have I been that I haven't heard of:

echo 65535 > /proc/sys/sunrpc/rpc_debug
echo 65535 > /proc/sys/sunrpc/nfs_debug

And other interesting behaviour from that second bug:

The problem in that bug was that immediately following a reboot, the NFS client will end up opening the same TCP port it used before, so it tries to establish a TCP connection from client:1234 -> server:2049. The server still has a TCP control block for this, and replies with a single ACK containing what it thinks are the right sequence numbers. That ACK is eaten by the conntrack module because the connection isn't yet in state ESTABLISHED.

Okay but back to our original bug: which appears to have been fixed now by adding one line to /etc/yp.conf:

broadcast
domain foo broadcast

Why the fuck that should work is beyond me...

Tags: suse!

Blood alone moves the wheels of history

From the ever-excellent GrigorPDX:

The images are originally from this site, an online collection/store of Soviet and Communist propaganda posters. The original images are hypnotizing, especially when (like me) you're fascinated by right-wing politics (and its fixation on left-wing/Communist conspiracies), melodrama and the paranoid style; never let it be said that the only place to find the three together is at Alex Jones' website or Sisters of Mercy lyrics.

These images are not profound observations on Bush2's presidency. It's not fair to compare Bush2 to, say, Stalin. But that doesn't stop them from being very, very powerful.

Tags: politics

NWR04B: What the hell am I missing?

I must really be missing something here, because I am unable to get this thing to write to flash at all. Here's what's going on in the kernel:

1. Turn off write protection; working. By that I mean that the kernel is successfully able to change a value in memory; the driver for this chip agrees with the datasheet from the HRI project that this is the bit that twiddles write protection.
2. The kernel tries to write the following mysterious values: 0xaa to 0x5555, 0x55 to 0x2aaa, and 0xa0 to 0x5555. The destination addresses (0x5555 and 0x2aaa) get mapped to the right area of memory: 0x20000000 plus the offset for mtd1 I've set up. Checking these writes show that they fail.
3. The kernel tries to write the first byte of data copied from the user request. Again, the address gets changed properly (0x20000000 + mtd1 offset). Again, the write fails.

(All this is in cx84200-flash.c, BTW.) I can think of two things...wait, three things...that might be happening:

1. There's a big change in memory mapping that happens some time after boot. Before The Change, flash begins at 0x0; after The Change, it starts at 0x20000000. I've been assuming, without much evidence, that the onboard bootloader does this flip before loading and running Linux. As ryanr suggested, it may not. In this case, I'd either need to make The Change myself, or else change the memory mappings.
2. There's some weirdness with little-endianness going on. Datasheet sez it's the 26th bit at 0x4000000 that twiddles write protection; this address is not affected by The Change. Maybe I'm simply counting bits from the wrong end...or something...arghh, this makes my head hurt. I think it's unlikely, though, that the developers would not have accounted for this.
3. Datasheet's wrong, or the chips not the same. Which'd suck.

Any other ideas, please let me know.

Tags: nwr04b

Stupid Debian syslog.conf

Debian. I love the Debian. But the logs in Debian annoy me.

1. You can't read 'em unless you're part of the adm group, or root. Not right.
2. Iptables denied packets get logged to kernel.log, messages.log and syslog.
3. What, precisely, is the difference between kernel.log and syslog? Between daemon.log and debug.log? Why is exim4/mainlog not symlinked to mail.log?
4. There's the annoying habit of printing far too much to the console. My time and my screen's real estate are precious -- doubly so when I'm in single-user mode (another rant) trying to fix something. The last thing I want is to have precious, precious vi sessions drowned out with kernel: IN=eth2 SRC=24.82.14.99 LEN=64 TOS=0x00 PREC=0x00 TTL=45 ID=40654 DF PROTO=TCP SPT=2678 DPT=445 WINDOW=53760 RES=0x00 SYN URGP=0. Fuck that noise!

FreeBSD, by contrast, has it fucking down. There's messages.log for everything you're likely to need as a normal user -- except mail messages, which are conveniently located at mail.log. For the sysadmin, you've got security.log (firewall stuff), auth.log (login stuff) and all.log (everything). It's simple, easy to understand and you can bloody well ready what you need to without becoming root. Sigh.

In other news, thanks to Mr. Dickens I came across Belanix today, a live OpenSolaris CD. I'm currently scrounging around for a spare machine to boot from, as QEMU seems to confuse it.

Tags: rant

NWR04B: My descent into little-endian binary arithmetic hell

Currently writing this entry in emacs. Once upon a time, I stopped using emacs for fear of what loading a 20MB editor would do to the mail server I was working on, and learned to love vi. Prompted by ESR's Art of Unix Programming, I've decided to try pick up emacs again. It's interesting....Anyhow: Right now I'm trying to figure out why the hell writing to flash on the NWR04B is not working. First off, I've edited the map file for the flash devices (drivers/mtd/maps/cx84200-flash.c for those of you playing the home game) so that I've got two partitions declared:

static struct mtd_partition cx84200_partitions[] = {
        {
                name:           "bootloader",
                size:           0x00020000,
                offset:         0x00000000,
                mask_flags:     MTD_WRITEABLE, /* force read-only */
        }, {
                name:           "root_fs",
                // Codeman's original:
                // size:        0x000fa000,
                // My efforts at making a root partition:
                size:           0x00040000,
                offset:         0x000f0000,
}

The first I'm not really doing anything with, but it could (as the title suggests) be turned into a bootloader partition someday. The second is where I'm concentrating my efforts. The read-only flag that was originally in there was removed once I figured out it might help matters. :-) Okay, so now what? Well, got a jffs2 image that I created, so let's try the obvious:

# cat test.jffs2 > /dev/mtd1

...and it just hangs. (I still haven't bothered to figure out how to make CTRL-C interrupt a process yet...something to do with the terminal, I think.) Up the debugging output and you see MTD_open, and then nothing. I had a look at the part of the driver (drivers/mtd/chips/sst39vf080.c) to see what's going on here, and I managed to figure it out a bit. The write operation tries to write one byte at a time, then reads it back to make sure it got read. If so, move on to the next byte; if not, try 256 more times (I guess waiting to see if it just needs a moment) and see if that works. If yes, next byte; if not, give up on the write entirely. I threw in some messages to track that, and one that shows what value it's reading back from flash after the write. After throwing in ridiculous amounts of debugging info to track this, it seems that the write of the first byte is simply not working. The write fails, and cat just keeps on trying (or something). A bunch of looking around finally turned up the MTD-JFFS-HOWTO from (I think) the guy who wrote the MTD driver. 'S full of all sorts of helpful hints, like:

• you can do cp test.jffs2 /dev/mtd1 to copy stuff to flash (but I got the same result as with cat),
• you can mount an erased block device, then just copy files to it w/o formatting it (mount /dev/mtdblock1 /mnt && cp foo /mnt), and
• you need to erase a flash partition if it has anything on it before just blindly copying files over.

Well, fuck. So I follow the directions for the 2.4 kernel support, and figure out how to compile the flash_eraseall utility. Wonderful! Ready to go! Just gotta erase this here partition, and... Only no, that doesn't work: I get the same error re: the byte not being written as before. I'm currently throwing in even more unholy amounts of debugging than before, and teaching myself the simplest bits of binary arithmetic you can image, in order to confirm that, yes, write protection is being turned off...I think. This little-endian thing still confuses the hell out of me. The datasheet sez that, at the address the enable_write() operation is accessing, there are 32 bits set aside for controlling the first bank of flash (which is what we're after here). The 26th bit is write-protect (1 for on, 0 for off). enable_write() reads all 32 bits at that address, &'s it with 0x04000000, and then WP should be off. So the unholy debugging shows that the long int being read:

• before turning off write-protect: 0x1400ffef
• what it wants to write to turn off WP: 0x1000ffef
• what it reads back after, checking how it went: 0x1000ffef

Okay, so that works. Maybe I'll give the flashcp utility (part of the MTD tree) a try and see how that goes.

Tags: emacs nwr04b

First post in a while...

...and it's another Wine problem. Coworker says he's having trouble, as of a couple days ago, running Wine on machine Foo, a FreeBSD machine that lots of people use. He's running into these errors:

err:ntdll:RtlpWaitForCriticalSection Critical section 0x65430070 wait timed out, retrying (60 sec) fs=008f
err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x280abf94

...which is pretty strange, and doubly so since he's only having this problem on Foo -- machines Bar and Baz are working just fine. I spent entirely too much time fucking around with --debugmsg +all, truss(1) and ktrace before I finally thought to check:

$ ps auxw | grep wine
coworker        81344  2.0  0.0     0    0  p3- Z    Tue11PM   0:00.00 (wine)
coworker        81341  0.0  0.2 11120 1452  p3- I    Tue11PM   0:00.34 (wine)
coworker        81343  0.0  0.0  3100  324  ??  Is   Tue11PM   0:00.12 wineserver

Sigh. Kill off 81341, the rest fell too, and it all worked again.

Tags: wine

Sigh_ii

title: Sigh II date: 2005-09-20 17:56:40

Seeking individual with access to quality lists of opt-in email addresses to mail to. Offer is to be geared to US addresses, Mortgage Refinance.

Why is it that only spammers advertise on Craigslist?

Tags:

FYT

FYT #1: New Firefox 1.5 Beta. It's great: wicked fast, and they've added drag-n-drop tabs. Slashdot comment pages render in a heartbeat. But it's pissing me off right now for two reasons. First, the Profile Manager only seems to come up if no other Firefox window is running. If there is another window running, it comes up with that profile no matter what arguments you pass (-P, -ProfileManager, -P Profile Name, ). (When I was first writing this entry, I tried that last one just to make sure. When the current profile came up yet again I closed it -- but closed the browser window that had this entry, too. I'm writing this in vi in an xterm now.)

This is irritating because I have two profiles: Default and Wide Open. Default is where I spend nearly all my time; Java, JavaScript, pop-up windows and flash are turned off; AdBlock shoots to kill; animations go once and then stop; I'm asked about cookies. I hate dancing baloney. Wide Open is where I go if I need to visit my bank's website (it's not that wide open, of course), or if there's something that won't work in my Default profile that I'm convinced is worth the effort (which doesn't happen often). Keeping two profiles is much easier than toggling all that nonsense each time.

Second, a lot of the extensions I love aren't yet ready for 1.5 (or at least, don't say they're ready...I seem to remember when the upgrade to 1.0 happened that you could edit some of the extensions directly and just lie about what version was required). Adblock is running -- if it wasn't for that, I don't think I'd be using the new version at all. But Session Saver, Sage and Mozex aren't, and I've come to rely on them. We'll have to see.

FYT #2: I went into work this morning to reboot a couple of servers. I'd let everyone know about it, and got up with my wife at 4.45am. But when I got to the building, the card that let me in the front door would not make the elevators go -- they just sat in the lobby waiting for, I don't know, drugs or Jesus. (Double punishment!) I'd used the card before to make the elevators go, so WTF? (Stairwells are not an option; you can't get into your floor [or any other] using your key or any access card.)

After failing to find a security guard anywhere, I called tenant services for the building. They said that the elevators might be turned off, but they couldn't be sure; I could get a better answer calling back during the week. (Fair enough, since our building's managed by a company that owns buildings all across Canada.) Oh, and security starts at 8am. Fuck. I'll have to reschedule for during the week, but after making sure that I can get in at 6am. Double fuck!

FYT #3: Why am I rebooting servers? Good question: they're running FreeBSD, after all, so it's not like it should need to happen all that often. The answer is: because amd sucks ass through straws. Not only does amd:

1. create a mess of symlinks (people who complain about SysV init symlinks messes need to look at amd: /home/foo symlinked to /net/machine/home/foo symlinked to /.amd/_mnt/machine/host/home/foo, the only place the directory is actually mounted) (interesting: quick Google for sysv init symlink turns up this post by my namesake)

2. interact badly with FreeBSD symlink caching (okay, FreeBSD's fault maybe)

but it will also get wedged sometimes, requiring a reboot -- and don't talk to me about the -r option for amd, because that simply doesn't work.

F'r instance: a while back one guy at worked moved from FreeBSD to Linux. I took the opportunity to give him a bigger hard drive; he'd had a second one, mounted at /home/foo/scratch, because he'd run out of room on the first. Unfortunately, one of the servers in question had /home/foo/scratch mounted at the time through amd -- and when his machine came back online w/no scratch directory, amd/NFS refused to umount it and refused to mount his home directory, because the bogus /home/foo/scratch was blocking it. That's what this morning's reboot was meant to get around. Okay, again, not all amd's fault -- NFS and me, not in that order -- but still.

I mentioned two servers, though, so what about the second? Aha, that's the symlink caching thing. We get around this by running a newer version of amd than is supplied w/FreeBSD; it doesn't have quite so many problems. But I'd missed the second server, and it didn't have the pointer to the newer version of amd. Again, my fault -- I should've caught this a long time ago -- but dangit, it shouldn't be necessary to do this just to restart amd. (I'm setting up cfengine to catch this sort of thing. cfengine rox.)

Minor update re: earlier problems with Vinum and a Maxtor IDE card: I picked up a new RocketRaid 454 that was reputed to work much better, plus had four controllers rather than two. Cheap, too -- $135. Long story short is that it still caused problems, I think; the machine seized up again in the middle of backups, apropos of nothing and with no message or panic. (Took a while for this to happen, though, so it was an improvement. I think I should've taken to heart the warning I got a while back that Vinum was not the most stable of code.

Tags: freebsd amd rant

New_machine,_or,_how_does_one_crack_solaris_2.8_again?

title: New machine, or, How does one crack Solaris 2.8 again? date: 2005-09-10 17:20:43

I went out to the swap meet today, but I couldn't get excited about anything there. I'd gone out hoping to find a Sun workstation or some such, and nothing. Closest I got to interesting was the guy offering a stripped bare P2 laptop -- no battery, no hard drive, no CD, no floppy, and a busted screen -- for $100. Oh wait, not interesting -- crack-induced. That's what I meant. (Yeah yeah yeah parts nothing.)

So I took off to go see Cal, since I was (sort of) in the neighbourhood. I was a lot happier when I found the upstairs where they'd hid the good stuff -- including a SparcStation LX and a Sun External Hard Drive, model 411 (4.5GB Seagate Barracuda, baby!). Even managed to find a keyboard and a cable and a 25-to-9-pin serial adapter. I was briefly tempted to buy an SGI keyboard, which looked like it'd been made to beat Communists to death, but resisted. Stuffed it in my backpack and brought it home...man, those things are pigs.

I hooked up a serial port, tried the magic keycodes, and nothing. After wiggling the keyboard cable a bit I could get the keyboard to beep at power-on (speaker in a keyboard? no wonder Sun's got such a good rep...:-), but nothing else -- not even the caps lock light. Well, what about networking? Yep, it's working, and appears to be convinced that it's kootenay.cs.ubc.ca judging by the ypbind requests.

A quick nmap and rpcinfo -p confirmed that all it had open was portmapper and ypbind. Allegedly, the POST has failed if the caps lock key doesn't flash -- but surely it wouldn't be running RPC services if that were true. ..which is going to make cracking it over the crossover cable a little difficult. It's not exporting any directories. I figure I can spoof the domain, but then what?

In other news: Firefox moved the tab select key from Ctrl to Alt (ie, Alt-3 selects the 3rd tab). I thought this feature was completely gone a few versions back, and was quite sad. Finally figuring it out makes me happy.

Tags:

NWR04B: Flash, telnetd, serial port...plus Ted Leo

Things are coming along on this router, and I've managed to make some progress on a couple of fronts.

First off, I've managed to get access to the flash memory on this thing. It's a little embarrassing, because I went through a lot of code in the mtd section of the kernel before realizing that I had simply not included the driver in the configuration file. Managed to learn a bit about how it fits together, though, so it wasn't wasted effort.

I've been able to get the contents of the flash out -- at least, the bit that's covered by the memory map that Codeman put together in his driver, which is about 1MB of the 2MB on board. Still, that appears to include the bootloader menu on this thing, which is good; with luck I'll be able to figure out the checksum for that, and maybe upload armboot or something. Of course, I could always just overwrite the flash directly...but I'm a little scared of that. We'll see.

The other thing that this'll lead to, of course, is including a filesystem in the flash memory itself. Right now I'm mounting everything by NFS, which is very flexible but not terribly self-contained. With something like JFFS2 and a separate partition for the kernel, I should be able to have something pretty skookum.

I ran into some weirdness with Minicom and the serial port: at random times, for reasons I couldn't figure out, the display from the router would get all scrambled. Letters and newlines would be dropped, or transposed, or just garbled out of recognition entirely. I tried everything I could think of: power-cycling the router, letting it cool (it doesn't take long for it to heat up, and things tend to go south pretty quickly when it does...must do something about that), swapping cables, swapping serial ports, exiting minicom, trying other serial port terminal programs (and let me tell you, there aren't many for Linux). Eventually I gave up and ran:

cat /dev/ttyS0 & cat > /dev/ttyS0

which worked perfectly: I could watch it boot, run commands, all that stuff. I could even see that the shell was using colours for ls, which made me wonder if maybe that was a problem.

Finally, though, it came time to try uploading another kernel image. I tried fooling around with sb, but while I could get it to upload to the router w/o problems, it was difficult to get the timing right when it ended, and the image didn't seem to load properly. All right, I thought, I'll use Minicom just for uploading. But check it out: when I ran Minicom again, it was perfect -- no display problems at all. Still don't know what changed, but I'm glad it's working again.

This led me to try getting the telnet daemon from BusyBox working...if I can't use a serial port, why not just use the network? But getting it going is going to take some work. With uClibc, there is neither a fork() nor a daemon() routine, both of which are used by telnetd. Instead, you get vfork, which lets a child run but blocks the parent until the child calls either exit() or exec. So, as uCdot points out, the trick is to do exec() the same program, but with a command-line option that tells the application that it's a child, and should be treated accordingly. Good trick.

By the time I realized that, though, it was midnight, and I figured I'd be too tired to do it coherently. And then I got the flash memory working, so I was distracted. Coming soon, though...

On another note: on Friday my wife and I went with the famous Victor Scott to see Ted Leo and the Pharmacists. Holy fuck can that man play. And his drummer! His drummer has the beard I want plus all the drumming chops in the entire world. The last drummer I saw who was anywhere close to him played for Wilco; before that, Lotion. Absolutely fucking amazing, and a must-see if you ever get the chance.

Hon. mention to opening band The Parallels, for whom I can't find a website. Great 60s-mod outfits and music, and a fun show.

Tags: nwr04b

I'm sorry...

...but when you use the word "solution", do you mean:

• program?
• identity token?
• software?
• shelf?
• algorithm?
• application?
• office suite?
• server hardware?
• server software?
• virus scanner?
• product?
• network?
• method?
• word processor?
• network protocol?
• scheduling software?
• email client?
• vendor?
• invention?
• operating system?
• windows manager?
• website?
• web application?
• authoring software?
• network client?
• web browser?
• API?
• ABI?
• encoding standard?
• bug tracking software?
• revision control system?
• wiki?
• contact manager?

I'd include links, but I think it would kill me.

Tags: rant

Trackback: A Tragedy in Three Acts

From Ant's Eye View:

You should assume that systems on the public network will be abused. This is a lesson as old as the Internet, but every programmer seems to have to learn it for him/herself: if you make a system available to the public, people will abuse it.

Worth reading.

Tags: toptip