add linktype for ATSC ALP link protocol

[nickkelsey]

ATSC 3.0 uses a new packet based link layer - ATSC Link-Layer Protocol (ALP) as defined in the ATSC A/330 specification. The link layer typically carries multicast UDP/IPv4 packets and signalling packets.

ATSC 3.0 devices may use this linktype to capture ALP packets and output in pcap format.

(Silicondust makes network attached tuner devices with open APIs for anyone to use)

[guyharris]

OK, looking at the capture file you sent me, using that handy file-examination tool "Wireshark" (with some fixes to handle nanosecond-resolution pcap files when it's acting as proto-Fileshark - thanks for triggering that Wireshark bug!), the first packet's data begins with:

05 dc 45 00 05 dc 6c 87

So that's

00000101 11011110

for the first two bytes. At least as I read the A330 spec that's presumably

• 000 - Packet_Type
• 0 - PC
• 0 - HM
• 10111011110 - length = 1502

So that's an IPv4 packet, with a length of 1502, with no additional header. What follows starts with 45 00, so that appears to be an IPv4 packet.

Presumably, then, the right description would be something such as

ATSC Link-Layer Protocol frames, as described in section 5 of the A/330 Link-Layer Protocol specification, found at the ATSC 3.0 standards page, beginning with a Base Header.

I'm linking the top-level standards page there, in case the URL for the A/330 spec changes.

The header is defined in a byte-by-byte fashion, so there don't appear to be any byre-order issues with the link layer.

[guyharris]

You should also add a new entry at the end of dlt_choices[] in pcap.c as well, just before ``DLT_CHOICE_SENTINEL`.

It might be possible to add filtering for IPv4 packets without too much difficulty, at least for packets not fragmented at the link layer.

[nickkelsey]

On 3/20/2020 9:35 PM, Guy Harris wrote: OK, looking at the capture file you sent me, using that handy file-examination tool "Wireshark" (with some fixes to handle nanosecond-resolution pcap files when it's acting as proto-Fileshark - thanks for triggering that Wireshark bug!), the first packet's data begins with: 05 dc 45 00 05 dc 6c 87 So that's 00000101 11011110 for the first two bytes. At least as I read the A330 spec that's presumably      000 - Packet_Type      0 - PC      0 - HM      10111011110 - length = 1502 So that's an IPv4 packet, with a length of 1502, with no additional header. What follows starts with 45 00, so that appears to be an IPv4 packet. Perfect. Most packets will IPv4 like this with no header extensions, so just 2 bytes of ALP header (not included in the payload length count) Every now and again you sill see a signalling packet and they tend to be PC=0 HM=1 Presumably, then, the right description would be something such as ATSC Link-Layer Protocol frames, as described in section 5 of the A/330 Link-Layer Protocol specification, found at the ATSC 3.0 standards page, beginning with a Base Header. I'm linking the top-level standards page there, in case the URL for the A/330 spec changes. Description looks good. The header is defined in a byte-by-byte fashion, so there don't appear to be any byre-order issues with the link layer. Yep - everything is always aligned the same within any byte so you can parse by advancing a byte pointer. Nick

[guyharris]

OK, I'll check in an update to the tcpdump-htdocs repository, adding it to the link-layer header types page.