As i understand, your concern is the router being rebooted and not coming back, because the npk package was corrupted. is this correct? As mentioned by ‘cbrown’, the router verifies the file right after the reboot and before upgrading. so it would only make sense that it would stop upgrading if it couldn’t verify the integrity of the npk package. its quite easy to test actually. though i can’t afford testing it at the moment but one could open the .npk file with an hex-editor and edit couple of bytes, upload the npk file to the router, setup the serial port so he could see whats happening, and restart the router…
Seriously, give the Microtik guys some credit. They’re not stupid. How exactly do you think they’re checking that the packages “are not damaged” other than by using some kind of strong hash code (MD5, SHA, …)?
Unless you’ve tested and proven this yourself claiming that they’re “not check with md5sum or similar method” is a baseless accusation of incompetence verging on malpractice.
It’s probably more than just some hash verification. a lot of firmwares are signed with the manufactures master code. and unless the device could verify the signature, it wouldn’t do the upgrade. i wouldn’t be surprised if that was the case with mikroik firmwares as well. that being said, being able to see the md5 hashes on stored files in routeros might come handy. but i don’t think it’s a priority. If someone’s really that concern that everything together might go wrong including somehow a .npk package, could only be partially uploaded or being written exactly on a bad sector and then after restart, the router would stop working cause there might be a bug or something in firmware verification check done by the router, he could just upload the .npk package first, then download the uploaded package from the router, check the md5 hash to make sure the package still has the right hash even after uploading to the router, and then restart the router.
I mean you gotta stop being worried at some point. even if they implement manual md5 hash checking for routeros files, the next thread would be ‘what if that partially uploaded .npk package, ends up having the same md5 hash as the original one?’
Digital signatures either involve encrypting the whole file, or more commonly using a hash which is then encrypted. See the History section here: http://en.wikipedia.org/wiki/Digital_signature Also, strong hashes use crypto techniques anyway to minimize the chances of collisions and thus undetected errors, which is why all of the modern ones come from crypto researchers. Either way it’s kind of “a rose by any other name”.
A bit of research on npk reveals a lightweight packaging system http://code.google.com/p/npk/ which uses a block cipher called xxtea (http://en.wikipedia.org/wiki/XXTEA) for content verification. The wiki page doesn’t include enough details to tell how they’re using it, or if MicroTik’s npk is the same.
Lately we had some issues with 6.6 packages.
We where uploading routeros-mipsbe-6.6.npk file, but after reboot most of the packages was missing - only system package was installed.
In log files we had error that verification of package was unsuccessful.
