--- Begin Message ---
Thank you for explaining in such a great detail.
> It's about either 1) saying "slicing is forbidden" or 2) saying "here's how
> you do slicing".
I would rather not introduce the limitation if not really necessary. The way
you described earlier made sense to me so I am fi
--- Begin Message ---
>> That should also be noted in the specification.
I updated the specification with information about alignment, SrcID, and
PayloadType.
Slicing a captured packet is not supported by our capturing device.
>>>
>>> But some software can slice packets afterwards. Either
--- Begin Message ---
> If the fields of the footer are aligned on natural boundaries, the footer
> will be 72 bytes long; if they are *not* aligned, the footer will be 53 bytes
> long.
The footer is exactly 54 Bytes long.
__
> Are the
--- Begin Message ---
> Can the variable be anything *other* than a packet of some sort?
There are only the mentioned 5 representations planned for pcap files since
this is what our capture device may capture into a pcap file. The
representation gives at least the ability to extend in the future
word!
VORSICHT: Diese E-Mail kommt von einem externen Absender. Bitte keine Links
anklicken oder Anlagen öffnen falls Sie den Absender nicht kennen. Niemals Ihr
Kennwort eingeben!
On Mar 8, 2021, at 12:07 AM, Jan Adam via tcpdump-workers
wrote:
> We have created a public document on our we
--- Begin Message ---
Hello
We have created a public document on our website You can point to for the
description.
Here is the link: https://kb.hilscher.com/x/brDJBw
It contains a more detailed description of the fields in the footer structure.
It also contains a C – like structure definition
--- Begin Message ---
Hi,
for our new analysis product netANALYZER NG I would like to request a new
link-layer type value.
NETANALYZER_NG
The new Link-Layer-Type format is described as following:
Next-generation packet structure:
+---+
| Payload |
.
