Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TX/RX packets are incorrectly labeled #485

Open
spaceKelan opened this issue Dec 13, 2023 · 1 comment
Open

TX/RX packets are incorrectly labeled #485

spaceKelan opened this issue Dec 13, 2023 · 1 comment

Comments

@spaceKelan
Copy link

Dear all,

I added this to stackoverflow, a while ago as I thought it might be an issue on my side : https://stackoverflow.com/questions/76763697/why-does-candump-of-can-utils-flag-sent-frames-as-rx-instead-of-tx

raspberry pi sends messages:

On that device I have two terminals open:

  1. to look at candump -x any expecting TX messages

  2. to send messages cansend can0 <ID>#<data>

device B receives the messages sent by raspberry pi.

However, raspberry pi displays the "RX" flag, even though socketcan is setup explicitly with loopback off.

The candump on the TX side is malicious:
enter image description here

The frame counters increase correctly:
enter image description here
I am confident the "TX" messages are falsely displayed with "RX" flag.

Did anybody else experience that bug or knows what the issue is?

I worked with candump of the can-utils toolbox two weeks ago and it worked fine. I did not update the toolbox since then.

When I turned loopback on, I received two messages with RX

  • one for the sent message
  • one for the received message

I rebooted both systems, reinstalled can-utils and still receive the same behavior.

@marckleinebudde
Copy link
Member

Which CAN controller are you using on the raspi? ip --details -s -s -s link show can0

Which Kernel version are you using? uname -a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants