Bad firmware detection in WebGUI

[anonymous]

Can you embed a small checksum (sha1 or md5) routine in your web interface so that it reads the checksum of a firmware at the beginning or end of your firmware, and verifies it "BEFORE" flashing. You probably do it in Java/Script?. I seem to remember you indicating adding a small checksum file in the d/l directory, but hey who's gonna go through the trouble of actually verifying it "BEFORE" bricking their router. When I sometimes d/l your firmware and both mozilla & ie7 will show completion but only after flashing I find my router no longer works or crashes. I bet alot of "BAD" experience can be attributed to this!

[anonymous]

If SHA1 or MD5 checksum code is too complicated, perhaps an 8-bit or 16-bit checksum is a better alternative.

[soulstace]

Eko posted checksums, in a file labeled MD5SUMS located in the same directory as the firmware files. If you successfully verify the checksum, you can rest assured your download is not corrupted.

BrainSlayer?, all it takes to generate checksums of your builds..

.# cd /path/to/firmware/binaries

.# find . -type f -print0 | xargs -0 md5sum > MD5SUMS

Then upload the MD5SUMS file to the server along side the bin files.

Hope it helps,

~ss

[anonymous]

Few goes through the trouble of checking, embedding it within the firmware and auto verifies it the WebGUI DURING a flash is the most convenient and safest.

[BrainSlayer]

the checksum is always checked and it will be performed completelly if the router has enough memory free for storing the image into the ram. if this is not the case, the firmware will be flashed and a checksum error will be displayed at the end, but the router will not reboot in this case. so you're still able to reflash it

[soulstace]

If that is the case, why would his router no longer work and crash?

Does this also apply when flashing via tftp the very first time? Does the bootloader verify the checksum?

As I mentioned above, it is trivial to generate an MD5SUMS file. If you would kindly do that for all future releases, I am sure it would give many users peace of mind.

Thanks,

~ss

[anonymous]

BrainSlayer?

First, thanks a lot for considering our request!

Second, please realize that generating checksums on the file server is not ideal procedure. The checksums of binaries should be generated BEFORE uploading them to the file server. This eliminates the problem of files possibly becoming corrupted during an upload or other type of transfer.

I realize you probably can't do this now since most of the files likely only reside on the server itself. But in the future, consider generating MD5SUMS before you upload the binaries, for example in RC7 or v24 Final directories.

MD5 is a very strong algorithm for verifying the integrity of files. Perhaps even stronger algorithm than what is built into the firmware itself? Anyhow, if these precautions are taken, over time we should hopefully have much less users complaining of bricked routers!

Thanks again, and keep up the great work!

~ss

[soulstace]

Oh, this is off topic, but while I think of it.. I love Modular Majesty! You have great talent in music as well. Thanks for sharing it :D

~ss

[anonymous]

Checking the integrity of the firmware by the WebGUI inteerface, while the firmware still only resides on one's harddrive before it is uploaded is still the safest & best way of doing it. tftp will probably send anything to your router, so no checks are performed via tftp.

[soulstace]

Many routers cannot be initially flashed from the web interface. They must be flashed by tftp. In which case I think it is a good idea to verify the MD5 before sending it to the router. MD5 produces a very strong 128-bit cryptographic hash, which has much better chances of detecting any corruption.

I am not knocking your idea anonymous guy. I am simply stating why everyone cannot totally rely on the web interface to save us from corrupted flash.

[anonymous]

Yeah, understood, the initial, 1st flash from the stock is usually the most "dangerous". Later flashes can usually be recovered by tftp/bootwait=on.

[BrainSlayer]

@soulstace: yes, the bootloader does always check the checksum before flashing and refused todo it if the checksum is invalid

@anonymous the files cannot be destroyed while uploading. this here is no standard webserver from any ISP. its a own housed server system and we wont transfer files with ftp

@soulstace regarding modular majesty: there is more to come, we are working on finishing a full cd. just takes alot of time since i still spend all my time into dd-wrt

and to all. it does matter if you transfer the file with tftp (udp) or web (tcp) as far as the checksum is checked internally after the file arrived and this is done. so tftp can also be used as safe flashing way

[soulstace]

Thank you BrainSlayer? for helping to clear this up.

I can't wait to hear more tracks from the cd!

Have a nice day (:))

[anonymous]

​电子地磅解码器,吨位遥控器/本吨位遥控器引进日本先进技术研制而成，完全采用数字式集成电路技术，采用万能解码数据处理线路，适用于10----150吨以下吨位，无须对地磅作任何改动 具有防拦截，防扫描等优点，解码器安装于车上或离地磅8米以内，在电子称旁40米或60米以内，能控制电子称的数码数据，最小值20公斤，规格10 /15/20，此产品主要产生电子磁场干扰和控制，从而使吨位变大或变小，性能稳定可靠，体积小，遥控主机 解码处理器 如烟盒大小，遥控器配两种型号，隐蔽性强，附件含使用光盘一套，