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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.