Anthony Coddington
changed
bug 12526
Comment # 1
on bug 12526
from Anthony Coddington
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? Does still calling
it caplen make sense? Adding a phdr_len seems like the lowest impact approach
though. Making broader changes might not be quite so bad since most of the
dissector side is already abstracted away by tvb lengths.
What about trailing 'pseudoheaders' like PCAP-NG EPB options? 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 pseudoheader? An
interesting case in point here is something like LINKTYPE_ERF in PCAP(-NG),
where more than one dissector could be involved in dissecting the
pseudoheaders/trailers.
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?
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.
Another question is whether this should be related somehow to filetype
dissectors (which might no longer be limited to non-packet records)?
You are receiving this mail because:
- You are watching all bug changes.
