Closed lars18th closed 3 weeks ago
Hi @Jalle19 ,
Please merge it. When running with multiple SAT>IP servers in the same network you will see the trouble.
I'm not entirely sure what the problem is here? Device ID initialization from bootid file seems to work fine at least?
I'm not entirely sure what the problem is here? Device ID initialization from bootid file seems to work fine at least?
NO. With the last changes of the initialization a BIG BUG is present: The code allways starts to count from 1. Therefore the stored value and the enforced value of the parameter is never used.
This patch is necessary. Please, merge it. Thank you.
Okay, I think I get it now. This is mainly about fixing the scenario where a conflict is detected, opts.device_id
is incremented and readBootID()
is called again?
Okay, I think I get it now. This is mainly about fixing the scenario where a conflict is detected,
opts.device_id
is incremented andreadBootID()
is called again?
Not really. With the "previous" code the "initial" value is allways 1, and the paramters and bootid data is overwrited.
And thank you for merging it! 😉
Note: One edge case not considered. Fixed too in #1186.
This fix solves the problem of messages
Device ID conflict, changing our device id to...
at the start caused by an incorrect initialization. Without this fix the values from-D --device-id
parameters andbootid
file are not used.