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.verstu...@gmail.com>: > Updated the spec with the latest clarifications. > > > 2018-01-21 0:42 GMT+01:00 Bruno Verstuyft <bruno.verstu...@gmail.com>: > >> >> >> 2018-01-19 23:21 GMT+01:00 Guy Harris <g...@alum.mit.edu>: >> >>> On Jan 19, 2018, at 5:03 AM, Bruno Verstuyft <bruno.verstu...@gmail.com> >>> wrote: >>> >>> > 2018-01-19 10:10 GMT+01:00 Guy Harris <g...@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. >> > > _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
