Unreproduced reports of bad firmware images for DD-WRT v24 SP1

Started by Jeremy Collake, October 18, 2008, 01:52:23 PM

Previous topic - Next topic

Jeremy Collake

I've had two reports of badly generated firmware images for DD-WRT v24 SP1. In my tests though of the same firmware images, I have no problems with extraction, building, and then re-extraction. They further work fine on the flashed routers.

To determine what is going on, we'll need someone to take the time to figure it out, or at least start to narrow down the circumstances in which this happens.

I test with a UBuntu x32 linux distribution. Under what platforms do users who see this problem use? Are you use the FMK as root, or a standard user? I'm extracting to an ext3 file system, what are you?

Have other users had successful results with DD-WRT v24 SP1 and pre-SP2 images?

Since the FMK is a totally free project, user support is critical.
Software Engineer. Bitsum LLC.

retromodcoza

Jeremy - Yep ... The firmware for SP1 come out bad for me.

I'm on Kubuntu x32 logged in as root. Extraction and Building seem to work. Uploading the firmware works - succeeds and then bricks the router. Im using the latest version of your software from Google code ( not the latest build from your website )

If you have any ideas or need further info...let me know...

Thanks
Lloyd


Jeremy Collake

Did you try extracting and building as a standard user instead of root? Perhaps the filesystem permissions are the issue.

In my tests, using a standard user, I did fully boot and telnet into the router to verify the successful flash of the image. So, it wasn't an insufficiency in my testing, I don't believe.
Software Engineer. Bitsum LLC.

retromodcoza

Hey Jeremy

Heres what I tried and the result..

1) Extracted DD WRT - v24 SP1 under normal user. Got permission error. Changed permissions on folders. Extraction now worked , as well as building. Same result - upload with success then bricked. Unbricking my linksys 54GL wasn't fun ( I had to rewire it ) so I'm using a Asus 520 GU.

2) Tried the same with V24 (not sp1) std - same result...bricked - which maybe means its an error larger than the sp1 upgrade because I then tried with the mini-v24 ( not sp1 ) and it extracted , built , flashed and worked perfectly.

Bear in mind I did a straight extract and rebuild - no file changes were made. Also note I tried flashing via tftp and web GUI in all cases. When I uploaded a failed firmware I could ping the router - but not tftp , telnet or get into the web interface.

Note sure if that helps - but I would really like to fix this... ;D ;D ;D

Thanks for your time helping me with this....
Lloyd


Jeremy Collake

Hmm.. Dunno, I really need to see the serial output from one of routers flashed with a 'bad' images. It sounds like a file system error of some sort for sure.
Software Engineer. Bitsum LLC.

retromodcoza

Ok - I can brick another router...but how do I get the "serial output" ? Can you list some steps?

Alternatively , I can send you a zip with the produced firmware for you to take a look at.  If you send me your email addy via PM I can get it to you....

Jeremy Collake

#6
First try an experiment, delete the working directory you previously used completely and try the process again as a standard user. The lack of correct ownership or filesystem permissions in the extracted filesystem seem very likely.

The serial output is unobtainable without a serial cable properly connected, so its not something you can do real quick.
Software Engineer. Bitsum LLC.

Jeremy Collake

Oh, and, yes, you may end up in the same situation as before.. but these routers should be easily recoverable using the recovery mode httpd (hold down reset button while powering on router).

I'll try extraction and building as root to see if that's the problem. LIke I said, that's my best suspicion right now, as it could cause problems with the files being owned by root. When you previously adjusted the ownership (though you indicated permissions), you may have removed, or not set, the +x bit for other users, which would have resulted in a similar problem.
Software Engineer. Bitsum LLC.

Jeremy Collake

I made some experimental changes, which shouldn't be necessary, but I figured anything is worth a try.. Checkout the latest version from the repository and give it a try.

If I ever get the time I will dig my WRT54G back out and attach a serial port to try one of these bad images that users have built. I've only done test flashes of my own built images of DD-WRT v23, v24, v24 SP1, and v24 pre-SP2.
Software Engineer. Bitsum LLC.

retromodcoza

Thanks Jeremy. I won't be at my PC's this weekend - so on Monday morning I will try your suggestions and give you some feedback....

Thanks for following up on this... ;D

retromodcoza

Jeremy....

I fixed it - but probably not in the way that you would like....

I installed 0.52 beta of the mod kit that I found at http://www.dd-wrt.com/dd-wrtv2/down.php?path=downloads%2Fothers%2Ftornado%2Ffirmwaremodkit2-new-LZMA

I extracted it the same way as I did with 0.6 - I did not change permissions or anything and I modded my firmware and it worked.

Im happy now - but I'm more than willing to help you get to the bottom of why it isn't working. The only thing I can think of is that I'm running a version of Kubuntu that hasn't been upgraded in 6 months - and some newer files are required as the base for your program.

I have tried the steps above on 0.6 with no effect. I'm not really sure what to do next. I made sure the firmwares and the files were writeable by everyone...

Thanks for all your help - I appreciate it  ;D

Jeremy Collake

Hmm, thanks for the info. Yea, I no longer believe the permissions or file ownership are the problem. That was just a guess, and a bad one.

I am not sure what is up with v0.52 working. It shouldn't even support DD-WRT v24. Perhaps someone else modified the kit to add v24 support, and their mechanism worked better. They perhaps used a direct copy of DD-WRT's squashfs-tools instead of a tweaked one, or perhaps the script behavior is different. I tried downloading it, but it appears to no longer be on the server. Perhaps because it does work? ;).

I really dunno. I will do some more testing when I get a chance and the impetus. I will figure it out sooner or later.

You can always try using v24 images instead of v24 SP1 or SP2. In at least one case, a user was able to successfully extract, rebuild, flash/test v24 images when v24 SP1 images had failed in the same way as yours.


Software Engineer. Bitsum LLC.

Jeremy Collake

I was just thinking.. one of my more recent changes was to improve OS X compatibility I killed the multi-threaded testing for the most optimal LZMA parameters. This results in slightly larger firmware images than DD-WRT would build by default. If users accidentally exceed the maximum size of the firmware, then that could cause problems.

You could try checking out revision 121 of the firmware mod kit:

svn checkout http://firmware-mod-kit.googlecode.com/svn/trunk/ firmware-mod-kit-read-only -r 121

That version does the whole brute force testing for best compression parameters like DD-WRT v24+ does.
Software Engineer. Bitsum LLC.

muzzak

I can confirm the same bug, reproduced both on revision 121 and the latest stable release of the fmk.

Running latest Ubuntu 32bit
Linux murray-laptop 2.6.24-21-generic #1 SMP Mon Aug 25 17:32:09 UTC 2008 i686 GNU/Linux

Reiserfs running as root.

Perhaps its the image?

netnode

Hi
Just to confirm I get the same on v24 sp1

Running on Debian Etch
ext3 fs
as normal user
using svn head version of the kit

No error reported however buicks wrt54gs v1 every time

RyeBrye

#15
The download link to the modified v51 is here:

http://www.dd-wrt.com/dd-wrtv2/downloads/others/tornado/firmwaremodkit2-new-LZMA/firmwaremodkit2_x86_64.tar.bz2

I found it by going to here: http://www.dd-wrt.com/dd-wrtv3/dd-wrt/downloads.html and navigating down to others / tornado / firmwaremodkit2-new-LZMA - it seems the direct link posted earlier might not work anymore.

This one did produce a working image for me.

The v62 or whatever the latest is seems to extract the image fine, and doesn't give an error when it recreates it. When I try to run extract_image.sh on the built image, it fails with an error like this:


Firmware Mod Kit (extract) v0.62 beta, (c)2008 Jeremy Collake
http://www.bitsum.com
Checking for updates ...
  You have the latest version of this kit.
LINUX system detected. Compatibility ok.
Testing file system of ../../test_working_dir/ ...
Building tools ...
Build seems successful.
Preparing working directory ...
Removing any previous files ...
Creating directories ...
Extracting firmware
Attempting squashfs 3.0 lzma ...
Trying 'damn small' variant - used by DD-WRT v24 ...
*** glibc detected *** src/squashfs-3.0-lzma-damn-small-variant/unsquashfs-lzma: free(): invalid next size (fast): 0x0000000000d245a0 ***
.. TRUNCATED BY FORUM ADMIN ..
Error: filesystem not extracted properly.
  firmware image format not compatible?


Jeremy Collake

Can someone please check the latest revision of the firmware-mod-kit to see if the DD-WRT v24 problem still persists? I reverted some optimizations I made to the LZMA damn-small-variant code. It may very well fix it.

Revision: 153
Software Engineer. Bitsum LLC.

Jeremy Collake

#17
Someone finally tested the latest revision of the FMK. It DOES fix this problem. I have uploaded a new final build, which should be of comfort to many.
Software Engineer. Bitsum LLC.