Add Ethernet+Marvell switch tag link-layer header types.

[vivien]

No description provided.

[vivien]

Hi Guy, I've force-pushed a new iteration.

[guyharris]

The Marvell documentation says that, for TO_CPU frames, b18, b17, and b16 are "CPU_Code[3:1] when using none extended mode" and b12 is "CPU_Code[0] when using none extended mode", and that "CPU_Code[3:0] must be set to 0xF to indicate an Extended DSA tag."

Is "CPU_code" the same thing as the frame type, and is it a four-bit field with b18 being part of the field?

[guyharris]

The Marvell documentation also describes a second 32-bit word for the tag, which might be what the "Extended DSA tag" refers to, i.e. if b18/b17/b16/b12 is 0xF, then there's an additional 32-bit word.

[vivien]

I am not sure what you are referring to by "Marvell documentation". If that is the link the a PDF hosted on lafribre.info you gave here, I am not aware of this device and the DSA tag format seems a bit older/different. This is a SoC I think. Googling for "dsa tag format from_cpu to_cpu" for example may provide documentation for Ethernet switches (88E*).

[vivien]

The current MEDSA ether printer in the tcpdump code is an alternative implementation of the (E)DSA tags. That said, if this 88F* datasheet show a different format, what would be your approach? Would you like to ignore it until it is actually tested by someone? Or would you prefer tcpdump to be less verbose and ignore these "To_CPU frame code" bits?
I would say the important parts here are the tag mode, the source/target device/port and the (IEEE) tagged data. But that might be subjective.

[guyharris]

Republic of Venice FTW!

US Patent 8.923,297 describes (see Tables 1, 2, 3, and 4) something that looks similar to the what the 88F6180/88F6190/88F6192/88F6281 data sheet shows for TO_CPU and FORWARD tags; the 88F data sheet says "See the specific GbE switch specification for exact details on the DSA tag format and usage." for FROM_CPU tags. The patent doesn't describe the second "Extend" word, however.

(BTW, US Patent 8,379,644 appears to mention EDSA - "In accordance with the FIG. 3 embodiment, the standard DSA Tag format has been modified to include four additional bytes of data. Bytes 391 and 392 define respective EtherTypes that a port may be expected to be used for data traffic on a particular network. ...")

I haven't yet found a patent giving the DSA Tag format from the 88E6092/88E6095/88E6095F data sheet.

So I'm guessing that the 88F6180/88F6190/88F6192/88F6281 format isn't restricted to Ethernet adapter chips - presumably the chips the 88F6180/88F6190/88F6192/88F6281 data sheet describes can be combined with some form of switch chip, to implement, for example, a digital home gateway with a multi-port Ethernet switch in the back - and the switch chips in question may use the same DSA Tag format.

The 88E6092/88E6095/88E6095F data sheet has an older date, so it may be that they have an older DSA Tag format and a newer one.

This data sheet for the 88E6096/88E6097/88E6097F switch chips mentions EDSA as well as DSA, and gives the DSA Tag formats for all four types. It describes a format similar to the one in the 88E6092/88E6095/88E6095F data sheet, but the tag has some more fields.

[guyharris]

The code in net/dsa/tag_dsa.c and net/dsa/tag_edsa.c has the tag format wired into the code, so if Linux ever adds support for a switch chip using the "Extend" format, there will have to be new code.

As such:

1. Let's treat these two types as referring only to the old no-Extend-bit tags;
2. If support for the Extend-bit tag is ever added, it should get new DSA_TAG_PROTO_ types for the DSA and EDSA formats, so they have different names and get different LINKTYPE_/DLT_ values.

[vivien]

The code in net/dsa/tag_dsa.c and net/dsa/tag_edsa.c has the tag format wired into the code, so if Linux ever adds support for a switch chip using the "Extend" format, there will have to be new code.

As such:

1. Let's treat these two types as referring only to the old no-Extend-bit tags;

2. If support for the Extend-bit tag is ever added, it should get new DSA_TAG_PROTO_ types for the DSA and EDSA formats, so they have different names and get different LINKTYPE_/DLT_ values.

Correct, because there is no way to distinguish this "Extend" variant from the frame itself, the switch driver will have to tell the kernel that it uses this particular tagging format, thus this will require a new tag parser in net/dsa/ as well as a new value for the master interface's dsa_tagging attribute (which libpcap relies on.)

So if I understand correctly, you want me to implement the tagging format described in the old 88E6092/88E6095/88E6095F data sheet, which is a valid subset of the tagging format described in newer datasheets, that is used by the kernel today.

This means that my current PRs are valid, except that I must limit the To_CPU Code values to BPDU (MGMT) Trap, IGMP/MLD Trap and ARP Mirror, and remove the description for the To_Sniffer tag mode, which isn't used in the kernel (even though the old datasheet does mention it but doesn't describe it.) Correct?

Also, the Forward tag mode is bidirectional, either sent by the switch to the CPU, or sent by the CPU to delegate the frame processing. Is there a way from a tcpdump DLT printer to distinguish if the frame to be printed was received or sent by the listened interface? If so I can mark the switch port as "source" or "target" accordingly, otherwise no big deal.

[guyharris]

So if I understand correctly, you want me to implement the tagging format described in the old 88E6092/88E6095/88E6095F data sheet, which is a valid subset of the tagging format described in newer datasheets, that is used by the kernel today.

No, implement the tagging format described in the 88E6096/88E6097/88E6097F data sheet, as it appears to be a superset of the format in the 88E6092/88E6095/88E6095F data sheet (unless I've missed some place where they're incompatible). That data sheet describes all four modes, including To_Sniffer mode, and describes To_CPU trap types from 0x0 (MGMT Trap) to 0x5 (Policy Mirror), with 0x6 and 0x7 described as "Reserved".

Neither of those are the same as the format in the patents and the 88F6180/88F6190/88F6192/88F6281 data sheet - and those would probably require different kernel code.

Also, the Forward tag mode is bidirectional, either sent by the switch to the CPU, or sent by the CPU to delegate the frame processing. Is there a way from a tcpdump DLT printer to distinguish if the frame to be printed was received or sent by the listened interface? If so I can mark the switch port as "source" or "target" accordingly, otherwise no big deal.

Currently, no. However, one item on my (bigger than I'd like) to-do list is to:

• add new APIs for both live capture and capture-file reading that are more pcapng oriented (they'll handle reading both pcap and pcapng files, but, when reading a pcap file, obviously won't supply information that pcap doesn't support);

• on Linux, and other platforms where the capture mechanism supplies packet direction information, supply that information to capture callbacks in the Enhanced Packet Block flags word;

• add new APIs to write pcapng files;

• have tcpdump use the new APIs, if the libpcap with which it's being linked supports them, and provide all the relevant information to printers, so they can determine whether a packet is incoming or outgoing if that information is available.

[vivien]

Hi Guy, it makes sense. I've updated the PR(s).