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 = D
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
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;
--- 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
--- 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
--- 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
p
--- 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 d
