can't extract dd-wrt v24 preSP2 for buffalo whr-g300nv2

[nwmonster]

can't extract dd-wrt v24 preSP2 for buffalo whr-g300nv2

[GoogleCodeExporter]

The extract-ng.sh script properly extracts this firmware. build-ng.sh builds 
the new firmware, but the resulting firmware size is larger than the original 
firmware image. 

Other than the file size, the new firmware looks OK, but I don't have this 
router so it is untested - tread with caution.

Original comment by [email protected] on 5 Sep 2011 at 12:56

• Changed state: Accepted

[GoogleCodeExporter]

It used to be the case that DD-WRT uses a variant of squashfs-lzma that tries 
various compression parameters to determine the most optimal. I would imagine 
this is still the case. IIRC, I limited the search for the most optimal 
parameters so it didn't take all day. This may be the cause of what should be a 
slight difference in file size.

Original comment by [email protected] on 5 Sep 2011 at 12:58

[GoogleCodeExporter]

One more thing: make sure you get the latest repo updates, some bug fixes for 
extract-ng.sh and build-ng.sh were checked in today.

Original comment by [email protected] on 5 Sep 2011 at 12:58

[GoogleCodeExporter]

Just confirmed that the mksquashfs-lzma from the dd-wrt svn repo builds a 
smaller squashfs image than the current version in FMK (in fact, even smaller 
than the squashfs image in the dd-wrt firmware). Will update the damn-small 
varient in FMK after further testing.

Original comment by [email protected] on 5 Sep 2011 at 1:40

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Sounds good. If no output is shown during its very long compression process, I 
will add some status indicator to it. I could even throw in a keypress, 'hit a 
key to just use the best we found so far'.

Original comment by [email protected] on 5 Sep 2011 at 1:47

[GoogleCodeExporter]

The extra size is only an issue as the new scripts expect the size to not 
change and the CRC's and size values in the firmware headers won't be properly 
updated if the size of the image changes. 

Of course, this can be - and probably should be - changed, but I also like to 
keep the sizes the same in order to ensure we aren't going to accidentally 
overwrite something critical in flash. Without knowing the MTD layout for each 
and every router, this can be kind of important. :P

Original comment by [email protected] on 5 Sep 2011 at 1:50

[GoogleCodeExporter]

Indeed it is, you are very right. Related, one of the most common issues users 
have had is going over the size threshold for their device. Whether we should 
warn if the new size is larger than the original, I don't know. We could infer 
from the original firmware image size the likely MTD layout and firmware size 
limit, then check against it. However, all that is more trouble than I want to 
go to, so its one of those 'put off until forever' ideas ;p.

Original comment by [email protected] on 5 Sep 2011 at 1:59

[GoogleCodeExporter]

New squashfs code checked in, resulting firmware image is now the same size as 
the original firmware image.

Right now, the build-ng script will throw an error and quit if the resulting 
firmware image gets larger than the original.

Original comment by [email protected] on 5 Sep 2011 at 4:24

• Changed state: Fixed

[GoogleCodeExporter]

many thanks to all of above comments.

btw, the extract-ng.sh needs binwalk to work properly. this tools can be found 
at http://code.google.com/p/binwalk/.

Original comment by [email protected] on 5 Sep 2011 at 12:47

[GoogleCodeExporter]

Yes, the latest FMK check in includes and builds the binwalk 0.3.9 source.

Original comment by [email protected] on 5 Sep 2011 at 2:31