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

Bruno Verstuyft bruno.verstuyft at gmail.com
Wed Jan 31 09:07:20 EST 2018


Hi,

can I already commit the dissector code for the XRA header to wireshark, or
is it best to wait for finalization of the spec details?

Best Regards,

Bruno

2018-01-24 16:09 GMT+01:00 Bruno Verstuyft <bruno.verstuyft at gmail.com>:

> 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