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

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

[Alexander Stein]

Hello,

a student noticed that during his CANopen SDO transfer traffic candump sometimes shows e.g.
> (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.

Best regards,
Alexander

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

[Oliver Hartkopp]

Am 22.01.2013 08:55, schrieb Alexander Stein:

> a student noticed that during his CANopen SDO transfer traffic candump sometimes shows e.g.
>> (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'.

Best regards,
Oliver

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

[Alexander Stein]

Hello Oliver,

On Tuesday 22 January 2013 09:44:09, Oliver Hartkopp wrote:
> Am 22.01.2013 08:55, schrieb Alexander Stein:
> 
> > a student noticed that during his CANopen SDO transfer traffic candump sometimes shows e.g.
> >> (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'.

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.

Thanks so far.
Alexander

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

[Alexander Stein]

On Tuesday 22 January 2013 09:58:54, Alexander Stein wrote:
> Hello Oliver,
> 
> On Tuesday 22 January 2013 09:44:09, Oliver Hartkopp wrote:
> > Am 22.01.2013 08:55, schrieb Alexander Stein:
> > 
> > > a student noticed that during his CANopen SDO transfer traffic candump sometimes shows e.g.
> > >> (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'.
> 
> 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.

Oliver, you were right. This issue was raised by local CAN frames and a memset on the struct solves this annoyance. Thanks for the hint.

Regards,
Alexander