Ok, thank you for response !
I wasn't at the latest version. And after updating the kernel, this
problem disappeared.
Sorry for the inconvenience.
Best regards.
--
Arthur Guyader - Embedded Engineer - IoT.bzh
On 16/07/2019 09:38, Kurt Van Dijck wrote:
On di, 16 jul 2019 09:05:18 +0200, Kurt Van Dijck wrote:
On di, 16 jul 2019 06:36:35 +0200, Oleksij Rempel wrote:
Hi Arthur,
On 15.07.19 16:15, Arthur Guyader wrote:
Hello,
I encountered a problem when using the claiming address.
When an ECU1 with a low name requests an address, it is saved in the kernel cache.
If this ECU1 is cut, and we launch our ECU2 which will ask for the same address.
He will have no answer from ECU1 and has no trace of him in his cache, so
he can consider that the address is free.
However, the kernel will consider that the address is busy and generate an
error when sending a message. (99 : cannot assign requested address)
How would you handle this situation?
AFAIK, J1939 does not describe a timeout on claimed addresses, so
technically, ECU1 is never really away.
The code will respect the j1939 spec, and will never timeout either on
that.
Reading back my own reply, and trying to fix jacd.c, I realize that it
is allow to contest an address, and if the remote didn't respond within
time, you're the owner.
jacd is written like that, so I assume the kernel code is blocking so
to avoid unnecessary address claim congestion.
It's not nice to put a 'recently seen' notion in kernel to decide if an
address claim will problably fail or not, so that justifies to remove
the check completely, but it's not nice to
allow stupid contests either.
I'm undecided wether to add the 'recently seen' or not.
The problems you experience would in any case dissapear.
Kurt
