Comment # 2
on bug 12526
from Guy Harris
(In reply to Anthony Coddington from comment #1)
> One effect this would have is 'caplen' would no longer really be
> captured-from-the-wire length anymore (it isn't in PCAP/PCAP-NG anyway, but
> has traditionally been in Wireshark).
>
> Would real captured bytes be caplen-phdr_len in all cases?
If we always ensure that phdr_len <= caplen, yes, it would.
Given that, for example, a snaplen of 1, 2, or 3 wouldn't even leave enough
room for the length field of a radiotap pseudo-header, my inclination would be
to require that all libwiretap modules ensure that phdr_len <= caplen. In the
case of radiotap, for example, the code in pcap-common.c to handle radiotap
would do
if (caplen < 3)
phdr_len = caplen;
else {
phdr_len = it_len field from the radiotap pseudo-header;
if (phdr_len > caplen)
phdr_len = caplen;
}
> Does still calling it caplen make sense?
It's called "Captured Packet Length" in the pcapng specification, so I guess we
could continue to call it caplen.
> Adding a phdr_len seems like the lowest impact approach though.
That's probably a good start. There's enough "more thought and perhaps even
more experience is required" stuff in the current libwiretap API that I would
push as hard as possible *NOT* to freeze it in 2.2, and leave it open for some
significant future work.
> What about trailing 'pseudoheaders' like PCAP-NG EPB options?
The libwiretap API should, for all records it returns, provide an array of
options, in the same form as the array of options that the wtap_opttypes code
does. The pcapng EPB options should be supplied in that fashion, rather than
as payload.
And, yes, that's probably how the ERF reader should handle its extension
headers as well.
> Is it
> reasonable to assume they all belong to one dissector that passes an
> appropriate tvb downstream or does more than one dissector need to handle
> the pseudo header?
They wouldn't even be *in* a tvbuff.
> Things like CPacket trailer timestamps are even more murky since they affect
> the Ethernet CRC, I'd probably argue those shouldn't count as phdr_len but
> am not sure. Otherwise dissectors might need to be able to dynamically
> update phdr_len which might get messy, as wiretap may not be fully aware of
> possible pseudoheadrs in that case. Perhaps the definition here should be it
> is only pseudoheader if it relates to a wtap_encap encapsulation type?
It's a pseudo-header if it relates to a file type or encapsulation type (and
that may mean we'd supply two pseudo-headers in some cases).
> We should also be careful to support frames with no on-the-wire length, i.e.
> caplen >= len is not a reasonable assumption in the case of some types of
> PCAP-NG blocks and other types of metadata only records.
Presumably you meant "caplen <= len".
And presumably (caplen-phdr_len) <= len *is* a reasonable assumption.
> Another question is whether this should be related somehow to filetype
> dissectors (which might no longer be limited to non-packet records)?
"filetype dissectors" meaning dissectors for information specific to particular
file types?
You are receiving this mail because:
- You are watching all bug changes.