Automated Machine Identification

[aaron97neu]

We should be able to identify the machine that the ISOBlue is on, likely with the address claiming CAN sequence at machine startup. This will decrease errors from having to manually enter what machine a given ISOBlue is on

Suggested by @aultac on 1/22/21 meeting, but has been kicked around for a while

Potential roadblocks:

• Do we start up fast enough to catch these messages? If not can we query for them?
• Can we reliably associate CAN address claiming with a human readable and unique machine name?

[facastiblancor]

I do not think ISOBlue starts fast enough to catch those messages. According to https://copperhilltech.com/blog/sae-j1939-address-claim-procedure-sae-j193981-network-management/, the address claim procedure starts after the machine's POST. For this to be successful, ISOBlue would need to be ready to log before turning on the machine, which is extremely hard (if not impossible) to determine. It might make more sense to query this data, and it is possible sending the request address claim message on the bus, but this would make ISOBlue an active listener, opening new challenges and security issues. Experience would be best to tell if these concerns are actually a big deal.

[aultac]

Well it’s worth checking if they are there now in logs at least.

I would think this is a common issue since address claim is a critical part of J1939 so any CAN interface has this issue. Is there is some way to do “wake on CAN” where the CAN interface immediately starts buffering packets until the OS is awake so that the first read is actually pulling from the buffer?

Aaron

On Jan 22, 2021, at 11:15 AM, Fabio A. Castiblanco notifications@github.com wrote:

I do not think ISOBlue starts fast enough to catch those messages. According to https://copperhilltech.com/blog/sae-j1939-address-claim-procedure-sae-j193981-network-management/ https://copperhilltech.com/blog/sae-j1939-address-claim-procedure-sae-j193981-network-management/, the address claim procedure starts after the machine's POST. For this to be successful, ISOBlue would need to be ready to log before turning on the machine, which is extremely hard (if not impossible) to determine. It might make more sense to query this data, and it is possible sending the request address claim message on the bus, but this would make ISOBlue an active listener, opening new challenges and security issues. Experience would be best to tell if these concerns are actually a big deal.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oats-center/isoblue-avena/issues/112#issuecomment-765519888, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2KEUAP6TQBREVVKGEI4VLS3GQD7ANCNFSM4WOUQIVA.

[abalmos]

There is a chance that we do see them when IB is turned on by wake-on-can. I assume the CAN hardware captures everything, its just a question of if Linux/SocketCAN pulls from that hardware before it's internal buffers are full. There is a USB in the middle, but given wake on CAN works over it, the USB systems must stay active during suspend.

We should just check. I don't know the PGN, but I think this is as simple as checking for the existence of a PGN, at least at first.

[aultac]

PGN’s for address claim are here (first search result): https://copperhilltech.com/blog/sae-j1939-address-management-messages-request-for-address-claimed-and-address-claimed/ https://copperhilltech.com/blog/sae-j1939-address-management-messages-request-for-address-claimed-and-address-claimed/

59904, 60928, 65240

The 65240 PGN is the “I successfully commanded this address” message which I think is the important one. It contains the NAME (the main thing we want) and the SA that was claimed to link the NAME with any subsequent messages on the bus.

Aaron

On Jan 22, 2021, at 11:26 AM, Andrew Balmos notifications@github.com wrote:

There is a cache that we do see them when IB is turned on by wake-on-can. I assume the CAN hardware captures everything, its just a question of if Linux/SocketCAN pulls from that hardware before it's internal buffers are full. There is a USB in the middle, but given wake on CAN works over it, the USB systems must stay active during suspend.

We should just check. I don't know the PGN, but I think this is as simple as checking for the existence of a PGN, at least at first.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oats-center/isoblue-avena/issues/112#issuecomment-765528303, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2KEUBNHPH4VM3YTVLVVILS3GRL3ANCNFSM4WOUQIVA.

[aaron97neu]

Fabio and I discussed this briefly in person yesterday

We came to the conclusion that if this data (PGN 55240?) is queryable the simpler solution would be to not worry about catching these messages in the beginning and query for them once we get around to booting up. This would also work for machines that do not have power on the isobus plug while the machine is off.

We could not find an evidence saying this is or is not possible but we are planning on experimenting with it this week with skidsteer to see if it would work.

[aultac]

You are right, it looks like “request for address claimed” to broadcast address should get you what you want. However, did anybody take just a few minutes to look and see if you have any in your logs from the past?

Aaron

On Jan 23, 2021, at 3:02 PM, Aaron Neustedter notifications@github.com wrote:

Fabio and I discussed this briefly in person yesterday

We came to the conclusion that if this data (PGN 55240?) is queryable the simpler solution would be to not worry about catching these messages in the beginning and query for them once we get around to booting up. This would also work for machines that do not have power on the isobus plug while the machine is off.

We could not find an evidence saying this is or is not possible but we are planning on experimenting with it this week with skidsteer to see if it would work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oats-center/isoblue-avena/issues/112#issuecomment-766171164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2KEUFSOIL6LKUYRDONZG3S3MTOLANCNFSM4WOUQIVA.

[aaron97neu]

@facastiblancor had checked one of the Deer combines and didn't see it. Not sure if he has gotten around to checking any other machines.

[aultac]

You are right, it looks like sending the Request for Address Claimed message to the broadcast address is supposed to get all the ECU’s to respond with their addresses. That would do it!

Aaron

On Jan 23, 2021, at 3:02 PM, Aaron Neustedter notifications@github.com wrote:

Fabio and I discussed this briefly in person yesterday

We came to the conclusion that if this data (PGN 55240?) is queryable the simpler solution would be to not worry about catching these messages in the beginning and query for them once we get around to booting up. This would also work for machines that do not have power on the isobus plug while the machine is off.

We could not find an evidence saying this is or is not possible but we are planning on experimenting with it this week with skidsteer to see if it would work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/oats-center/isoblue-avena/issues/112#issuecomment-766171164, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2KEUFSOIL6LKUYRDONZG3S3MTOLANCNFSM4WOUQIVA.