candump -x: brs esi is set on non-canfd interfaces

(000.000124) can0 TX B E 641 [8] 00 32 33 34 35 36 37 38

a student noticed that during his CANopen SDO transfer traffic candump sometimes shows e.g.

Quoted 1 line

(000.000124) can0 TX B E 641 [8] 00 32 33 34 35 36 37 38

while on a non-canfd interfaces. It seem to occur at some time and disappears again for one SDO transfer and it occurs for another transfer and stays forever. I see that candump always uses struct canfd_frame, but AFAICS the flags member should not be set at all, as alloc_can_skb does a memset on struct can_frame. So the padding bytes in can_frame are zero which are used for flags in canfd_frame. When printing flags directly it is set to 0x7F. Has anybody an idea what could cause this? I could find any position which would manipulate the flags byte.

Am 22.01.2013 08:55, schrieb Alexander Stein:

Quoted 5 lines

a student noticed that during his CANopen SDO transfer traffic candump sometimes shows e.g.

Quoted 1 line

(000.000124) can0 TX B E 641 [8] 00 32 33 34 35 36 37 38

while on a non-canfd interfaces. It seem to occur at some time and disappears again for one SDO transfer and it occurs for another transfer and stays forever. I see that candump always uses struct canfd_frame, but AFAICS the flags member should not be set at all, as alloc_can_skb does a memset on struct can_frame. So the padding bytes in can_frame are zero which are used for flags in canfd_frame. When printing flags directly it is set to 0x7F. Has anybody an idea what could cause this? I could find any position which would manipulate the flags byte.

Is it possible that you generate that CAN frame on the local host? If you do not zero the struct CAN frame before sending it e.g. via CAN_RAW socket this could be an idea where it comes from.

Because as you already pointed out alloc_can_skb() initializes the struct properly. But this only is relevant from CAN frames from 'the outside'.

Hello Oliver,

Quoted 8 lines · Oliver Hartkopp

Am 22.01.2013 08:55, schrieb Alexander Stein:

Quoted 5 lines

a student noticed that during his CANopen SDO transfer traffic candump sometimes shows e.g.

Quoted 1 line

(000.000124) can0 TX B E 641 [8] 00 32 33 34 35 36 37 38

while on a non-canfd interfaces. It seem to occur at some time and disappears again for one SDO transfer and it occurs for another transfer and stays forever. I see that candump always uses struct canfd_frame, but AFAICS the flags member should not be set at all, as alloc_can_skb does a memset on struct can_frame. So the padding bytes in can_frame are zero which are used for flags in canfd_frame. When printing flags directly it is set to 0x7F. Has anybody an idea what could cause this? I could find any position which would manipulate the flags byte.

Quoted 6 lines

Is it possible that you generate that CAN frame on the local host? If you do not zero the struct CAN frame before sending it e.g. via CAN_RAW socket this could be an idea where it comes from.

Because as you already pointed out alloc_can_skb() initializes the struct properly. But this only is relevant from CAN frames from 'the outside'.

I don't know about the details that much, but you actually might be right. I will forward your suggestion and reply with the response.