Firmware filename now included directly in the firmware

[HommeOursPorc]

The new filename feature by @wellloaded (and @MarsTomato) add the firmware filename directly into the firmware filesystem. The filename can now be found in the /rom/filename directory.

See: FreshTomato-Project/freshtomato-arm@02fcac3

So now I'm debating with myself on how to use this new feature. IMO, if there's no logic issue with the new feature, it should be the holy grail of firmware and hardware identification. I suppose this will be proven at the next FreshTomato release. If everything is fine, I'm trying to think of how else it could be wrong. The only way I see is if someone used the wrong firmware in the first place. Is there any other situation where it could be wrong?

It could replace my "online database" and my sketchy ID algorithm...

The cheapest way to proceed right now would be to use it as an extra verification step, but I think this is wrong and that it should be the other way around. The filename feature should be the ultimate reference and my current script ID function might be used for validation just to be sure. But this means the script still need the "online database"....

I know @wellloaded like the idea of a "accuracy meter", but I think that if the new feature is in fact bulletproof, there's no need for my ID function which mean no need to "guess" so no need for an "accuracy meter".

Sure this is only valid if the script is ever integrated to FreshTomato. If it is not included in the future, my ID function would be needed for version 2025.5 and older. (Since the new feature, I suppose, will be included in 2026.1)

So right now I'm thinking about all this and I'm looking for opinions on this, please.

🙂

[MarsTomato]

The only way I see is if someone used the wrong firmware in the first place

Yes, for exmple, this is at least one case, or someone just flashed the init-firmware (case netgear), there are probably more

but I think that if the new feature is in fact bulletproof, there's no need for my ID function which mean no need to "guess" so no need for an "accuracy meter".

mmmhh ... i still think it is a good idea to use the IDs / checks. The filename gives us (much) more stability (not 100% safety in my opinion), but like mentioned above,

• a wrong image (SDK OK) could be in place (still working, but not every case)
• a wrong branch/SDK image could be in place (mips branch mostly, no 5 GHz radio support, SDK5.10 <--> SDK5.110)
• RT-N66U can run with SDK5.110 OR SDK6 (mips)
• init-file in place
• etc

[wellloaded]

I would say not to overthink on this point. If someone has installed the wrong firmware, and it actually works, that's not a script responsibility to correct. Also providing the latest release of that "not ideal firmware" is unlikely to create new issues. e.g. I'd expect it ti work as the old one did with exactly the same secondary issues I suppose.

[HommeOursPorc]

• RT-N66U can run with SDK5.110 OR SDK6 (mips)

I will have to find my RT-N66U and do some tests. I think it is a good candidate to test this. Good idea 👍

Was the filename feature added to the MIPS branch?

[MarsTomato]

Was the filename feature added to the MIPS branch?

Not yet finished. ~50% work done.

[HommeOursPorc]

Was the filename feature added to the MIPS branch?

Not yet finished. ~50% work done.

Cool 😎

[wellloaded]

Was the filename feature added to the MIPS branch?

Not yet finished. ~50% work done.

did you try this?
FreshTomato-Project/freshtomato-arm@91a33ea#commitcomment-176013246

[MarsTomato]

Yes, but It is more work, more cases

[HommeOursPorc]

Just a little update here. I'm currently working on implementing this new FNAME stuff. It would be so easy if I could rely on it 100%, but since it could be wrong I need to put conditions and verifications in place which kind of bring me back to square one. I'm trying to figure out a logical way to calculate the accuracy/confidence of the identification and firmware choosing functions, but I didn't find a way yet since it is hard to calculate if one id method doesn't match with an other id method....

[wellloaded]

I'm not aware of any issue with the filename discrepancy Vs model name?
For ARM (where I believe the ftup should be introduced first), I'd expect this to work. Has anyone reported this?

[HommeOursPorc]

No, it was not reported. AFAIK it works fine. I wish I could just use it at is and dump all my other identifying stuff...

[wellloaded]

No, it was not reported. AFAIK it works fine. I wish I could just use it at is and dump all my other identifying stuff...

Have you encountered any issue trying to do a match against filename? A regex can do this nicely.

About the rest of the identification, it can either be removed (as hopefully is not needed) or left there as a backup? I personally don't have strong opinions in regard.

[HommeOursPorc]

No, it was not reported. AFAIK it works fine. I wish I could just use it at is and dump all my other identifying stuff...

Have you encountered any issue trying to do a match against filename? A regex can do this nicely.

About the rest of the identification, it can either be removed (as hopefully is not needed) or left there as a backup? I personally don't have strong opinions in regard.

I didn't test it much, but I do have verification against the FNAME.

Look at @MarsTomato post:

mmmhh ... i still think it is a good idea to use the IDs / checks. The filename gives us (much) more stability (not 100% safety in my opinion), but like mentioned above,

• a wrong image (SDK OK) could be in place (still working, but not every case)
• a wrong branch/SDK image could be in place (mips branch mostly, no 5 GHz radio support, SDK5.10 <--> SDK5.110)
• RT-N66U can run with SDK5.110 OR SDK6 (mips)
• init-file in place
• etc

[wellloaded]

My view (as discussed in other threads) is that we can't account for initial wrong image installations.
Also, if it works currently it is very likely to work on the "same wrong" but upgraded image.

The rest you mention is MIPS, right? I'm not sure I understand the init reference though btw.

Speed beats quality. In the interest of time and to get the ball rolling I would focus on ARM only at this stage and on fname specifically. This can already work and will trigger feedback suggestions from users which is extremely important.

We save safeguards in place, right? We also discussed prompting the user with a popup verification on the model before proceeding. Is there anything else that raises the risk level that we are currently missing in the context of ARM? If there's any doubt on fname precision, perhaps post on the forum asking for feedback on the current reported filename Vs actual HW model? I checked all my models and they look ok.

Once the MIPS is address perhaps we can consider extending the functionality at that point of time?

[HommeOursPorc]

My view (as discussed in other threads) is that we can't account for initial wrong image installations. Also, if it works currently it is very likely to work on the "same wrong" but upgraded image.

I agree with you on this.

The rest you mention is MIPS, right? I'm not sure I understand the init reference though btw.

In the code that populate the t_model_name nvram variable, I would add a new variable specific to the "named" firmware. I mean that routers whom have their model name written in the firmware file name would have a dedicated nvram variable to quickly match the firmware and the device. But if your make file FNAME stuff works correctly, then we probably don't need this.

Speed beats quality. In the interest of time and to get the ball rolling I would focus on ARM only at this stage and on fname specifically. This can already work and will trigger feedback suggestions from users which is extremely important.

I'm not sure the script is a good idea.... Pedro have mentioned space issue lately and he will be the one stuck to upgrade the script once it is merged in.... I'm still not sure if he want to be any part of this 🤣.
Maybe a slimmer version focusing on identifying and fetching the firmware before passing the firmware to the already in place upgrade code would be a cleaner solution? I already discussed this elsewhere, but look like it felled between the cracks and got no replies...

We save safeguards in place, right? We also discussed prompting the user with a popup verification on the model before proceeding. Is there anything else that raises the risk level that we are currently missing in the context of ARM? If there's any doubt on fname precision, perhaps post on the forum asking for feedback on the current reported filename Vs actual HW model? I checked all my models and they look ok.

Once the MIPS is address perhaps we can consider extending the functionality at that point of time?

👍