Re: CAN ISO-TP

Re: CAN ISO-TP

[Oliver Hartkopp]

+CC Linux CAN ML

Hi Bartosz,

On 06.05.21 19:28, Bartosz Zdanowicz wrote:

> I'm not sure if you prefer e-mail message, but I don't want to raise 
> GitHub Issue yet.
> 

Raising a GitHub issue is generally a good idea as it may help other 
people too.

But asking on the Linux CAN mailing list is even better ;-)

> I'm using module that you are an author and it's working perfectly on my 
> local PC. I'm using Ubuntu with Kernel version 5.4.0-70-generic

Which branch did you use? master branch?

> I tried to simplify example where I use python wrappers and other things 
> and manage to get minimal example:
> 
> /import socket as s
> socket = s.socket(s.AF_CAN, s.SOCK_DGRAM, s.CAN_ISOTP)
> socket.bind(("vcan0", 1, 2))
> socket.send(b"AAAAAAAAA")
> socket.send(b"AAAAAAAAA")/
> /
> /
> It's working perfectly, even if I don't open receiver socket. It just 
> timeout and there is no issue.

But this should raise an issue as you send 9 bytes which would need 
segmentation.

This should only work with CAN FD frames with a single frame.

Can you create a candump log from vcan0 to see, what's going on the bus?

> I tried to run my application on RPI, when module is already included 
> with kernel version Linux raspberrypi 5.10.17-v7+ #1403 SMP Mon Feb 22 
> 11:29:51 GMT 2021 armv7l GNU/Linux.
> 
> I run above code and first send is working (no receiver as well), 
> timeout, but second one is printing
> 
> OSError: [Errno 70] Communication error on send

That's interesting! We are currently working on creating that kind of 
feedback.

https://lore.kernel.org/linux-can/97e2ddd5-cc8b-9c7b-6198-2eceee39dfd4@hartkopp.net/

So how is Python getting this information?

Regards,
Oliver

> 
> And pattern is repeated. So sending next data works and after those 
> error appears. It seems like sending new data somehow ,,validate" 
> previous send. When I create other socket that reads data it's working 
> perfectly. The issue is, somehow in our architecture other device might 
> be unavailable.
> 
> I checked also dmesg and there is no tips. Is it any known issue, or 
> maybe it's expected?
> 
> Thanks in advance for you reply.
> 
> Best Regards,
> Bartosz Zdanowicz

Re: CAN ISO-TP

[Patrick Menschel]

Am 06.05.21 um 20:01 schrieb Oliver Hartkopp:
>> I tried to simplify example where I use python wrappers and other
>> things and manage to get minimal example:
>>
>> /import socket as s
>> socket = s.socket(s.AF_CAN, s.SOCK_DGRAM, s.CAN_ISOTP)
>> socket.bind(("vcan0", 1, 2))
>> socket.send(b"AAAAAAAAA")
>> socket.send(b"AAAAAAAAA")/
>> /
>> /
>> It's working perfectly, even if I don't open receiver socket. It just
>> timeout and there is no issue.
> 
> But this should raise an issue as you send 9 bytes which would need
> segmentation.
> 
> This should only work with CAN FD frames with a single frame.
> 
> Can you create a candump log from vcan0 to see, what's going on the bus?
> 
>> I tried to run my application on RPI, when module is already included
>> with kernel version Linux raspberrypi 5.10.17-v7+ #1403 SMP Mon Feb 22
>> 11:29:51 GMT 2021 armv7l GNU/Linux.
>>
>> I run above code and first send is working (no receiver as well),
>> timeout, but second one is printing
>>
>> OSError: [Errno 70] Communication error on send
> 
> That's interesting! We are currently working on creating that kind of
> feedback.
> 
> https://lore.kernel.org/linux-can/97e2ddd5-cc8b-9c7b-6198-2eceee39dfd4@hartkopp.net/
> 
> 
> So how is Python getting this information?
> 
> Regards,
> Oliver

Hi,

that seems to be my topic.

1. Feel free to use my python module.

https://gitlab.com/Menschel/socketcan#using-a-canisotpsocket

It is in regular pypi and I push new releases from time to time.

pip install socketcan

Don't forget to increase txqueuelen.
https://gitlab.com/Menschel/socketcan#can-isotp-overflows-when-the-tx-queue-is-too-small

2. Concerning errors, they are returned through the socket to user space
and raise OSError by Errno in socket.Socket() class.
If a subclass is implemented for that Errno, that subclass is raised
instead, for example TimeoutError.

The reported scenario may be a delayed stderr message, means it happens
on first attempt and is printed on second attempt.
There are such things when using "python -i".

There is an easy way to verify such a thing. Wrap your socket.send()
statements into a print() statement this will print the number of bytes
sent and these numbers will be printed after the error message.

Regards,
Patrick

Re: CAN ISO-TP

[Bartosz Zdanowicz]

czw., 6 maj 2021 o 20:01 Oliver Hartkopp <socketcan@hartkopp.net> napisał(a):
>
> +CC Linux CAN ML
>
> Hi Bartosz,
>
> On 06.05.21 19:28, Bartosz Zdanowicz wrote:
>
> > I'm not sure if you prefer e-mail message, but I don't want to raise
> > GitHub Issue yet.
> >
>
> Raising a GitHub issue is generally a good idea as it may help other
> people too.
>
> But asking on the Linux CAN mailing list is even better ;-)
>
Sure, thanks! :)
>
> > I'm using module that you are an author and it's working perfectly on my
> > local PC. I'm using Ubuntu with Kernel version 5.4.0-70-generic
>
> Which branch did you use? master branch?
>
I'm using a master branch on my local PC. I was not able to find which
version of the codebase specific kernel of RaspberryPI is using.
>
> > I tried to simplify example where I use python wrappers and other things
> > and manage to get minimal example:
> >
> > /import socket as s
> > socket = s.socket(s.AF_CAN, s.SOCK_DGRAM, s.CAN_ISOTP)
> > socket.bind(("vcan0", 1, 2))
> > socket.send(b"AAAAAAAAA")
> > socket.send(b"AAAAAAAAA")/
> > /
> > /
> > It's working perfectly, even if I don't open receiver socket. It just
> > timeout and there is no issue.
>
> But this should raise an issue as you send 9 bytes which would need
> segmentation.
>
> This should only work with CAN FD frames with a single frame.
>
So when no receiver socket is opened, it should already raise an
exception after sending more than 8 bytes? I'm using standard CAN
frames (it's virtual can locally but 8 bytes per frame)
>
> Can you create a candump log from vcan0 to see, what's going on the bus?
>
On RPI after first send I got
pi@raspberrypi:~ $ candump can0
  can0  002   [8]  10 09 41 41 41 41 41 41

After the second message I got mentioned OSError and there is no data
on candump. Sending again I received next frame:
pi@raspberrypi:~ $ candump can0
  can0  002   [8]  10 09 41 41 41 41 41 41
  can0  002   [8]  10 09 41 41 41 41 41 41

On my local PC where I get no system Error I got one frame per every send:
 bartosz  ~/Work/DeltaThermal/can-isotp   master  candump vcan0
  vcan0  002   [8]  10 09 41 41 41 41 41 41
  vcan0  002   [8]  10 09 41 41 41 41 41 41
  vcan0  002   [8]  10 09 41 41 41 41 41 41
  vcan0  002   [8]  10 09 41 41 41 41 41 41
  vcan0  002   [8]  10 09 41 41 41 41 41 41
  vcan0  002   [8]  10 09 41 41 41 41 41 41
>
> > I tried to run my application on RPI, when module is already included
> > with kernel version Linux raspberrypi 5.10.17-v7+ #1403 SMP Mon Feb 22
> > 11:29:51 GMT 2021 armv7l GNU/Linux.
> >
> > I run above code and first send is working (no receiver as well),
> > timeout, but second one is printing
> >
> > OSError: [Errno 70] Communication error on send
>
> That's interesting! We are currently working on creating that kind of
> feedback.
>
> https://lore.kernel.org/linux-can/97e2ddd5-cc8b-9c7b-6198-2eceee39dfd4@hartkopp.net/
>
> So how is Python getting this information?
>
In general, that's the biggest issue for me. Because in my real
application I'm using python select() and recv() on that socket. When
this error is raised, my select() on socket deduce something is
received and recv() function also throws an error. I just tried to get
a minimal example that reproduces the issue which is above. In those
cases I would expect timeout, not OSError.
>
> Regards,
> Oliver
>
> >
> > And pattern is repeated. So sending next data works and after those
> > error appears. It seems like sending new data somehow ,,validate"
> > previous send. When I create other socket that reads data it's working
> > perfectly. The issue is, somehow in our architecture other device might
> > be unavailable.
> >
> > I checked also dmesg and there is no tips. Is it any known issue, or
> > maybe it's expected?
> >
> > Thanks in advance for you reply.
> >
> > Best Regards,
> > Bartosz Zdanowicz

Re: CAN ISO-TP

[Patrick Menschel]

Am 06.05.21 um 23:28 schrieb Bartosz Zdanowicz:
>> Can you create a candump log from vcan0 to see, what's going on the bus?
>>
> On RPI after first send I got
> pi@raspberrypi:~ $ candump can0
>   can0  002   [8]  10 09 41 41 41 41 41 41
> 
> After the second message I got mentioned OSError and there is no data
> on candump. Sending again I received next frame:
> pi@raspberrypi:~ $ candump can0
>   can0  002   [8]  10 09 41 41 41 41 41 41
>   can0  002   [8]  10 09 41 41 41 41 41 41
> 
> On my local PC where I get no system Error I got one frame per every send:
>  bartosz  ~/Work/DeltaThermal/can-isotp   master  candump vcan0
>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>>
>> ...
>> So how is Python getting this information?
>>
> In general, that's the biggest issue for me. Because in my real
> application I'm using python select() and recv() on that socket. When
> this error is raised, my select() on socket deduce something is
> received and recv() function also throws an error. I just tried to get
> a minimal example that reproduces the issue which is above. In those
> cases I would expect timeout, not OSError.


As expected, timeout error on missing flow control. Since it's tx side
it just tells -ECOMM instead of -ETIMEDOUT .

https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L10
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L755

Is there a specific reason why you use select.select() instead of
Socket.recv(timeout) / Socket.send() ?

Best Regards,
Patrick

Re: CAN ISO-TP

[Bartosz Zdanowicz]

pt., 7 maj 2021 o 09:02 Patrick Menschel <menschel.p@posteo.de> napisał(a):
>
> Am 06.05.21 um 23:28 schrieb Bartosz Zdanowicz:
> >> Can you create a candump log from vcan0 to see, what's going on the bus?
> >>
> > On RPI after first send I got
> > pi@raspberrypi:~ $ candump can0
> >   can0  002   [8]  10 09 41 41 41 41 41 41
> >
> > After the second message I got mentioned OSError and there is no data
> > on candump. Sending again I received next frame:
> > pi@raspberrypi:~ $ candump can0
> >   can0  002   [8]  10 09 41 41 41 41 41 41
> >   can0  002   [8]  10 09 41 41 41 41 41 41
> >
> > On my local PC where I get no system Error I got one frame per every send:
> >  bartosz  ~/Work/DeltaThermal/can-isotp   master  candump vcan0
> >   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >>
> >> ...
> >> So how is Python getting this information?
> >>
> > In general, that's the biggest issue for me. Because in my real
> > application I'm using python select() and recv() on that socket. When
> > this error is raised, my select() on socket deduce something is
> > received and recv() function also throws an error. I just tried to get
> > a minimal example that reproduces the issue which is above. In those
> > cases I would expect timeout, not OSError.
>
>
> As expected, timeout error on missing flow control. Since it's tx side
> it just tells -ECOMM instead of -ETIMEDOUT .
>
> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L10
> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L755
>
> Is there a specific reason why you use select.select() instead of
> Socket.recv(timeout) / Socket.send() ?
>
> Best Regards,
> Patrick

I have a seperate thread that waits and process data, since I have
multiple sockets opened I want to wait for any of them:

while True:
    ready_sockets = select.select(self.sockets, [], [], self.timeout)[0]
        if not ready_sockets:
        logging.info("No data received")
        continue
    for socket in ready_sockets:
        self.process_data(socket=socket)

In process_data I call:

received = socket.recv()
    if received:
    #process data

My main thread is sending data on those sockets:
schedule.every(X).seconds.do(request_that_sends_using_socket.send(),
socket=socket)

So the flow is that my thread sends data to another device, and the
processing thread is waiting for data. When I don't send any data I
get only prints "No data received" which is expected cause no device
is responding (no device is running). When I send data (no other
device is running) I get an error on send AND my select() is finished
with an error socket inserted to ready_sockets. That means I enter
self.process_data() function with socket and also recv() fails. So it
seems it's not only that OSError is raised but also that socket is
somehow "invalid" because it triggers select() which should not be
triggered (no data was received).

I hope I described it clearly, if any more details are needed I'll try
to provide.

Best Regards,
Bartosz Zdanowicz

Re: CAN ISO-TP

[Patrick Menschel]

Am 07.05.21 um 09:24 schrieb Bartosz Zdanowicz:
> pt., 7 maj 2021 o 09:02 Patrick Menschel <menschel.p@posteo.de> napisał(a):
>>
>> Am 06.05.21 um 23:28 schrieb Bartosz Zdanowicz:
>>>> Can you create a candump log from vcan0 to see, what's going on the bus?
>>>>
>>> On RPI after first send I got
>>> pi@raspberrypi:~ $ candump can0
>>>   can0  002   [8]  10 09 41 41 41 41 41 41
>>>
>>> After the second message I got mentioned OSError and there is no data
>>> on candump. Sending again I received next frame:
>>> pi@raspberrypi:~ $ candump can0
>>>   can0  002   [8]  10 09 41 41 41 41 41 41
>>>   can0  002   [8]  10 09 41 41 41 41 41 41
>>>
>>> On my local PC where I get no system Error I got one frame per every send:
>>>  bartosz  ~/Work/DeltaThermal/can-isotp   master  candump vcan0
>>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
>>>>
>>>> ...
>>>> So how is Python getting this information?
>>>>
>>> In general, that's the biggest issue for me. Because in my real
>>> application I'm using python select() and recv() on that socket. When
>>> this error is raised, my select() on socket deduce something is
>>> received and recv() function also throws an error. I just tried to get
>>> a minimal example that reproduces the issue which is above. In those
>>> cases I would expect timeout, not OSError.
>>
>>
>> As expected, timeout error on missing flow control. Since it's tx side
>> it just tells -ECOMM instead of -ETIMEDOUT .
>>
>> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L10
>> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L755
>>
>> Is there a specific reason why you use select.select() instead of
>> Socket.recv(timeout) / Socket.send() ?
>>
>> Best Regards,
>> Patrick
> 
> I have a seperate thread that waits and process data, since I have
> multiple sockets opened I want to wait for any of them:
> 
> while True:
>     ready_sockets = select.select(self.sockets, [], [], self.timeout)[0]
>         if not ready_sockets:
>         logging.info("No data received")
>         continue
>     for socket in ready_sockets:
>         self.process_data(socket=socket)
> 
> In process_data I call:
> 
> received = socket.recv()
>     if received:
>     #process data
> 
> My main thread is sending data on those sockets:
> schedule.every(X).seconds.do(request_that_sends_using_socket.send(),
> socket=socket)
> 
> So the flow is that my thread sends data to another device, and the
> processing thread is waiting for data. When I don't send any data I
> get only prints "No data received" which is expected cause no device
> is responding (no device is running). When I send data (no other
> device is running) I get an error on send AND my select() is finished
> with an error socket inserted to ready_sockets. That means I enter
> self.process_data() function with socket and also recv() fails. So it
> seems it's not only that OSError is raised but also that socket is
> somehow "invalid" because it triggers select() which should not be
> triggered (no data was received).


Ok,

try to enable CAN_ISOTP_WAIT_TX_DONE via socket.setsockopt() .
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L14

https://gitlab.com/Menschel/socketcan/-/blob/master/socketcan/socketcan.py#L583

and wrap tx into a try-except block.

try:
    self.process_data(socket=socket)
except OSError as e:
    print(e)

With this you actually have a chance to do error handling on tx path
instead of hitting an already present error of the previous op.

Regards,
Patrick

Re: CAN ISO-TP

[Bartosz Zdanowicz]

I used following code:

import isotp
import time
s = isotp.socket()
s._socket.settimeout(2)
s.set_opts(s.flags.WAIT_TX_DONE)
s.bind("can0", isotp.Address(rxid=1, txid=2))

s.send(b"aaaaaaaaa") -> returns immediately with number of bytes
s.send(b"aaaaaaaaa") -> same OS error as above (Error 70)

pt., 7 maj 2021 o 09:59 Patrick Menschel <menschel.p@posteo.de> napisał(a):
>
> Am 07.05.21 um 09:24 schrieb Bartosz Zdanowicz:
> > pt., 7 maj 2021 o 09:02 Patrick Menschel <menschel.p@posteo.de> napisał(a):
> >>
> >> Am 06.05.21 um 23:28 schrieb Bartosz Zdanowicz:
> >>>> Can you create a candump log from vcan0 to see, what's going on the bus?
> >>>>
> >>> On RPI after first send I got
> >>> pi@raspberrypi:~ $ candump can0
> >>>   can0  002   [8]  10 09 41 41 41 41 41 41
> >>>
> >>> After the second message I got mentioned OSError and there is no data
> >>> on candump. Sending again I received next frame:
> >>> pi@raspberrypi:~ $ candump can0
> >>>   can0  002   [8]  10 09 41 41 41 41 41 41
> >>>   can0  002   [8]  10 09 41 41 41 41 41 41
> >>>
> >>> On my local PC where I get no system Error I got one frame per every send:
> >>>  bartosz  ~/Work/DeltaThermal/can-isotp   master  candump vcan0
> >>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >>>   vcan0  002   [8]  10 09 41 41 41 41 41 41
> >>>>
> >>>> ...
> >>>> So how is Python getting this information?
> >>>>
> >>> In general, that's the biggest issue for me. Because in my real
> >>> application I'm using python select() and recv() on that socket. When
> >>> this error is raised, my select() on socket deduce something is
> >>> received and recv() function also throws an error. I just tried to get
> >>> a minimal example that reproduces the issue which is above. In those
> >>> cases I would expect timeout, not OSError.
> >>
> >>
> >> As expected, timeout error on missing flow control. Since it's tx side
> >> it just tells -ECOMM instead of -ETIMEDOUT .
> >>
> >> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L10
> >> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L755
> >>
> >> Is there a specific reason why you use select.select() instead of
> >> Socket.recv(timeout) / Socket.send() ?
> >>
> >> Best Regards,
> >> Patrick
> >
> > I have a seperate thread that waits and process data, since I have
> > multiple sockets opened I want to wait for any of them:
> >
> > while True:
> >     ready_sockets = select.select(self.sockets, [], [], self.timeout)[0]
> >         if not ready_sockets:
> >         logging.info("No data received")
> >         continue
> >     for socket in ready_sockets:
> >         self.process_data(socket=socket)
> >
> > In process_data I call:
> >
> > received = socket.recv()
> >     if received:
> >     #process data
> >
> > My main thread is sending data on those sockets:
> > schedule.every(X).seconds.do(request_that_sends_using_socket.send(),
> > socket=socket)
> >
> > So the flow is that my thread sends data to another device, and the
> > processing thread is waiting for data. When I don't send any data I
> > get only prints "No data received" which is expected cause no device
> > is responding (no device is running). When I send data (no other
> > device is running) I get an error on send AND my select() is finished
> > with an error socket inserted to ready_sockets. That means I enter
> > self.process_data() function with socket and also recv() fails. So it
> > seems it's not only that OSError is raised but also that socket is
> > somehow "invalid" because it triggers select() which should not be
> > triggered (no data was received).
>
>
> Ok,
>
> try to enable CAN_ISOTP_WAIT_TX_DONE via socket.setsockopt() .
> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L14
>
> https://gitlab.com/Menschel/socketcan/-/blob/master/socketcan/socketcan.py#L583
>
> and wrap tx into a try-except block.
>
> try:
>     self.process_data(socket=socket)
> except OSError as e:
>     print(e)
>
> With this you actually have a chance to do error handling on tx path
> instead of hitting an already present error of the previous op.
>
> Regards,
> Patrick
>

Re: CAN ISO-TP

[Patrick Menschel]

Am 10.05.21 um 12:02 schrieb Bartosz Zdanowicz:
> pt., 7 maj 2021 o 09:59 Patrick Menschel <menschel.p@posteo.de> napisał(a):
>> try to enable CAN_ISOTP_WAIT_TX_DONE via socket.setsockopt() .
>> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L14
>>
>> https://gitlab.com/Menschel/socketcan/-/blob/master/socketcan/socketcan.py#L583
>>
>> and wrap tx into a try-except block.
>>
>> try:
>>     self.process_data(socket=socket)
>> except OSError as e:
>>     print(e)
>>
>> With this you actually have a chance to do error handling on tx path
>> instead of hitting an already present error of the previous op.
>>
> I used following code:
> 
> import isotp
> import time
> s = isotp.socket()
> s._socket.settimeout(2)
> s.set_opts(s.flags.WAIT_TX_DONE)
> s.bind("can0", isotp.Address(rxid=1, txid=2))
> 
> s.send(b"aaaaaaaaa") -> returns immediately with number of bytes
> s.send(b"aaaaaaaaa") -> same OS error as above (Error 70)
> 

OK,

this is really strange. I have no clue how that is possible unless it's
on kernel side.

I have to write a test for it later.

Regards,
Patrick

Re: CAN ISO-TP

[Patrick Menschel]

Am 10.05.21 um 20:04 schrieb Patrick Menschel:
> Am 10.05.21 um 12:02 schrieb Bartosz Zdanowicz:
>> pt., 7 maj 2021 o 09:59 Patrick Menschel <menschel.p@posteo.de> napisał(a):
>>> try to enable CAN_ISOTP_WAIT_TX_DONE via socket.setsockopt() .
>>> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L14
>>>
>>> https://gitlab.com/Menschel/socketcan/-/blob/master/socketcan/socketcan.py#L583
>>>
>>> and wrap tx into a try-except block.
>>>
>>> try:
>>>     self.process_data(socket=socket)
>>> except OSError as e:
>>>     print(e)
>>>
>>> With this you actually have a chance to do error handling on tx path
>>> instead of hitting an already present error of the previous op.
>>>
>> I used following code:
>>
>> import isotp
>> import time
>> s = isotp.socket()
>> s._socket.settimeout(2)
>> s.set_opts(s.flags.WAIT_TX_DONE)
>> s.bind("can0", isotp.Address(rxid=1, txid=2))
>>
>> s.send(b"aaaaaaaaa") -> returns immediately with number of bytes
>> s.send(b"aaaaaaaaa") -> same OS error as above (Error 70)
>>
> 
> OK,
> 
> this is really strange. I have no clue how that is possible unless it's
> on kernel side.
> 
> I have to write a test for it later.

I can confirm this behaviour, it is definetly kernel-side of the socket.

tests/test_socketcan.py::TestCanIsoTpSocket::test_should_fail_missing_flow_control_on_transfer

--------------------------------------------------------------------------------------------------
live log call
--------------------------------------------------------------------------------------------------
2021-05-11 18:14:00 [    INFO] Return value of IsoTpSend without flow
control: 64 (test_socketcan.py:720)
2021-05-11 18:14:01 [   ERROR] Return value of IsoTpSend without flow
control: None, Raised [Errno 70] Communication error on send
(test_socketcan.py:718)

Apparently there is another message thread for this and something was fixed.

https://marc.info/?i=97e2ddd5-cc8b-9c7b-6198-2eceee39dfd4%20()%20hartkopp%20!%20net

Funny thing is, it does not care about the wait_tx_done flag, this
happens with and without it.

Regards,
Patrick

Re: CAN ISO-TP

[Oliver Hartkopp]

On 11.05.21 18:37, Patrick Menschel wrote:
> Am 10.05.21 um 20:04 schrieb Patrick Menschel:
>> Am 10.05.21 um 12:02 schrieb Bartosz Zdanowicz:
>>> pt., 7 maj 2021 o 09:59 Patrick Menschel <menschel.p@posteo.de> napisał(a):
>>>> try to enable CAN_ISOTP_WAIT_TX_DONE via socket.setsockopt() .
>>>> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L14
>>>>
>>>> https://gitlab.com/Menschel/socketcan/-/blob/master/socketcan/socketcan.py#L583
>>>>
>>>> and wrap tx into a try-except block.
>>>>
>>>> try:
>>>>      self.process_data(socket=socket)
>>>> except OSError as e:
>>>>      print(e)
>>>>
>>>> With this you actually have a chance to do error handling on tx path
>>>> instead of hitting an already present error of the previous op.
>>>>
>>> I used following code:
>>>
>>> import isotp
>>> import time
>>> s = isotp.socket()
>>> s._socket.settimeout(2)
>>> s.set_opts(s.flags.WAIT_TX_DONE)
>>> s.bind("can0", isotp.Address(rxid=1, txid=2))
>>>
>>> s.send(b"aaaaaaaaa") -> returns immediately with number of bytes
>>> s.send(b"aaaaaaaaa") -> same OS error as above (Error 70)
>>>
>>
>> OK,
>>
>> this is really strange. I have no clue how that is possible unless it's
>> on kernel side.
>>
>> I have to write a test for it later.
> 
> I can confirm this behaviour, it is definetly kernel-side of the socket.
> 
> tests/test_socketcan.py::TestCanIsoTpSocket::test_should_fail_missing_flow_control_on_transfer
> 
> --------------------------------------------------------------------------------------------------
> live log call
> --------------------------------------------------------------------------------------------------
> 2021-05-11 18:14:00 [    INFO] Return value of IsoTpSend without flow
> control: 64 (test_socketcan.py:720)
> 2021-05-11 18:14:01 [   ERROR] Return value of IsoTpSend without flow
> control: None, Raised [Errno 70] Communication error on send
> (test_socketcan.py:718)
> 
> Apparently there is another message thread for this and something was fixed.
> 
> https://marc.info/?i=97e2ddd5-cc8b-9c7b-6198-2eceee39dfd4%20()%20hartkopp%20!%20net
> 
> Funny thing is, it does not care about the wait_tx_done flag, this
> happens with and without it.

The error handling was originally intended to be done by simple timeout 
monitoring on application level.

What I assume from the output above:

1st attempt: We have a failure but we happily return that we have send 
64 bytes (which Marc improved with the above referenced patch for 
CAN_ISOTP_WAIT_TX_DONE mode).

(socket remains open?!?)

2nd attempt: The error from the first attempt shows up in the socket 
error message queue?!?

I just did some tests with a modified isotpsend.c which closes the 
socket after the sending operation. This is probably the reason I did 
not see that behaviour ...

Regards,
Oliver

Re: CAN ISO-TP

[Patrick Menschel]

Am 11.05.21 um 19:44 schrieb Oliver Hartkopp:
> On 11.05.21 18:37, Patrick Menschel wrote:
>> Am 10.05.21 um 20:04 schrieb Patrick Menschel:
>>> Am 10.05.21 um 12:02 schrieb Bartosz Zdanowicz:
>>>> pt., 7 maj 2021 o 09:59 Patrick Menschel <menschel.p@posteo.de>
>>>> napisał(a):
>>>>> try to enable CAN_ISOTP_WAIT_TX_DONE via socket.setsockopt() .
>>>>> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L14
>>>>>
>>>>>
>>>>> https://gitlab.com/Menschel/socketcan/-/blob/master/socketcan/socketcan.py#L583
>>>>>
>>>>>
>>>>> and wrap tx into a try-except block.
>>>>>
>>>>> try:
>>>>>      self.process_data(socket=socket)
>>>>> except OSError as e:
>>>>>      print(e)
>>>>>
>>>>> With this you actually have a chance to do error handling on tx path
>>>>> instead of hitting an already present error of the previous op.
>>>>>
>>>> I used following code:
>>>>
>>>> import isotp
>>>> import time
>>>> s = isotp.socket()
>>>> s._socket.settimeout(2)
>>>> s.set_opts(s.flags.WAIT_TX_DONE)
>>>> s.bind("can0", isotp.Address(rxid=1, txid=2))
>>>>
>>>> s.send(b"aaaaaaaaa") -> returns immediately with number of bytes
>>>> s.send(b"aaaaaaaaa") -> same OS error as above (Error 70)
>>>>
>>>
>>> OK,
>>>
>>> this is really strange. I have no clue how that is possible unless it's
>>> on kernel side.
>>>
>>> I have to write a test for it later.
>>
>> I can confirm this behaviour, it is definetly kernel-side of the socket.
>>
>> tests/test_socketcan.py::TestCanIsoTpSocket::test_should_fail_missing_flow_control_on_transfer
>>
>>
>> --------------------------------------------------------------------------------------------------
>>
>> live log call
>> --------------------------------------------------------------------------------------------------
>>
>> 2021-05-11 18:14:00 [    INFO] Return value of IsoTpSend without flow
>> control: 64 (test_socketcan.py:720)
>> 2021-05-11 18:14:01 [   ERROR] Return value of IsoTpSend without flow
>> control: None, Raised [Errno 70] Communication error on send
>> (test_socketcan.py:718)
>>
>> Apparently there is another message thread for this and something was
>> fixed.
>>
>> https://marc.info/?i=97e2ddd5-cc8b-9c7b-6198-2eceee39dfd4%20()%20hartkopp%20!%20net
>>
>>
>> Funny thing is, it does not care about the wait_tx_done flag, this
>> happens with and without it.
> 
> The error handling was originally intended to be done by simple timeout
> monitoring on application level.
> 
> What I assume from the output above:
> 
> 1st attempt: We have a failure but we happily return that we have send
> 64 bytes (which Marc improved with the above referenced patch for
> CAN_ISOTP_WAIT_TX_DONE mode).
> 
> (socket remains open?!?)
> 
> 2nd attempt: The error from the first attempt shows up in the socket
> error message queue?!?
> 
> I just did some tests with a modified isotpsend.c which closes the
> socket after the sending operation. This is probably the reason I did
> not see that behaviour ...

I forgot to post my test which produced that result above.

https://gitlab.com/Menschel/socketcan/-/commit/bd7bfebde1d791c7dccb717c849398c0d0f53dcd

I run it on a pi0w with regular raspbian buster and a recent python
3.9.4 installed.
"pytest
tests/test_socketcan.py::TestCanIsoTpSocket::test_should_fail_missing_flow_control_on_transfer"

Regards,
Patrick

Re: CAN ISO-TP

[Patrick Menschel]

Am 11.05.21 um 21:02 schrieb Patrick Menschel:
> Am 11.05.21 um 19:44 schrieb Oliver Hartkopp:
>> On 11.05.21 18:37, Patrick Menschel wrote:
>>> Am 10.05.21 um 20:04 schrieb Patrick Menschel:
>>>> Am 10.05.21 um 12:02 schrieb Bartosz Zdanowicz:
>>>>> pt., 7 maj 2021 o 09:59 Patrick Menschel <menschel.p@posteo.de>
>>>>> napisał(a):
>>>>>> try to enable CAN_ISOTP_WAIT_TX_DONE via socket.setsockopt() .
>>>>>> https://github.com/raspberrypi/linux/blob/rpi-5.10.y/net/can/isotp.c#L14
>>>>>>
>>>>>>
>>>>>> https://gitlab.com/Menschel/socketcan/-/blob/master/socketcan/socketcan.py#L583
>>>>>>
>>>>>>
>>>>>> and wrap tx into a try-except block.
>>>>>>
>>>>>> try:
>>>>>>      self.process_data(socket=socket)
>>>>>> except OSError as e:
>>>>>>      print(e)
>>>>>>
>>>>>> With this you actually have a chance to do error handling on tx path
>>>>>> instead of hitting an already present error of the previous op.
>>>>>>
>>>>> I used following code:
>>>>>
>>>>> import isotp
>>>>> import time
>>>>> s = isotp.socket()
>>>>> s._socket.settimeout(2)
>>>>> s.set_opts(s.flags.WAIT_TX_DONE)
>>>>> s.bind("can0", isotp.Address(rxid=1, txid=2))
>>>>>
>>>>> s.send(b"aaaaaaaaa") -> returns immediately with number of bytes
>>>>> s.send(b"aaaaaaaaa") -> same OS error as above (Error 70)
>>>>>
>>>>
>>>> OK,
>>>>
>>>> this is really strange. I have no clue how that is possible unless it's
>>>> on kernel side.
>>>>
>>>> I have to write a test for it later.
>>>
>>> I can confirm this behaviour, it is definetly kernel-side of the socket.
>>>
>>> tests/test_socketcan.py::TestCanIsoTpSocket::test_should_fail_missing_flow_control_on_transfer
>>>
>>>
>>> --------------------------------------------------------------------------------------------------
>>>
>>> live log call
>>> --------------------------------------------------------------------------------------------------
>>>
>>> 2021-05-11 18:14:00 [    INFO] Return value of IsoTpSend without flow
>>> control: 64 (test_socketcan.py:720)
>>> 2021-05-11 18:14:01 [   ERROR] Return value of IsoTpSend without flow
>>> control: None, Raised [Errno 70] Communication error on send
>>> (test_socketcan.py:718)
>>>
>>> Apparently there is another message thread for this and something was
>>> fixed.
>>>
>>> https://marc.info/?i=97e2ddd5-cc8b-9c7b-6198-2eceee39dfd4%20()%20hartkopp%20!%20net
>>>
>>>
>>> Funny thing is, it does not care about the wait_tx_done flag, this
>>> happens with and without it.
>>
>> The error handling was originally intended to be done by simple timeout
>> monitoring on application level.
>>
>> What I assume from the output above:
>>
>> 1st attempt: We have a failure but we happily return that we have send
>> 64 bytes (which Marc improved with the above referenced patch for
>> CAN_ISOTP_WAIT_TX_DONE mode).
>>
>> (socket remains open?!?)
>>
>> 2nd attempt: The error from the first attempt shows up in the socket
>> error message queue?!?
>>
>> I just did some tests with a modified isotpsend.c which closes the
>> socket after the sending operation. This is probably the reason I did
>> not see that behaviour ...
> 
> I forgot to post my test which produced that result above.
> 
> https://gitlab.com/Menschel/socketcan/-/commit/bd7bfebde1d791c7dccb717c849398c0d0f53dcd
> 
> I run it on a pi0w with regular raspbian buster and a recent python
> 3.9.4 installed.
> "pytest
> tests/test_socketcan.py::TestCanIsoTpSocket::test_should_fail_missing_flow_control_on_transfer"


Just tying some loose ends here.
I rewrote the test to be in line with pytest convention.
"can_interface" is a pytest fixture which will use any CAN interface
that is available. OSError is expected so it fails.

Regards,
Patrick

https://gitlab.com/Menschel/socketcan/-/blob/master/tests/test_socketcan.py#L708

====================================================================================================
FAILURES
=====================================================================================================
______________________________________________________________________
TestCanIsoTpSocket.test_should_fail_missing_flow_control_on_transfer
_______________________________________________________________________

self = <tests.test_socketcan.TestCanIsoTpSocket object at 0xb55d2370>,
can_interface = 'mcp1'

    def test_should_fail_missing_flow_control_on_transfer(self,
can_interface):
        rx_addr = 0x18DA01FA
        tx_addr = 0x18DAFA01
        s = CanIsoTpSocket(interface=can_interface, rx_addr=rx_addr,
tx_addr=tx_addr)
        data = bytes(range(64))
        with pytest.raises(OSError):
>           err = s.send(data)
E           Failed: DID NOT RAISE <class 'OSError'>

tests/test_socketcan.py:714: Failed
________________________________________________________________
TestCanIsoTpSocket.test_should_fail_missing_flow_control_on_transfer_and_wait_tx
_________________________________________________________________

self = <tests.test_socketcan.TestCanIsoTpSocket object at 0xb55d28b0>,
can_interface = 'mcp1'

    def
test_should_fail_missing_flow_control_on_transfer_and_wait_tx(self,
can_interface):
        rx_addr = 0x18DA01FA
        tx_addr = 0x18DAFA01
        s = CanIsoTpSocket(interface=can_interface, rx_addr=rx_addr,
tx_addr=tx_addr, wait_tx_done=True)
        data = bytes(range(64))
        with pytest.raises(OSError):
>           err = s.send(data)
E           Failed: DID NOT RAISE <class 'OSError'>

tests/test_socketcan.py:722: Failed