WRT FAIL
by David Kowis on May.12, 2010, under Linux, Source Mage
I had posted previously about setting up a WRT54G-TM running OpenWRT to be the router for my network. I thought it would be the perfect router, low power consumption, low heat, no moving parts, and wifi included. Unfortunately it did not work well at all. My advanced traffic shaping configuration killed the poor thing. 200MHz is apparently insufficient hurtz to handle the large number of interrupts for packet processing and marking. I was told it might be a driver issue, but I wasn’t aware of any other drivers that I could have loaded to offload those interrupts. So the system spent > 70% of it’s CPU time in System IRQ handling. When it was under heavy packet load, something the original router setup would’ve handled without batting an eye, it would drop connections and eventually die. It wouldn’t respond to pings, nor would it forward traffic adequately. NAT + Traffic shaping + bittorrents = DEATH. Not to mention that syslogd eventually threw the thing into a kernel panic. Oh, and the b43 driver also panicked the kernel soon after turning on the wifi.
So I’m back to the original setup, with an old (1998) left-over 2GB hard-drive, and a modified Source Mage install. It’s in good shape, with some tmpfs stuff for things that write to the disk in order to hopefully prolong the life of the disk. I took a clonezilla snapshot of it as well, so when the drive dies, I can throw in a new (also old, I have several 2 to 4 GB drives that are in the closet that still work) one, and the router will be back up in a few moments.
Whilst it was unfortunate that the router wasn’t a good fit for my particular use, perhaps I’ll find another use for it. Since there are two Serial ports trivially accessible on the device, perhaps I’ll get a GPS module and set it up in the car as a mobile automatic war-driving toy. I’ve found instructions to hook up an SD card to it as well, that would give it plenty of easy to replace storage.
It was an interesting experiment, and I’m somewhat sad it didn’t work out.
WRT54G-TM Hacking
by David Kowis on May.07, 2010, under Linux
A while ago, I purchased some WRT54G-TM routers from the TMoblie store near by. Apparently they were part of a push by TMobile to further their UMA stuff. People could purchase a router with wifi at the same time as purchasing their phone, if they didn’t already have one. I guess sales didn’t turn out so well, because TMobile was selling them for $20 each and trying to get rid of them all. I bought two.
Turns out these things are really just WRT54GL‘s, the Linux one that they sell for like $70 that they have not screwed with so you can hack them and run any of the (not all)Linux wrt distros out there. Except it’s even better, because it’s got 32MB of ram and 8mb of flash, instead of half that like the standard WRT54GL. It requires a bit more voodoo to unlock (and after flashing dd-wrt, you can flash openwrt, or anything else,) but not at all difficult.
With the recent release of BackFire from OpenWRT, which coincided with my old SMGL router’s hard drive failure, I have set up that router on my network. It worked well for a few weeks, but recently has started flaking out and completely disappearing from my network. A gateway that refuses to respond to anything on the network is not particularly useful. So, to the internets I went. I discovered how trivial it would be to hook up one of the serial ports on the thing to my computer. A bit of soldering later, and I have a log of everything that comes out of the console of that box on my server. Hopefully, the next time it flakes out, I’ll have a logged kernel panic that I can submit it in a bug report. I might even be able to figure out the solution and post it along with the bug.
Additionally, as a solution to keep the network alive right now, I have set up a Nagios event handler to tell the UPS the router is attached to, to restart. This successfully power cycles the two gateway devices: ATT’s 2-wire thingy, and my OpenWRT router. So, my network has a limited self-healing ability now, which is, of course, a band-aid. However, until I can figure out what’s wrong with the router, it’s the best option that I’ve got to keep things functional. Especially when I’m not at home, and it dies (which seems to be the only time it dies…)
xm pause testing
by David Kowis on May.01, 2010, under Linux, fedora
When I got xm pause working, I was quite excited. However, it doesn’t work in all cases. I’ve done some testing to figure out what combination of things cause it to fail.
All of this is using xen 4.0 hypervisor, the kernel from here, and a pvops domU kernel built by hand.
- Using blktap2 backed disks in the vhd format (vhd-util create -n name -s 1024) xm pause fails. The user-space disk devices are never released, and only a hard reboot will get it to function again.
- Using a different driver for the blktap2, tap:tapdisk:aio, also fails to pause.
- Using phy:/ backed disks, say through LVM works fine. The domU will pause, and resume nicely.
It would seem that there is something not quite ready to be used regarding the blktap2 backend, so I wouldn’t reccomend using it.
I also tried to use the original tap:aio drivers, but I cannot as they don’t seem to exist. I guess I’ll be using the plain old phy:/ drivers for now. That’s not a big deal as I don’t have any second xen machine to do anything fancy that the tap:aio drivers would provide. I guess I should poke on a mailing list or something.
xen pv_ops domU
by David Kowis on May.01, 2010, under Linux, Source Mage, W00t!, fedora
…means I can finally pause/suspend a domU vm again!
Finding this information should’ve been obvious, but for some reason it wasn’t. Maybe I had some silly mental block or something. Anyways, get the kernel source from here. Then build it for your architecture. If you want to build a 32-bit kernel for some 32-bit domUs, and you’re running on 64-bit, it’s as easy as make ARCH=i386 <target>. This does work and I’ve verified it. Had to fool a Fedora domU into beleiving that it really was a 32-bit system.
I’ve found make tarbz2-pkg to be quite handy in packaging up the kernel to be deployed.
I have verified that this works in Xen 3.4.2 on a patched 2.6.29.6 kernel.
On my Xen 4.0 test box, it fails to suspend. I’m using the blktap2 stuff, and perhaps that doesn’t pause well. As far as I understand it, that blktap2 should not affect suspending, but I’m going to test it with some logical volume based vms. I usually use the lvm backed disks anyway, but the blktap2 stuff offers some interesting features, if it were to work. Not being able to pause stuff probably isn’t good, but again, I’m not sure what’s causing it.
Apparently, that is what’s causing it. The domU will pause and unpause just fine when using an lvm backed disk, rather than the blktap2 ones. I should test a couple of other combinations to see if things like tap:aio will behave, as that’s needed for nifty things like remus.
Broke my database
by David Kowis on Apr.26, 2010, under Linux
Last Friday, whilst I was fiddling with innodb performance settings, I apparently managed to totally hose any innodb tables. My blag and my dspam signatures were, thankfully, the only ones that ate it. Of course, I didn’t have backups, so that kinda sucked. I restored the blag from the most recent backup I had (February 12th) and then recreated manually the few posts I knew were ahead of that.
I hacked up some backup scripts in ruby, I probably could have done it in pure bash, but I felt that this was cleaner.
