[tcpdump-workers] Request for link-layer header type (XRA)

Bruno Verstuyft bruno.verstuyft at gmail.com
Wed Jan 24 10:09:49 EST 2018


Updated the spec with the latest clarifications.

2018-01-21 0:42 GMT+01:00 Bruno Verstuyft <bruno.verstuyft at gmail.com>:

>
>
> 2018-01-19 23:21 GMT+01:00 Guy Harris <guy at alum.mit.edu>:
>
>> On Jan 19, 2018, at 5:03 AM, Bruno Verstuyft <bruno.verstuyft at gmail.com>
>> wrote:
>>
>> > 2018-01-19 10:10 GMT+01:00 Guy Harris <guy at alum.mit.edu>:
>> >
>> >> Is the Burst ID just a sequence of octets?
>> >
>> > For the moment, the Burst ID  is a uint64_t. Should this not be not
>> enough
>> > in future implementations, it can be increased to e.g. uint128_t
>>
>> So it should be treated as an opaque array of bytes, with no significance
>> to the values of the bytes, and used only for matching bursts and the MAC
>> frames contained within them by comparing the byte arrays for equality?
>>
>
> Yes, this is correct.
>
>
>>
>> >> What does the Burst ID Reference field contain?  Another burst ID?
>> >
>> > The Burst ID reference is the same as the Burst ID. Burst IDs are used
>> in
>> > databursts, while Burst ID references are used in Mac Frames. For the
>> > moment, these are both uint64_t.
>>
>> I.e., one or more MAC frames can be transmitted in a burst, and a capture
>> can contain a record for a burst as well as records for the MAC frames
>> within the burst, with the record for the burst having a Burst ID
>> parameter, and all the records for the MAC frames in that burst have a
>> Burst ID Reference parameter containing the burst ID value for the burst in
>> which it appeared?
>>
>
> This is also correct.
>


More information about the tcpdump-workers mailing list