From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Kurt Van Dijck <kurt.van.dijck@eia.be>
Cc: Felix Obenhuber <felix@obenhuber.de>, linux-can@vger.kernel.org
Subject: Re: Wireshark / libpcap - was Re: [RFC] CAN FD support part 2 - ideas and commented source
Date: Fri, 04 May 2012 11:59:56 +0200 [thread overview]
Message-ID: <4FA3A89C.8080209@hartkopp.net> (raw)
In-Reply-To: <20120504092937.GA420@vandijck-laurijssen.be>
On 04.05.2012 11:29, Kurt Van Dijck wrote:
> On Thu, May 03, 2012 at 08:01:32PM +0200, Oliver Hartkopp wrote:
>> On 03.05.2012 14:50, Oliver Hartkopp wrote:
>>
>>> On 03.05.2012 14:37, Kurt Van Dijck wrote:
>>
>>
>>>> I don't see benefit in introducing ETH_P_CANFD.
>>>> Using the skb's payload length differentiates enough between CAN_MTU & CANFD_MTU.
>>>> Why not using that info. IMHO, ETH_P_CANFD duplicates the info.
>>>
>>>
>>> This has a big advantage when thinking about wireshark & friends.
>>>
>>> You can look into the eth protocol and know the skb data layout.
>>> The length information is some kind of implicit knowledge.
>>
> Oliver,
>
> Thanks for the explanation.
> It shows how ETH_P_XXX values escape from kernel space.
> It thus promotes to a part of the ABI, which I did not yet realize :-).
>
> But you did not address my other concern, why you use
> different values for CAN & CANFD.
>
>>> You can look into the eth protocol and know the skb data layout.
> Again, both layouts are compatible.
Hm - nearly.
As the canfd_frame.flags element is new AND you have a different PDU length.
:-)
>
>>> The length information is some kind of implicit knowledge.
> Again, there are so many checks to fix the length to one of 2 available
> MTU's that I doubt the implicit character of the lenght information
> for the CAN situation.
>
> I appreciate your effort in digging up Felix's original posts.
> His opinions on this may be very usefull.
Yes - let's see ...
>
> Kurt
>
> [...]
>>
>> For that reason and because of the reference to <linux/if_ether.h> i think
>> it's pretty relevant to wireshark and libpcap - that's why i added Felix in CC.
>>
>> http://sourceforge.net/tracker/?func=detail&aid=2872132&group_id=53067&atid=469579
>>
>> Regards,
>> Oliver
>>
next prev parent reply other threads:[~2012-05-04 9:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4FA242D0.2070604@hartkopp.net>
2012-05-03 11:14 ` [RFC] CAN FD support part 2 - ideas and commented source Oliver Hartkopp
2012-05-03 12:37 ` Kurt Van Dijck
2012-05-03 12:50 ` Oliver Hartkopp
2012-05-03 13:22 ` Kurt Van Dijck
2012-05-07 11:51 ` Felix Obenhuber
2012-05-07 18:03 ` Oliver Hartkopp
2012-05-03 18:01 ` Wireshark / libpcap - was " Oliver Hartkopp
2012-05-04 9:29 ` Kurt Van Dijck
2012-05-04 9:59 ` Oliver Hartkopp [this message]
2012-05-07 12:19 ` Felix Obenhuber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FA3A89C.8080209@hartkopp.net \
--to=socketcan@hartkopp.net \
--cc=felix@obenhuber.de \
--cc=kurt.van.dijck@eia.be \
--cc=linux-can@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox