Comment # 4
on bug 12526
from Anthony Coddington
(In reply to Guy Harris from comment #2)
> (In reply to Anthony Coddington from comment #1)
> > 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.
Right, I've always found it a little confusing the caplen includes non on the
wire pseudoheaders, but here we are effectively matching up the concepts again
between pcapng and Wireshark.
> > 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).
There are two related but different ideas here: I understand the idea currently
proposed in this RFC is to put ALL captured data as part of 'payload' and
passing them to regular encap dissectors for display in the tree similar to the
USB dissector (possibly even including file level information) as just another
'layer' in the packet. Some metadata might need to also be extracted at the
wtap level e.g. optionblocks but the phdr union becomes scrapped in concept.
The purpose of the phdr_len here is to allow correct bandwidth statistics in
this situation where non-wire 'payload' is present. The outer tvb passed by
wtap would essentially match 1:1 with the amount of data dissected in the tree
*not* what is currently shown in the hex display (ignoring reassembly and
generated fields for a moment here). In this model I believe the packet-frame
dissector would display the generic wireshark level metadata and the actual
entire block/record could be dissected and displayed in the tree, including ERF
record and possibly even PCAPNG block pseudoheaders.
An alternative option, which I think you are also suggesting here is to keep
the pseudoheaders as separate (tvb?) buffers and dissect those independently of
the 'payload', e.g. the ERF dissector would inspect the 'ERF header'
pseudoheader tvb and the 'extension header' pseudoheader (maybe an optionblock)
and then pass the 'payload' tvb to the next layer, essentially replacing the
existing phdr union with one or more buffers. In this case caplen and described
in this RFC would no longer match outer tvb available length, and phdr_len
wouldn't be meaningful in fixing that. With this approach we probably wouldn't
need to record phdr_len at all? I'm also not sure it effectively solves the
problem of multiple layers of encapsulation at different places in the packet
(e.g. tunnelling ERF inside Ethernet). Wtap would likely need to know where all
the layers of pseudoheader were.
> > 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.
Yes, that's what I meant. Assuming caplen include phdr_len, caplen-phdr_len <=
len should be sensible.
>
> > 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?
I was thinking specifically of wtap_fts_rec currently (theoretically) used for
filetype specific non-packet records. I hadn't realised wtap_encap was a
specific dissector table so maybe as-is makes sense.
You are receiving this mail because:
- You are watching all bug changes.
