[tcpdump-workers] Linktype allocation for ATSC link layer protocol
ATSC 3.0 includes a new link layer protocol known as ALP (ATSC Link-layer protocol). A linktype allocation would enable packet capture and diagnostics of the ATSC 3.0 link layer. Proposed linktype allocation: LINKTYPE_ name = LINKTYPE_ATSC_ALP LINKTYPE_ value = 289 Corresponding DLT_ name = DLT_ATSC_ALP Description: ATSC link-layer protocol, as defined by ATSC A/330:2019 General link to ATSC 3.0 standards: https://www.atsc.org/standards/atsc-3-0-standards/ Direct link to ATSC A/330:2019 standard: https://www.atsc.org/wp-content/uploads/2016/10/A330-2019a-Link-Layer-Protocol.pdf I can provide pcap samples demonstrating ALP captured from the Phoenix ATSC 3.0 test market. Regards, Nick ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Linktype allocation for ATSC link layer protocol
ATSC 3.0 includes a new link layer protocol known as ALP (ATSC Link-layer protocol). So the first two octets of the packet data contain the Base Header? That appears to be a 16-bit header; in a capture, in what order are the bytes of the Base Header, and in what order are the bit fields? The same applies to other fields. There are a few different packet formats... If the most significant 3 bits of the first byte are 111b then the ALP packet contains MPEG-TS frames and the remaining bits in the first byte convey the count and if header deletion mode is used. The MPEG-TS frames are missing the leading 0x47 and optionally more of the header requiring minor reconstruction. The most common packet type is a single packet without additional header - this format is a simple 2 byte link layer header. Most commonly used to carry an IPv4 packet. Single packet with additional header - 3 bytes plus optional bytes. Segmentation packet where the payload has been split into multiple ALP packets - 3 bytes plus optional bytes, requires multi-packet reassembly to recover the payload. Concatenation packet where the ALP packet contains multiple payload frames - 3 bytes plus 12 bits per payload frame plus optional bytes. This one seems a little silly because it requires 12 bits (1.5 bytes) per concatenated payload where the overhead of putting each payload in a single packet is 2 bytes if you don't need additional headers. In single packet (with or without additional header), segmentation, and concatenation modes the payload type may be a type that has an additional header which must be accounted for before doing reassembly or splitting. In real-world captures I have seen single packets without additional header and single packets with additional header, carrying link-layer-signaling payloads and IPv4 payloads. I haven't seen MPEG-TS payloads, segmentation, or concatenation. Nick ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Linktype allocation for ATSC link layer protocol
But they all have the Base Header, and that header has: 3 bits of packet type; 1 bit of payload configuration; 1 bit of: header mode, if the payload configuration bit is 0; segmentation/concatenation, if the payload configuration bit is 1; 11 bits of length; for a total of 16 bits, right? Yes, unless the packet type is 111b in which case there the header is only 8 bits - you have the packet type, 4 bits indicating the count of TS frames (where 0 means a count of 16) and 1 bit indicating if header deletion mode is used. If so, in a capture file: 1) the Base Header has 2 octets - in what order in the file are the two octets? 2) in what order are the bit fields? Order - byte at a time, most significant bit first. The first 3 bits are the packet type - ie the most significant 3 bits of the first byte. For example, does the first octet of a packet contain: 3 bits of packet type in its upper 3 bits; 1 bit of payload configuration in the next lower bit; 1 bit of header mode or of segmentation/concatenation in the next lower bit; the uppermost 3 bits of length in the lowest 3 bits; and does the second octet contain the lowermost 8 bits of length? Correct, noting that the length field can be larger than 11 bits as follows: payload_configuration = 0, header_mode = 0: the length field is 3+8=11 bits long. payload_configuration = 0, header_mode = 1: the third byte contains another 5 bits of length (most significant) making the length field 16 bits long. payload_configuration = 1, segmentation_concatenation = 0: the length field is 3+8=11 bits long. payload_configuration = 1, segmentation_concatenation = 1: the third byte contains another 4 bits of length (most significant) making the length field 15 bits long. If the packet type is 4 (link layer signaling packet) then there is an additional 5 bytes of link layer signaling header after the optional headers, before you start counting the length. BTW - packets seem to often contain junk at the end. Nick ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Linktype allocation for ATSC link layer protocol
--- Begin Message --- For quick and simple maybe just report the packet type (first 3 bits). I can provide ALP packet captures and/or submit patches over time to expand the decoding. Key thing is the allocation of the linktype number so I can make captures public. Proposed linktype allocation: LINKTYPE_ name = LINKTYPE_ATSC_ALP LINKTYPE_ value = 289 Corresponding DLT_ name = DLT_ATSC_ALP Description: ATSC link-layer protocol, as defined by ATSC A/330:2019 General link to ATSC 3.0 standards: https://www.atsc.org/standards/atsc-3-0-standards/ Direct link to ATSC A/330:2019 standard: https://www.atsc.org/wp-content/uploads/2016/10/A330-2019a-Link-Layer-Protocol.pdf Nick --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Linktype allocation for ATSC link layer protocol
--- Begin Message --- After going to interop/test events and discussions with other engineers in the field it looks like a lot of the junk in the ATSC ALP protocol will never be used and can be ignored. The protocol is defined in the ATSC A/330 standard. Proposed implementation: 1) Check the packet_type (first 3 bits of the packet). If the packet type is 7 (MPEG2 transport stream) then report "MPEG2 transport stream" and stop parsing. It is likely this packet type will never be used in real-world use. Note that the fields that follow don't apply when the packet type is 7 - all we can do is report the packet type and stop. 2) If the payload_configuration bit is 1 check the segmentation_concatenation bit. If the segmentation_concatenation bit is 0 report that it is a "segmented packet" and stop parsing. It is likely this mode will never be used in real world use (the layer below this protocol does segmentation/reassembly). If the segmentation_concatenation bit is 1 report that it is a "concatenation packet" and stop parsing. It is likely this mode will never be used in real world use. 3) If the payload_configuration bit is 0 then the packet is useful! If header_mode is 0 then report the length and the packet_type. The packet type will typically be IPv4 packet (packet_type = 0) where the payload is a normal IPv4 packet. The other possible packet type is a link layer signalling packet (packet_type = 4). In this case there is an "Addition Header for Signaling" header followed by a table. Note that the payload_length tells you the table length - it does not include the "Addition Header for Signaling" header length. If header_mode is 1 then parse the single_packet_hdr(). If SIF flag is set then parse/skip sub_stream_identification() header. If HEF flag is set the parse/skip header_extension() header. At this point you look at the packet type, following the same logic as header_mode 0 above. Nick --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Linktype allocation for ATSC link layer protocol
--- Begin Message --- On 3/20/2020 11:17 AM, Michael Richardson wrote: > > Nick Kelsey via tcpdump-workers wrote: > > After going to interop/test events and discussions with other engineers in > > the field it looks like a lot of the junk in the ATSC ALP protocol will never > > be used and can be ignored. > > > The protocol is defined in the ATSC A/330 standard. > > > Proposed implementation: > > okay, this sounds fine. > Are you waiting for a link type allocation? > > libpcap/doc/DLT_ALLOCATE_HOWTO.md tells you how to do that with a pull request. Pull request created (#919): https://github.com/the-tcpdump-group/libpcap/pull/919 Thanks, Nick --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Linktype allocation for ATSC link layer protocol
--- Begin Message --- On 3/20/2020 9:42 PM, Guy Harris wrote: > On Mar 20, 2020, at 2:39 PM, Nick Kelsey via tcpdump-workers wrote: > >> Pull request created (#919): >> >> https://github.com/the-tcpdump-group/libpcap/pull/919 > > I've added a proposed description as a comment to the pull request; please check whether my assumptions are correct and whether the description would work for that format's entry on https://www.tcpdump.org/linktypes.html. Thanks! I figure there will be interest in this protocol as we start to see ATSC 3.0 test broadcasts. Our ATSC 3.0 hardware can output pcap data over HTTP in real time so ALP can be captured to file with a simple curl/wget command. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
