cangw freezes after ~4,000 msgs

[s177oke77]

cangw freezes after ~4,000 msgs

[s177oke77]

Sorry, let me clarify. I put on 60ohm resistors on both segments. They are still currently installed.

[hartkopp]

The txqueuelen is still vast to high. I would not exceed the value for such test to more than 100 to get an idea where the problem shows up. When your MCP251x CAN controller is simply too slow to send the desired frame rate you should be able to detect this instantly.

The MCP251x connected via SPI is not a setup with known best performance and stability. This has been improved with the CAN FD version and recent CAN/SPI driver improvements in the Linux kernel. What HW/SW are you running there? RasPi4 with Linux kernel 6.1?

You might also try to set some other controller options for the bitrate settings:
ip link set can0 up type can bitrate 125000 sjw 4 triple-sampling on

And you also might tweak the sample-point, e.g. sample-point 0.80 or sample-point 0.75 as you probably don't know the original ECU settings that are defined in the vehicle.

But PLEASE set the txqueuelen down to 100 to see what happens.

[s177oke77]

I've adjusted the txqueuelen to 100 as suggested and enabled triple sampling. The problem seems to be fixed. Both busses communicate fine now. Thank you! Can I ask you if canqw rules can filter out multiple messages like candump comma separated filters? Also if cangw -A -s can0 -d can1 -e -f 322:C00007FF -m AND:D:000.0.FFFF0000FFFFFFFF and cangw -A -s can0 -d can1 does the second rule still allow the original msg from --C-I-D 322 through to can1?

[hartkopp]

With the CAN_RAW socket candump can perform the 'join' option, which means the filters are logical "AND", so that you can define several "filter out" jobs: e.g. candump can0,123~C00007FF,333~C00007FF,j

In cangw all filters are independent from each other (logical OR). So creating two filter jobs with an inverted filter will always let something pass. Therefore I would suggest to create "positive" filters for the content you want to let pass.

E.g. use filters for ranges together with single CAN ID filters. The single CAN ID filters are very efficient.
https://www.kernel.org/doc/html/latest/networking/can.html#can-filter-usage-optimisation
"To benefit from the optimized filters for single CAN identifiers the CAN_SFF_MASK or CAN_EFF_MASK have to be set into can_filter.mask together with set CAN_EFF_FLAG and CAN_RTR_FLAG bits. A set CAN_EFF_FLAG bit in the can_filter.mask makes clear that it matters whether a SFF or EFF CAN ID is subscribed."

If you want to "overwrite" an existing cangw rule, check out the -u <uid> feature.

[s177oke77]

Thank you!

[hartkopp]

Having a txqueuelen of 1000 is usually broken. That just means you run into the problems 'later' - but it doesn't help at all.

Very likely the CAN frame tx rate is lower than than the receive rate.

1. Can you post the output of cangw -L as it shows the status of handled/dropped/deleted frames.
2. Do you run into similar problems without the tc stuff?

[s177oke77]

the cangw -L output:

cangw -A -s can1 -d can0 # 225 handled 0 dropped 0 deleted
cangw -A -s can0 -d can1 # 8780 handled 0 dropped 0 deleted

[hartkopp]

Looks good. What about question 2?

What's the status of the CAN interfaces then? (ip -det link show can0 and ip -det link show can1)

[s177oke77]

No other problem with tc. Normally do not touch it, just put in in there because another user (posted here) was having problems with candump freezing and I wanted to have all to information ready.

:~ $ ip -det link show can0
4: can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state BUS-OFF restart-ms 0 
	  bitrate 125000 sample-point 0.875 
	  tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
	  clock 8000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
:~ $ ip -det link show can1
5: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
	  bitrate 125000 sample-point 0.875 
	  tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
	  clock 8000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 

[hartkopp]

:~ $ ip -det link show can0
4: can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/can promiscuity 0 minmtu 0 maxmtu 0
can state BUS-OFF restart-ms 0

BUS-OFF means your CAN controller had problems with transmitting CAN frames and went into an error state that stops every CAN transmission.

So you likely have a CAN problem here. E.g. having two CAN controllers sending the same CAN ID to a CAN bus, or a missing node on can0 which ACKs the sent CAN frames or mismatching bitrates, missing termination, etc.

[s177oke77]

i apologize. the car shut down as i was entering the command. This one is with the car running

:~ $ ip -det link show can1
5: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 65536
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
	  bitrate 125000 sample-point 0.875 
	  tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
	  clock 8000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
s:~ $ ip -det link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 65536
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can state ERROR-WARNING restart-ms 0 
	  bitrate 125000 sample-point 0.875 
	  tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
	  mcp251x: tseg1 3..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
	  clock 8000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 

[hartkopp]

ERROR-WARNING is just one step before ERROR-PASSIVE (no TX possible)

Not really sure what happens here. But it doesn't seem to be can-gw related.

Did you separate a single(!!?) ECU from the vehicle's CAN bus?

If so, you likely have a termination problem. You need to have ~60 Ohms between CAN_L and CAN_H on either can0 and can1.

[s177oke77]

I did separate a single ECU. I will try that and report back, but in the mean time, if I only:

sudo cangw -A -s can0 -d can1

then it seems to be fine. If i do:

sudo cangw -A -s can1 -d can0

then:

cangw -A -s can1 -d can0 # 0 handled 0 dropped 0 deleted

seems termination is behind it. I will report back.

[s177oke77]

I tried the 60ohm resistors on halves of the can bus system, it may have help (went to 20,000 msgs before error). I tried a couple other things. When sending traffic in one direction: sudo cangw -A -s can0 -d can1 OR sudo cangw -A -s can1 -d can0 then everything is okay, but you don't get bidirectional communication as expected. If I do sudo cangw -A -s can0 -d can1 & sudo cangw -A -s can1 -d vcan0 then everything works as well. Its only when try to send traffic in both directions on the actual bus that there's a problem.

[s177oke77]

More testing shows that only CAN0 is halting all operation. If I send sudo ip link set can0 down
then sudo ip link set can0 up type can bitrate 125000 then both busses come back online for the same limited amount of time.

[s177oke77]

Also if I physically alternate the can0 and can1 connections then the error moves over to can1.

[hartkopp]

I tried the 60ohm resistors on halves of the can bus system,

What does "tried" mean? Do you still have 60 Ohms on both CAN segments or did you remove the resistors after you "tried" it?

[hartkopp]

No cangw problem 8-)