Can accidental change of MAC address be protected?
-
Can I stop users from changing MAC address i.e. use of M540 ?
-
@user3d only by building your own version of the firmware and disabling M540. There's no privileges built into RRF. But even then, there's nothing stopping a user from updating to a duet version of the firmware and using M540
-
@user3d When the MAC Address is set in config.g , it will be reset after boot up...
-
@user3d do you mean completely preventing a code being used; or just preventing it after config.g has been run; or just preventing it being used in print files?
-
@dc42 said in Prohibit use of a code?:
@user3d do you mean completely preventing a code being used; or just preventing it after config.g has been run; or just preventing it being used in print files?
@dc42 Complete prevention of a code
-
@jay_s_uk Got it... Thanks for the reply
-
-
@user3d Given that the Duet ecosystem, including the firmware, is an open source project, then I would have thought that it is not possible to prevent users from making certain changes. Essentially, what you would need to do is create a custom firmware which could never be updated with any other version, which then makes it closed source. It sounds like you have a version of DWC which uses that philosophy - not sure where you stand with licensing on that......
-
@deckingman Dear Ian ,
Thank you for the details. We don't plan to take away rights from the user to upgrade the software. Any upgrade in RRF will always be directed to the user.
My requirement is not to disable a feature of processing an instruction, But rather avoid accidental change of address. And looking for suggestion on that.
Also, I believe a power cycle will retain back the original address.
The point here was merely to ensure no theft, by reading a list of machines connected via DWC, ensuring boards are not tampered with. -
@user3d I still don't understand what exactly you want to stop from being stolen. Your version of DWC?
Technically, you won't easily be able to tie DWC to a specific board; if you find a solution media companies will make you rich for the DRM scheme quicker than you can make money from selling locked down 3d printers.
License wise, if that's derived from DWC proper, my layman's understanding is that you are bound to the GPL and need to provide the source code to your customers who then have the right to modify and use and redistribute it (right to modify includes removing MAC address checks or any other hardware checking scheme). Consult a lawyer versed in open source licensing if in doubt.
Maybe it's not worth trying to lock down your version of DWC, and just better for everyone if you teamed up with Chris Hamm to make DWC better for all ...
If anything, Duet3D has shown for more than 15 years now that you can make a successful hardware company selling and offering completely open source products, from hardware design to software (yes, some components aren't free, like CAN-FD, but IIRC CanOpen wasn't a thing or didn't have the required capabilities).
-
Dear @oliof @deckingman
I believe there is a grave misunderstanding here!Please be rest assured, that I have not done anything that contradicts the licensing terms. The very first question in the thread was "Can I ....?" .
I am aware of GNU license terms and have adhered to it, being an active forum user, i also solve queries possible. However, It was a requirement from a naive user who doesn't know how to code and hence the question. Intention here was just to see if user requirement can be fulfilled and nothing more!
I guess the subject was misleading and fixed hence!NOTE: my version of DWC = DWC with dark theme with some colors changed for user. no breaching of license.
I will check with Chris Hamm , if a solution can be derived to this kind of user requirement.
-
@user3d the processors used in Duet have unique IDs. You can retrieve the ID from the object model. Look under boards[0].uniqueId.
-
@dc42 Thank you!