Some suggestions for firmware compatibility.

[xianglin1998]

1. The part related to the communication protocol cannot be changed at will.
2. Those involving communication command codes and communication return parameters cannot be changed at will.
3. When adding any command, its function definition should be considered, and the functions related to HF should not be placed in the Device category.
4. If you need to delete the command, you can only mark it for deletion, remember not to rearrange the communication command code.
5. In any case, the client must be able to obtain the software version code for compatibility processing.
6. The current firmware version lacks many commands, which will lead to the client's functions being too simple or too difficult to use. It is necessary to wait for the v1.1 version to be released when the firmware is relatively complete, and update iteratively and perform compatibility processing from the v1.1 version.
7. After the v1.1 version of the firmware is released in the future, changes that affect compatibility should be more strictly reviewed to prevent the new firmware from being unable to run on the old client.
8. Ideally, when a user uses a new client with an old device firmware, there should be no compatibility issues. In other words, users can still use the old functions, but only the functions provided by the new version of the firmware cannot be used. (For example, the device firmware v1.2 provides the function of StaticNested decryption, but the GUI/CLI recognizes that the device firmware version used by the user is v1.1, then the user should be prohibited from running this function, and the user should be guided to update the firmware)
9. Starting from version v1.1, a compatibility adaptation document needs to be provided, and any client can perform compatibility adaptation according to the guidance of this document. For example, it is described in the document that the v1.2 version adds the collection command of StaticNested decryption parameters, and describes the specific meaning of the collected parameters, then any client can provide the StaticNested function when it detects that the firmware version is v1.2. (ideally)

Note: We are currently in the stage of ChameleonUltra's firmware function construction and community ecological construction, and we can temporarily ignore the strict restrictions on adding/modifying commands.

[xianglin1998]

Repositories related to Chameleon Ultra:

ChameleonUltraGUI (Flutter) By @GameTec-live

[doegox]

Can you elaborate what you mean by "the functions related to HF should not be placed in the Device category." and where it is in the code ?

[doegox]

"new firmware from being unable to run on the old client" => do you want to be always capable to run all newer fw with any old client ? That means potentially being stuck with some initial choices that cannot be changed anymore. On the proxmark3, we ask ppl to run fw and corresponding client version, and the client is able to detect automatically version mismatches and alert the user on the need to reflash the firmware, for example. I can think of running a fw newer than the client only for things like an outdated GUI or mobile application not properly maintained.

[xianglin1998]

Can you elaborate what you mean by "the functions related to HF should not be placed in the Device category." and where it is in the code ?

The CMD code define at Here (Just to categorize the functions of CMD.)

[xianglin1998]

"new firmware from being unable to run on the old client" => do you want to be always capable to run all newer fw with any old client ? That means potentially being stuck with some initial choices that cannot be changed anymore. On the proxmark3, we ask ppl to run fw and corresponding client version, and the client is able to detect automatically version mismatches and alert the user on the need to reflash the firmware, for example. I can think of running a fw newer than the client only for things like an outdated GUI or mobile application not properly maintained.

Indeed, the problem for "That means potentially being stuck with some initial choices that cannot be changed anymore" is very annoying, and it leads to a lot of code in our repo for compatibility with older clients. So we can treat item 7 loosely or ignore it, or find a better solution. but most users don’t know how to update firmware or don’t want to update firmware, so we maybe need to treat item 8 strictly.

[GameTec-live]

"new firmware from being unable to run on the old client" => do you want to be always capable to run all newer fw with any old client ? That means potentially being stuck with some initial choices that cannot be changed anymore. On the proxmark3, we ask ppl to run fw and corresponding client version, and the client is able to detect automatically version mismatches and alert the user on the need to reflash the firmware, for example. I can think of running a fw newer than the client only for things like an outdated GUI or mobile application not properly maintained.

We can treat item 7 loosely or ignore it, but most users don’t know how to update firmware or don’t want to update firmware, so we maybe need to treat item 8 strictly.

i might build dfu into the shell, for the gui, foxushka is working on dfu for that (maybe even autopull latest build from github? ;) )... so firmware updating shouldnt be hard or smthng.

[xianglin1998]

When I manage our company's hardware/software projects, I really only consider new clients running devices with older firmware. So every time I will notify customers to update to the latest version in time when the software is updated.

[doegox]

rather than relying on global fw version we can also have ways for the fw to report what are the available commands. As we do in https://github.com/RfidResearchGroup/proxmark3/blob/master/armsrc/appmain.c#L445-L572 So client does not have to know and maintain a map of all existing fw versions and their capabilities, it simply queries the fw that tells what it supports.

[xianglin1998]

"new firmware from being unable to run on the old client" => do you want to be always capable to run all newer fw with any old client ? That means potentially being stuck with some initial choices that cannot be changed anymore. On the proxmark3, we ask ppl to run fw and corresponding client version, and the client is able to detect automatically version mismatches and alert the user on the need to reflash the firmware, for example. I can think of running a fw newer than the client only for things like an outdated GUI or mobile application not properly maintained.

We can treat item 7 loosely or ignore it, but most users don’t know how to update firmware or don’t want to update firmware, so we maybe need to treat item 8 strictly.

i might build dfu into the shell, for the gui, foxushka is working on dfu for that (maybe even autopull latest build from github? ;) )... so firmware updating shouldnt be hard or smthng.

We should consider compatibility support for more possible ChameleonUltra clients. Therefore, the convenient DFU can indeed solve some compatibility problems, but it still needs to do a good job in pre-operation of compatibility processing.

[xianglin1998]

rather than relying on global fw version we can also have ways for the fw to report what are the available commands. As we do in https://github.com/RfidResearchGroup/proxmark3/blob/master/armsrc/appmain.c#L445-L572 So client does not have to know and maintain a map of all existing fw versions and their capabilities, it simply queries the fw that tells what it supports.

This is indeed a good solution, which allows some modules/directives case for supported to be reported to the client。

[xianglin1998]

rather than relying on global fw version we can also have ways for the fw to report what are the available commands. As we do in https://github.com/RfidResearchGroup/proxmark3/blob/master/armsrc/appmain.c#L445-L572 So client does not have to know and maintain a map of all existing fw versions and their capabilities, it simply queries the fw that tells what it supports.

Reporting the supported commands/modules can solve the problem of the global dependency of the firmware version code when solving compatibility, so the client development now needs to focus on the description manual of the parameters returned by the command, which requires a document for description, and the command changes described in this document need to be linked to the firmware version. Assuming that I am a client developer now, when I am developing the client, I can support the api support of certain functions according to the command/module support mapping table returned by the device, instead of judging the firmware version code every time. OK, this solves the problem of a large number of version determinations that may exist in the client code. Then, one day I suddenly saw in the compatibility processing document that after the release of the new version of the device firmware, a previously existing command changed the returned parameters in order to fix a BUG. At this time, in order to be compatible with the old device firmware and the new firmware, the new client that I am about to release needs to use the version code to judge, and treat the two kinds return parameters differently.

[xianglin1998]

If the v1.1 version adds a certain command, and the v1.2 version discards it, but the v1.3 version restores it to use, but the parameters returned by the command have been changed, is the compatibility processing of the client in this way:

1. According to the command/module support mapping table reported by the device, the support for certain functions can be optionally enabled
2. Use the firmware version code to process the compatibility of the return parameters of the command.

Assuming that the above coding method is used to achieve compatibility processing, when I open this latest client, the following will happen:

1. I got some information from the device cmd with firmware version v1.1, but some information is missing (only available on device firmware version v1.3). At this time, I need to use the device version code for compatibility judgment processing.
2. I disable this feature on devices with firmware v1.2.
3. I got some information from the device cmd with firmware version v1.3. This information contains some information that is not available in version v1.1. At this time, it is also necessary to use the device version code for compatibility judgment processing.

When the addition/modification of these commands is written as a manual for compatibility processing, client developers can choose to start compatibility processing from a certain version, and the client can refuse to serve devices that are lower than a certain firmware version.

[xianglin1998]

If the return parameter of the command does not change, then the command/module support mapping table directly helps us complete the firmware version compatibility management, which is indeed a perfect solution. But considering that we may change the returned parameters, perhaps the command/module support mapping table + firmware version code is the best solution. The former lets the client know whether certain functions are available, and the latter lets the client know how certain functions should be used.

[GameTec-live]

If the return parameter of the command does not change, then the command/module support mapping table directly helps us complete the firmware version compatibility management, which is indeed a perfect solution. But considering that we may change the returned parameters, perhaps the command/module support mapping table + firmware version code is the best solution. The former lets the client know whether certain functions are available, and the latter lets the client know how certain functions should be used.

probably overengineered, but why not, in the mapping table. include the returned parameters too? then the client would only need to reference one table to know all of the capabilities of the device?

[GameTec-live]

this would also allow 3dpraty firmware to maybe work with clients that wernt built with that firmware in mind?

[xianglin1998]

this would also allow 3dpraty firmware to maybe work with clients that wernt built with that firmware in mind?

No, only ChameleonUltra RRG repo.

[xianglin1998]

If the return parameter of the command does not change, then the command/module support mapping table directly helps us complete the firmware version compatibility management, which is indeed a perfect solution. But considering that we may change the returned parameters, perhaps the command/module support mapping table + firmware version code is the best solution. The former lets the client know whether certain functions are available, and the latter lets the client know how certain functions should be used.

probably overengineered, but why not, in the mapping table. include the returned parameters too? then the client would only need to reference one table to know all of the capabilities of the device?

The return parameter or transmission parameter is one or more bytes, and the meaning of the byte cannot be described in the mapping table. For example, a command was added in the v1.1 firmware version to implement a function similar to hf 14a raw, but the -k parameter was missing to inform the device of the ability to maintain the radio frequency field, and then the v1.2 firmware version began to support it. Then, as a client developer, if we need to consider the support of the old device firmware, do we see that the device firmware supports hf 14a raw in the mapping table, and we also need to deal with parameter compatibility issues?

[GameTec-live]

this would also allow 3dpraty firmware to maybe work with clients that wernt built with that firmware in mind?

No, only ChameleonUltra RRG repo.

you cant prevent people from building their own firmware, altough i too prefer if people just improve the original firmware

[xianglin1998]

The handling of device firmware compatibility needs to take into account other projects in the open source community ecology. Of course, we only consider trying to make our device firmware can be normally supported by other clients, so as to expand this software(client etc...) ecology. This process needs to consider more possibilities in compatibility processing, rather than just considering the software support in this code repository.

[xianglin1998]

this would also allow 3dpraty firmware to maybe work with clients that wernt built with that firmware in mind?

No, only ChameleonUltra RRG repo.

you cant prevent people from building their own firmware, altough i too prefer if people just improve the original firmware

We do not prevent users from building their own device firmware. We just try to make the device firmware built from our repository well compatible with the client. Because we provide compatibility processing documents(No yet, at future), client developers know the specific usage of the commands provided by the firmware. if developer need to improve the user experience, developer need to be compatible with the old version of the device firmware to a certain extent, which will make most users choose to use his software, because there is no need to think too much.

[xianglin1998]

this would also allow 3dpraty firmware to maybe work with clients that wernt built with that firmware in mind?

I'm also opening this issue only to improve support for our device firmware version compatibility with third-party clients and clients in our own code repository. Just imagine, a user uses a certain version of firmware in this code repository to cooperate with your client, and then you are perfectly compatible with the device with the old firmware according to the compatibility document. The user does not need to think too much. If he does not want to update the firmware, he can still use the old firmware for some functions.

[doegox]

If the return parameter of the command does not change, then the command/module support mapping table directly helps us complete the firmware version compatibility management, which is indeed a perfect solution. But considering that we may change the returned parameters, perhaps the command/module support mapping table + firmware version code is the best solution. The former lets the client know whether certain functions are available, and the latter lets the client know how certain functions should be used.

If a function disappears and reappears differently, you may just consider it's a new function and give it a new name and a new code. e.g. #define DATA_CMD_SCAN_EM410X_TAG_V2 (3010)

[xianglin1998]

If the return parameter of the command does not change, then the command/module support mapping table directly helps us complete the firmware version compatibility management, which is indeed a perfect solution. But considering that we may change the returned parameters, perhaps the command/module support mapping table + firmware version code is the best solution. The former lets the client know whether certain functions are available, and the latter lets the client know how certain functions should be used.

If a function disappears and reappears differently, you may just consider it's a new function and give it a new name and a new code. e.g. #define DATA_CMD_SCAN_EM410X_TAG_V2 (3010)

Good idea, then we only have the description of the return parameters and transfer parameters for the new command left. The commands that need to be removed can be marked as deprecated in the compatibility document. In this way, the compatibility processing document only contains descriptions of these commands and is independent of the firmware version.