Re: CAN ISO-TP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



czw., 6 maj 2021 o 20:01 Oliver Hartkopp <socketcan@xxxxxxxxxxxx> 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@xxxxxxxxxxxx/
>
> 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




[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux