Comment # 30
on bug 12687
from Michael Mann
(In reply to Oliver Hartkopp from comment #29)
> (In reply to Michael Mann from comment #26)
> > (In reply to Oliver Hartkopp from comment #23)
> > > You patch has at least two issues:
> > >
> > > 1. The frame_type_vals still contain RTR. Please check my patch to fix this
> > > up.
> >
> > My first patch today (unintentionally) left the RTR logic as is. Subsequent
> > patches tried to "improve" it, but I don't understand the justification for
> > effectively removing it entirely. Isn't it just something that isn't
> > supported in CANFD, but is still supported in "Classic" CAN?
>
> Only Classic CAN supports RTR.
> But you can have STD (== 11 bit Identifier) or XTD (==29 bit Identifier) CAN
> frames that may contain data bytes (length according to DLC) OR the CAN
> frame is a RTR frame which has a DLC but no data content.
> Therefore RTR can not be a 'frame type' like STD or XTD.
>
> As RTR has turned out to be 'bad' they left out RTR frames when defining CAN
> FD.
I didn't realize what STD and XTD actually meant. I think I should use those
better when passing the CAN ID to subdissectors (i.e. already apply the
bitmask). There's another Wireshark bug that could be helped by this
information.
> The two SLL types are not really relevant for CAN application programmers.
> It's a Linux internal thing which only becomes visible when programming
> PF_PACKET sockets.
>
> For that reason my suggested changes to libpcap make sense to me as they are
> using PF_CAN sockets to get the CAN frames - and this would be a reasonable
> extension then.
I think I'll leave the SLL support in there for now for the same reason the
other SLL types are supported - people may use them, even if it's "internal".
If the flag becomes an issue, we can worry about it then.
You are receiving this mail because:
- You are watching all bug changes.
