direct address transport protocol initiated through Node.send_parameter_group() results in a broadcast transfer

[DaveP987]

When sending a directed long message through Node.send_parameter_group, the resulting transfer is always broadcast. j1939.Bus.send is always seeing a destination address of 0xFF.

I added some logging in Node.send_parameter_group immediately prior to the send:

            logger.debug('send_parameter_group: to address: %s', pdu.arbitration_id.pgn.pdu_specific)
            logger.info("DKP: send_parameter_group: is_destination_specific={}, destAddr={}".format(pdu.arbitration_id.pgn.is_destination_specific, pdu.arbitration_id.destination_address))

When sending a long message that requires the use of the transport protocol, I see the following results:

DEBUG:j1939:send_parameter_group: to address: 176                  <---- correct address
DEBUG:j1939:PGN is_pdu1 00ef: True
DEBUG:j1939:            (self.pdu_format & 0xFF) < 240 00ef: True
DEBUG:j1939:            self.reserved_flag 00ef: 0
DEBUG:j1939:            self.data_page_flag 00ef: 0
DEBUG:j1939:value-result = 00efb0
DEBUG:j1939:PGN is_destination_specific efb0: True
DEBUG:j1939:PGN is_pdu1 00ef: True
DEBUG:j1939:            (self.pdu_format & 0xFF) < 240 00ef: True
DEBUG:j1939:            self.reserved_flag 00ef: 0
DEBUG:j1939:            self.data_page_flag 00ef: 0
DEBUG:j1939:value-result = 00efb0
DEBUG:j1939:PGN is_destination_specific efb0: True
INFO:j1939:DKP: j1939.send: is_destination_specific=True, destAddr=255   <---- global address

I believe the root issue is in ArbitrationID, where destination_address_value is maintained separately from pgn.pdu_specific, allowing them to hold different values that I believe should never be different. Node.send_parameter_group sets pdu.arbitration_id.pgn.pdu_specific to the destination_address, but not pdu.arbitration_id.destination_address.

My gut feel is that ArbitrationID.destination_address_value should just be a property that defers to pgn.pdu_specific. I see the following in ArbitrationID.__init__, which kinda indicates the separation may be intentional, and the commented assert makes me think the intention was that they should always be the same (yet it's been commented out...). I'm not sure if there's more to this than I'm seeing.

                        if  self.destination_address_value != self._pgn.pdu_specific:
                                logger.debug("self._pgn=%s, self.destination_address_value = %x, pgn.pdu_specific = %x" %
                                        (self._pgn, self.destination_address_value, self._pgn.pdu_specific))
#                        assert( self.destination_address_value == pgn.pdu_specific)

My workaround is to assign the destination address to both within Node.send_parameter_group, which gets me by for now, but isn't a fix, IMO:

        pdu.arbitration_id.pgn.pdu_specific = pdu.arbitration_id.destination_address = destination_address

I'm happy to take a stab at a fix, but would need some guidance/clarification on the reason for separate address storage.

[milhead2]

Hi Dave, I am more than happy to have someone look at this and provide a PR. I don't have an answer to your question as I picked up maintenance of the library only because Brian dropped it from python-can and our testing environment at work was based on it. We use the library for most of our j1939 traffic simulation for Polaris vehicles. I can test a display or hand control and the robot framework libraries we've built on top of the python-j1939 allow us to simulate most of the rest of the ECU's on a vehicle. If you submit a PR you like, I'll take a look at it but I've not been in the code for a while. The major thing I'll test is if it breaks any of our functional test suites. I say got for it! Let me know if you have any quesitons.. Miller Lowe ***@***.***>

…

________________________________ From: Dave Paul ***@***.***> Sent: Thursday, November 10, 2022 9:54 AM To: milhead2/python-j1939 ***@***.***> Cc: Subscribed ***@***.***> Subject: [milhead2/python-j1939] direct address transport protocol initiated through Node.send_parameter_group() results in a broadcast transfer (Issue #21) *External Email* Think Before You Click. When sending a directed long message through Node.send_parameter_group, the resulting transfer is always broadcast. j1939.Bus.send is always seeing a destination address of 0xFF. I added some logging in Node.send_parameter_group immediately prior to the send: logger.debug('send_parameter_group: to address: %s', pdu.arbitration_id.pgn.pdu_specific) logger.info("DKP: send_parameter_group: is_destination_specific={}, destAddr={}".format(pdu.arbitration_id.pgn.is_destination_specific, pdu.arbitration_id.destination_address)) When sending a long message that requires the use of the transport protocol, I see the following results: DEBUG:j1939:send_parameter_group: to address: 176 <---- correct address DEBUG:j1939:PGN is_pdu1 00ef: True DEBUG:j1939: (self.pdu_format & 0xFF) < 240 00ef: True DEBUG:j1939: self.reserved_flag 00ef: 0 DEBUG:j1939: self.data_page_flag 00ef: 0 DEBUG:j1939:value-result = 00efb0 DEBUG:j1939:PGN is_destination_specific efb0: True DEBUG:j1939:PGN is_pdu1 00ef: True DEBUG:j1939: (self.pdu_format & 0xFF) < 240 00ef: True DEBUG:j1939: self.reserved_flag 00ef: 0 DEBUG:j1939: self.data_page_flag 00ef: 0 DEBUG:j1939:value-result = 00efb0 DEBUG:j1939:PGN is_destination_specific efb0: True INFO:j1939:DKP: j1939.send: is_destination_specific=True, destAddr=255 <---- global address I believe the root issue is in ArbitrationID, where destination_address_value is maintained separately from pgn.pdu_specific, allowing them to hold different values that I believe should never be different. Node.send_parameter_group sets pdu.arbitration_id.pgn.pdu_specific to the destination_address, but not pdu.arbitration_id.destination_address. My gut feel is that ArbitrationID.destination_address_value should just be a property that defers to pgn.pdu_specific. I see the following in ArbitrationID.__init__, which kinda indicates the separation may be intentional, and the commented assert makes me think the intention was that they should always be the same (yet it's been commented out...). I'm not sure if there's more to this than I'm seeing. if self.destination_address_value != self._pgn.pdu_specific: logger.debug("self._pgn=%s, self.destination_address_value = %x, pgn.pdu_specific = %x" % (self._pgn, self.destination_address_value, self._pgn.pdu_specific)) # assert( self.destination_address_value == pgn.pdu_specific) My workaround is to assign the destination address to both within Node.send_parameter_group, which gets me by for now, but isn't a fix, IMO: pdu.arbitration_id.pgn.pdu_specific = pdu.arbitration_id.destination_address = destination_address I'm happy to take a stab at a fix, but would need some guidance/clarification on the reason for separate address storage. — Reply to this email directly, view it on GitHub<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmilhead2%2Fpython-j1939%2Fissues%2F21&data=05%7C01%7Cmiller.lowe%40polaris.com%7Cc4a3de5215a64dcc36dd08dac3449b77%7C85f78c4cad11473596240b2c11611dff%7C0%7C0%7C638036996682397847%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6lIDnvg19BAtwhD2xFq%2FXyP%2BVygGwtBtT8dXe9EFcU8%3D&reserved=0>, or unsubscribe<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEWRWU3LIAYWG7HXTDUIBE3WHUZFDANCNFSM6AAAAAAR42HAFU&data=05%7C01%7Cmiller.lowe%40polaris.com%7Cc4a3de5215a64dcc36dd08dac3449b77%7C85f78c4cad11473596240b2c11611dff%7C0%7C0%7C638036996682554064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=veE4UvPyPMeUHpmrCAr%2BwCWaSVHMiGxVininZy9Y4pY%3D&reserved=0>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> CONFIDENTIAL: The information contained in this email communication is confidential information intended only for the use of the addressee. Unauthorized use, disclosure or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by return email and destroy all copies of this communication, including all attachments.

[DaveP987]

Hi Miller,

Before I pursue any adjustments, I thought I'd setup some tests to make sure the basics were working. Right off the bat, I'm not seeing address claiming work as I expected (i actually thought I might have tripped into some insight about the global destination address for long transfers, but it turns out not...).

What I'm seeing is that "address claimed" messages appear to be ignored because the transmitted PGN (0xeeff) doesn't match the defined PGN_AC_ADDRESS_CLAIMED (0xee00), causing the check for pgn in [PGN_AC_ADDRESS_CLAIMED, ...] in Bus.notification to never be true, preventing the message from getting dispatched back to Node.

I've instantiated two nodes in a test environment, each attached to its own j1939.Bus, which are each using a test implementation of can.Bus. I see PGN_AC_ADDRESS_CLAIMED get sent by each and received by the other.

I would love to believe I'm just setting this up incorrectly, but this particular scenario seems baked in -- 0xeeff is explicitly constructed and sent and then explicitly compared to 0xee00.

This would also block the build-up of the known address list, which I would think would be super apparent. Are your tests/simulations relying on any address negotiation, and are you seeing them resolve correctly?

Step #2 was to change pgn in [PGN_AC_ADDRESS_CLAIMED, ...] to (pgn.value & 0xff00) in [PGN_AC_ADDRESS_CLAIMED, ...], which got me to another issue...

I'm at the head-scratching "how could this ever work" stage.

[DaveP987]

Hi Miller,

With a few changes, I was able to get address claiming and negotiation working in a test environment, but they're definitely in the "how did this ever work?" category. I'll write up a separate issue to capture it all.

As for this issue, I'll do some experimenting and see if I can arrive at a fix.

[milhead2]

Hi Dave, As an inheritee of the whole library I ask myself that a lot... I figure everyone is a better python programmer than I as well as more j1939 savvy... But I get by. Miller

…

________________________________ From: Dave Paul ***@***.***> Sent: Friday, November 11, 2022 8:32 AM To: milhead2/python-j1939 ***@***.***> Cc: Miller Lowe ***@***.***>; Comment ***@***.***> Subject: Re: [milhead2/python-j1939] direct address transport protocol initiated through Node.send_parameter_group() results in a broadcast transfer (Issue #21) *External Email* Think Before You Click. Hi Miller, With a few changes, I was able to get address claiming and negotiation working in a test environment, but they're definitely in the "how did this ever work?" category. I'll write up a separate issue to capture it all. As for this issue, I'll do some experimenting and see if I can arrive at a fix. — Reply to this email directly, view it on GitHub<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmilhead2%2Fpython-j1939%2Fissues%2F21%23issuecomment-1311923435&data=05%7C01%7Cmiller.lowe%40polaris.com%7Ce0bb49776f85479426a408dac40243d4%7C85f78c4cad11473596240b2c11611dff%7C0%7C0%7C638037811255579199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5krclFEml2eWlRYSyczfpdfNRo6L0EQX1kvW3YM2INU%3D&reserved=0>, or unsubscribe<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEWRWUYFSCSWPIEFHAELKGDWHZYIHANCNFSM6AAAAAAR42HAFU&data=05%7C01%7Cmiller.lowe%40polaris.com%7Ce0bb49776f85479426a408dac40243d4%7C85f78c4cad11473596240b2c11611dff%7C0%7C0%7C638037811255579199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=61CjU8W%2BIxob%2Bxc%2Fk7LnVuyW43r7q2E8UDzP4%2BoGh8U%3D&reserved=0>. You are receiving this because you commented.Message ID: ***@***.***> CONFIDENTIAL: The information contained in this email communication is confidential information intended only for the use of the addressee. Unauthorized use, disclosure or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by return email and destroy all copies of this communication, including all attachments.