What's new

Firmware update - Rev number mean anything?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

frankhere

Regular Contributor
Hello folks,
Just did an update... Simple question. Is there any logic/intelligence to the Rev numbers used by ASUS?
Being an X-engineer ( mechanical) , when we numbered projects/engineering drawings and their revisions there was a code/sequence to the number so one could tell a few things about the project and/or the drawing.
Hence my question.

Any logic or 'intelligence' given to the Rev numbers ?

upload_2020-3-16_12-52-40.png


thanks!!!
 
Sure there is! Internal (secret) code though. :)
 
The -gxxxxxxx part is the git hash from which they built the firmware.
 
The -gxxxxxxx part is the git hash from which they built the firmware.
thanks... and since I am not familiar with this, I looked it up:

At its core, the Git version control system is a content addressable filesystem. It uses the SHA-1 hash function to name content. For example, files, directories, and revisions are referred to by hash values unlike in other traditional version control systems where files or versions are referred to via sequential numbers. The use of a hash function to address its content delivers a few advantages:

  • Integrity checking is easy. Bit flips, for example, are easily detected, as the hash of corrupted content does not match its name.

  • Lookup of objects is fast.
Using a cryptographically secure hash function brings additional advantages:

  • Object names can be signed and third parties can trust the hash to address the signed object and all objects it references.

  • Communication using Git protocol and out of band communication methods have a short reliable string that can be used to reliably address stored content.

Sound about right ?
 
In less technical terms, software development is done by applying small changes to the source code, and each change is tagged with a unique ID. That ID is the hash value that Asus appends to firmware releases, so it allows them to know the exact code that was being used for a specific firmware release.
 
In less technical terms, software development is done by applying small changes to the source code, and each change is tagged with a unique ID. That ID is the hash value that Asus appends to firmware releases, so it allows them to know the exact code that was being used for a specific firmware release.
got it.... thanks.

So I got the tail end i.e. g3291119 and that will I.D. to the corresponding change in code ( flag).

The front end i.e. 3.0.0.4.386_25217 just looks like the iteration level of firmware. I was hoping it would tell me ~something like~ year, month , day , and the '25217' would clue in some additional info.

Again, it is just from a curiosity seeker and nothing that is of any great import... kinda like looking at a product code stamp and knowing its location, line number ( of production) , when it came off the line, simple stuff like that.

thanks again! Appreciated.
 
The front end i.e. 3.0.0.4.386_25217 just looks like the iteration level of firmware. I was hoping it would tell me ~something like~ year, month , day , and the '25217' would clue in some additional info.

No, they are just arbitrary numbers that they allocate and increment over the years. The first digit is 2.x for the very old blue firmware (from back in 2007-2010), 3.x Asuswrt, and 9.x for special test builds.

I never understood why some manufacturers feel the need to use so many different digits however. Asus added an extra digit around 2013 for some reason (it used to be just 3.0.0.4.xxx, then xxx became the major revision and a fifth number indicated the actual build number).

So, their own rules change now and then, just don't try to read too much into it, it only makes sense for the developers themselves. They tend to indicate separate code branches for separate product lines. 380 is the old codebase, got bumped to 382, then the few models that got AiMesh support got bumped to 384, the AC68U got some form of 385 hybrid builds God knows why, and the newest product lines are based on the latest 386 codebase. And all of these are developed in parallel.
 
As they leave back routers which lack some features it could be 68U got 385 because it wont support SmartConnect and newer ones get 386 with full SC support. Same like 382 for routers without Aimesh.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top