Add param to ignore flow control on transmit

[rbenji23]

It would be great if there was also a parameter to disable waiting for flow control when transmitting. Some devices may not support the flow control message.

[hartkopp]

Hi @rbenji23 - this feature would be a 1:n broadcast of ISO-TP PDUs without flow control, which needs local settings of the STmin value and the block size handling to be disabled.

Just for curiosity: What kind of devices do you have in mind, that are not able to provide the FC handling?

@pylessard : I remember there was already some discussion in 2019 which lead to this patch https://github.com/hartkopp/can-isotp/tree/nofc-softhrt but this is pretty outdated now.

I started a new attempt based on the latest Linux mainline code and isotpsend - see here: https://github.com/hartkopp/can-utils/commit/83604a92d976ef849aae8ab5b1dd903909464204

[rbenji23]

HI @hartkopp , thanks for looking at this! The devices use a legacy custom bootloader implementation that have custom flow control messages around the ISOTP block that also specifies the flash page. It was developed without support for the ISOTP flow control message. I did find a work around using the kvaser interface and recieve_own_messages param in the meantime. This would probably not work for all interfaces.

bus = KvaserBus(channel=0, bitrate=250000, accept_virtual = True, receive_own_messages = True) #recv_own_msgs allows dummy msg below to work
nodes = isotp.Address(isotp.AddressingMode.Normal_29bits, rxid=PDU1_ID(5,PGN,TX_NODE,RX_NODE), txid=PDU1_ID(5,PGN,RX_NODE,TX_NODE))
params = {
        'stmin' : 1,
        'blocksize' : 0,
        'tx_data_length' : 8,
        'tx_data_min_length' : 8,
        'squash_stmin_requirement' : False,
        'rx_flowcontrol_timeout'  : 1000,
        'rx_consecutive_frame_timeout' : 1000,
        'tx_padding' : 0xFF,
        'wftmax' : 0,
        'listen_mode' : True
}
stack = isotp.CanStack(bus, address=nodes, error_handler=my_error_handler,  params = params)
#Custom flow control to specify flash page
stack.send(pagedata)
stack.process() # send first frame
bus.send(can.Message(arbitration_id=PDU1_ID(5,PGN,TX_NODE,RX_NODE), data = [0x30,0x00,0x01,0x00], is_extended_id=True)) #Dummy msg to continue w/o flow control with 1ms spacing
while stack.transmitting():
   stack.process()
   time.sleep(stack.sleep_time())
#Custom flow control to signal end of flash page transmission

[hartkopp]

The devices use a legacy custom bootloader implementation that have custom flow control messages around the ISOTP block that also specifies the flash page.

Ah, interesting!

It was developed without support for the ISOTP flow control message.

When the settings of STmin and BS are clear anyway AND the availability of the receiving node is obviously ensured by another mechanism - why not ;-)

I did find a work around using the kvaser interface and recieve_own_messages param in the meantime.

Ah, just faking a FC reception ;-)

This would probably not work for all interfaces.

Yes. With Linux it would be pretty simple to generate a FC when a FF is sent (e.g. with cangw even without writing some own code). But this is not portable to Windows machines as-is.

[hartkopp]

Finally the idea of @rbenji23 has been implemented and will likely show up in Linux 5.19:

https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/commit/?h=testing&id=3cb50e60020fd4521ca7fe80257a734035f451eb

To test this feature and to work with this unconfirmed ISOTP transmission a new flag CAN_ISOTP_CF_BROADCAST has been introduced which is implemented in isotpsend too: https://github.com/linux-can/can-utils/commit/6e7f845a6886d69e14b6fb3796673dd1efd217e0

[pylessard]

I forgot about this request :s Will have a look eventually. Probably early June as I will have a full week of vacation.

Regards

[RichardLangFromNZ]

Finally the idea of @rbenji23 has been implemented and will likely show up in Linux 5.19:

https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/commit/?h=testing&id=3cb50e60020fd4521ca7fe80257a734035f451eb

@hartkopp would you be able to port this enhancement into your out-of-tree repo at https://github.com/hartkopp/can-isotp, it seems to be missing...

thx, Richard

[hartkopp]

Hi @RichardLangFromNZ , I have been thinking about that too. But due to the backwards compatibility with the hrtimer trampoline this likely will turn into a mess. That's why I only try to backport security and sanity patches - and sometimes features, when it is feasible.

Are you depending on that feature? What Linux kernel version are you using? (maybe there's a better way to meet your requirements)

Best, Oliver

[RichardLangFromNZ]

Thanks for your prompt response Oliver,
I'm working with an in-house proprietary protocol stack that uses ISO-TP without any flow control (we're working with messages that are generally pretty small so figured we could get away without it). We have C/C++ implementations working satisfactorily already, and was now looking at python support for debugging, engineering tools etc. With the recently merged python-can-isotp "listen mode with no flow control" (PR #59) and this work in progress, it looked to me that all the required parts were almost there.

Not having this available doesn't leave me stuck, I can implement what I need in application level python on top of stock socketCAN functionality without too much trouble, I was just having a look to see whether someone else might have already done it for me (I'd sorta assumed that https://github.com/hartkopp/can-isotp would be the master copy with the most comprehensive and up-to-date feature set)

regards, Richard

[hartkopp]

I'd sorta assumed that https://github.com/hartkopp/can-isotp would be the master copy with the most comprehensive and up-to-date feature set

No. The latest and greatest Linux kernel ISO-TP implementation can be found in the Linux kernel itself.

The https://github.com/hartkopp/can-isotp repository was the original out-of-tree development repo - and it is meant to make ISO-TP work in Linux kernels prior v5.10 (when isotp was merged into mainline Linux).

That's why I asked for your specific Linux version you use in your setup? It probably makes more sense to do some backporting of the mainline implementation than using the out-of-tree implementation as a starting point for your setup ...

[RichardLangFromNZ]

I'm running Mint 20.3 and colleagues who will want to use this work are generally running ubuntu 20.04. A download, build and install of your out-of-tree repo. would be reasonable, but I really think it's less trouble for all involved that I just write the bits I need in application level python than stuffing a custom kernel install down everyone's throat.

[hartkopp]

Hm, AFAIK both Mint 20.3 and Ubuntu 20.4 use Linux 5.4.

And Linux 5.4 has the infrastructure for HRTIMER_MODE_SOFT which is base requirement for the latest mainline code (with the latest features).

So it shouldn't be a big deal to create a branch in my can-isotp repo to build the out-of-tree isotp implementation for Linux 5.4+ with the 'latest' mainline features.

If you are interested in such a solution (to maintain your current process) I could set this up for you.

[hartkopp]

Done!

https://github.com/hartkopp/can-isotp/tree/mainline-5.4+

This branch is intended to build the latest mainline isotp code out-of-tree down to Linux 5.4

Please give it a try.

[RichardLangFromNZ]

Awesome Oliver, I'll give it a test drive over the weekend and let you know how it goes

many thanks, Richard

[pylessard]

Just to let you know that the pure python TransportLayer object now supports listen_mode which never sends flow controls. Will be available with v2.x release.