Re: [PATCH v2 net-next 07/22] ether: Add dedicated Ethertype for pseudo-802.1Q DSA tagging
From: Vladimir Oltean
Date: Wed Apr 10 2019 - 17:31:22 EST
On 4/10/19 5:04 AM, Florian Fainelli wrote:
On 4/9/2019 5:56 PM, Vladimir Oltean wrote:
With the newly added DSA_TAG_PROTO_8021Q, switch devices that don't
support a native insertion/extraction header on the CPU port may still
enjoy the benefits of port isolation with a custom VLAN tag.
For this, they need to have a customizable TPID in hardware and a new
Ethertype to distinguish between real 802.1Q traffic and the private
tags used for port separation.
Signed-off-by: Vladimir Oltean <olteanv@xxxxxxxxx>
Why was not using ETH_P_EDSA not suitable? Also how do we intend to use
this from user-space? The latest libpcap/tcpdump changes essentially
look at the dsa/tagging sysfs attribute for the master network device to
determine what type of underlying tagging protocol is used, since you
allocated a new one (NET_DSA_TAG_8021Q) you could have added a matching
string in sysfs so we can recognize it?
I'll freely admit that I hardly gave a second thoughts to Andrew's
previous reply, who said that tcpdump will parse these frames as MEDSA
and not much can be done about it.
But thanks for the hint, I was completely unaware of the recent pull
requests you guys made for DSA data link types in libpcap. As a pleb I
am only using the latest tcpdump/libpcap release tag.
I didn't look closely at the pull requests, but you're saying that it's
possible to discern based on /sys/class/net/eth2/dsa/tagging (which
returns "sja1105") and figure out that it's not MEDSA?
Also remember that NET_DSA_TAG_8021Q in my proposal is not a real
tagging protocol and therefore you won't see it in sysfs.
Awaiting some further advice on this, as I have obviously missed out on
quite a lot.
Thanks,
-Vladimir