Modify

Opened 7 years ago

Last modified 3 years ago

#9504 accepted defect

mktitanimg: Titan images won't validate

Reported by: wert Owned by: florian
Priority: normal Milestone: Barrier Breaker 14.07
Component: toolchain Version: Trunk
Keywords: Cc:

Description

Titan images from a current trunk (r27096) will not validate on a Linksys WRTP54G (Vonage-branded) router, firmware 3.1.17. I have tried updating with all images through the web uploader; the following are my results:

openwrt-Titan-squashfs-code.bin: Uploads completely, web GUI gives message that router is going down for reboot, router appears to reboot, then after a minute or two, the Linksys web GUI reappears.
This appears to be the reboot problem mentioned in the wiki.

openwrt-Titan-jffs2-64k-code.bin & openwrt-Titan-jffs2-128k-code.bin: Uploads to ~26%, then the web GUI redirects me to /cgi-bin/firmwarefcg and Firefox gives the error "The connection to the server was reset while the page was loading."

openwrt-Titan-na-squashfs-code.bin: Gets to 20% uploaded, then gives the error message Status: Invalid Code Pattern
This is correct behavior, as the Vonage hardware should reject the NA image.

My guess (for the squashfs image) is that mktitanimg is somehow getting the checksum wrong. Has it been tested since this changeset?

Let me know what other information I may provide you to help debug this...

Attachments (0)

Change History (11)

comment:1 Changed 7 years ago by florian

  • Owner changed from developers to florian
  • Status changed from new to accepted

I do not own a Titan device, so I merged the patch as-is. Can you try to compare what the original tarball mktitanimg tool and the one we have produce for the same input file?

The stuck percentage information could probably come from a badly computed length information. Is your machine big-endian and we lack some byte-swapping maybe?

comment:2 Changed 7 years ago by wert

Little-endian here (AMD x86_64), tried the images from http://downloads.openwrt.org/snapshots/trunk/ar7/ also with the same results so I don't think the issue is specific to my machine. It looks like the original author of the mktitanimg tool was on a 32-bit system, so maybe that is part of the problem?

I'll let you know how things go with the original tarball of the mktitanimg tool when I get a chance.

comment:3 Changed 7 years ago by anonymous

Tried using the mkimage executable through the buildimg.sh script contained in the mkimage.tgz tarball, made ver1 and ver2 images (squashfs, jffs2 64k, and jffs2 128k), results are the same as above.

I looked at the file length header (in the squashfs image made with mktitanimg) at position 0x20 and it indicates the length of the file is 8 bytes less than the actual length, which is correct on a stock firmware, but if that file length is used to calculate the checksum, then it would cause the reboot problem because 0xDEADC0DE (at position 0x380000) would be included in that checksum.

comment:4 Changed 7 years ago by wert

Disregard the mention of the length header at position 0x20 above, the culprit is the length header for the root partition; it appears to indicate the partition is four bytes too long (i.e., includes the 0xDEADC0DE bytes). Any idea how to modify the mktitanimg tool to reduce the root partition length by 4 bytes and not include the 0xDEADC0DE bytes in the partition's checksum?

comment:5 Changed 7 years ago by wert

I checked the images generated by both mktitanimg and mkimage, they are both getting the CRC32s wrong for the partition headers and the entire image itself. You can verify this with a hex editor like Okteta which can calculate checksums. I'd be surprised if the CRC32 algorithm in mktitanimg is safe to run on a 64-bit architecture (lots of bit manipulation + unsigned longs, which are 32 bits on a 32 bit system and 64 on a 64 bit system).

Florian, do you have access to a 32-bit build box where you could build and run the mkimage tarball? I tried to check this on an old 32-bit computer of mine, but I'm having trouble starting it up.

comment:6 Changed 7 years ago by florian

You could setup a 32-bits chroot just to try building this. Using the 'linux32 chroot /path /shell' thi will be working.

comment:7 Changed 7 years ago by anonymous

I looked at the checksums after running mkimage on a 32-bit computer -- they're the same as the ones on a 64-bit computer. I looked more closely at the C code that creates the checksums, and they aren't CRC32 like stated in the wiki (or at least not the "standard" CRC32 as used by zlib, pkzip, Okteta, zmodem, and essentially everyone else).

So basically, I think the only thing wrong with mktitanimg is that it's getting the length of the non-padded root fs image wrong (i.e., including 0xdeadc0de).

comment:8 follow-up: Changed 7 years ago by florian

you are right, it's also covering the 0xdeadc0de word, can you look into checksuming the rootfs before this deadcode? Eventually, you can use something like mtd fixtrx which exists for both bcm47xx and bcm63xx.

comment:9 in reply to: ↑ 8 Changed 6 years ago by wert

Replying to florian:

Hi Florian, haven't checked back in a while, just saw your last message.
I played around with checksumming the partitions and then the whole image (-8 bytes) quite a bit, never got it to validate. Also tried zeroing out the "4 bytes for for actual partition length" and the checksum field, hoping that would essentially eliminate any check altogether, and then checksumming the image (-8 bytes), but had no luck there either.

How would I try out the mtd fixtrx code? Would it just be a compile of a current checkout?

Also, do you have any suggestions on where to modify the mktitanimg tool to reduce the calculated length of the root fs image?

comment:10 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:11 Changed 3 years ago by florian

If you revert 21767 and force a build of mktitanimg, does that work better?

Add Comment

Modify Ticket

Action
as accepted .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.