I ported my WRT54G/GS v5-v6 firmware image builder, extractor, fixer, and viewer utility to linux, at the request of someone...

http://www.bitsum.com/files/wrt_vx_imgtool.zip .

The Makefile is for linux. No install rule, just run 'make'.

This was a quick port, so mistakes may be present. Hell, I didn't even test it ;p. Also, it doesn't use stderr like it should.

(Last edited by db90h on 14 Jul 2006, 04:14)

I've been working through your WRT54G5 CFE stuff, and think I've noticed a small bug in wrt54gv5_img.cpp (i.e. the source for wrt_vx_imgtool ):

$ diff -e wrt54gv5_img.cpp wrt54gv5_img.cpp_changed
884a
        }
.
877d

i.e. move the if(!pszCodePattern) inside the if(!bExtract && !bView)

This means that the -x or -v options won't work unless you use -c

But I didn't end up needing to use this anyway as vximgtoolgui.exe works fine with wine (I don't have a windows box) as I discovered eventually.

Also, a little bit off topic, the dd-wrt installation worked fine for me, but I couldn't get a working openwrt install - I tried to use http://downloads.openwrt.org/whiterussi … uashfs.bin - but after the tftp completed I just ended up with a blinking power light. Was this the right build to try?

Anyway, now I have found use for 2 v5 boxes I 'accidentally' bought last year which had been gathering dust on a shelf, so this is a result for me. With the linksys fw they would fall over regularly with wireless turned off when I only had http sessions running - useless. Great piece of work!

Thanks, I'm updating the version now. You may be the first person to actually use this tool ;p. I definitely went overboard on polishing it as much as I did, but I hate to release half-baked stuff.

Cool. I actually need to update that GUI tool so that it uses the new nvram modification code instead of the more brute-force mechanism it currently uses. But if it works no need to update it I guess . Note that I never did update the starting CFE in that, so it's default nvram parameters are a bit older/different than the current CFE the vxworks_killer images use. This will change soon anyway as I switch to a compressed CFE to make avaialble at least 128KB more flash ROM space.

You might try TFTP'ing the generic openwrt instead, as the current vxworks_killer CFE is from the WAP54Gv3 and it doesn't like the TRX header on the WRT54G image of OpenWrt. Otherwise, that should be a usable build though. For OpenWrt to be of any real use it needs to be micro-tized a lot, which compromises much of its design ideals. OpenWrt's philosophy just doesn't go well with size optimization. I am, of course, using OpenWrt for the VxWorks reversion firmwares, and it does work great for that specialized purpose.

I'm working on a super-micro build of OpenWrt, but have many other things to do.

A lot of people have got stuck with these boxes by accident, including me. I was happy to have made them easier to flash into usable boxes. They do a lot of jobs well, and mine does great as my primary AP (though I usually use my v4).

(Last edited by db90h on 26 Jul 2006, 13:29)

It worked now with the trx, after I eventually realised that I need to tftp to whatever I set lan_ipaddr to instead of 192.168.1.1. I had originally thought the bin version needed to be used (based on the filename in your VxWorks reversion firmware).

I agree openwrt is not very useable on the v5; in fact when dropbearkey was running initially it wasn't possible to do almost anything (lack of memory). Running ipkg update locks the machine up for several minutes before eventually failing.

dropbear is something I really miss from the dd-wrt micro, however.

Yea, I've run into memory issues too. Once I get a GS unit and enable 16mb on it, at least these they will not have such issues.

Another issue is how OpenWrt mandates use of JFFS2 (or some other RW filesystem) instead of exclusively using the nvram for configuration data. Once could move configuration data into nvram, but the more you do such things, the more you undo what OpenWrt is. For micro Operating Systems so much is different.

I could try squeezing dropbear into dd-wrt when I expand the available flash ROM space by 128KB. I think Brainslayer is going to use this space for language files, though I'm not sure. One issue with the micro builds of DD-WRT is there are so many different combinations of what packages a person might want that you can't build 100 different images. It'd be awesome to have a firmware image packager like OpenWrt has.