Only count the number of items in the SEQUENCE OF IFF we have the full TVB containing the entire blob.
Dont count the items if the tvb is "short" since then this would just lead to a [short frame] before a single item in the SEQUENCE OF has been dissected.
Do we really need to count the items and create a FT_UINT field with the number of items at all?
Then count the items as we are calling the subdissectors and
append the '# item[s]' text to the FT_NONE items after we finished the loop?
svn path=/trunk/; revision=15607
1. Use the new (good work!) 'nanosec' precision only for gig pods;
2. Rework 'struct netxray_hdr' to make it (somewhat) easier
to maintain and revise:
a. Declare known hdr fields such as 'captype' instead
of using offsets in 'xxx placeholder' fields.
d. Define 'unknown' hdr fields using placeholder names
based upon hex-offset in the netxray header record.
(This isn't perfect, but I hope it will make things
more manageable).
3. Update hdr field info (based upon examination of various
capture files):
a. Define a hdr field which appears to be 'time-zone'
[offset in hours from UTC] for the machine doing
the capture.
(Maybe this field can eventually be used for Ethereal
to display the (local) time as it was at the time
of the capture).
b. Describe certain hdr fields as being "file offsets"
(altho the exact use is still unclear).
Update some comments.
svn path=/trunk/; revision=15603
b) dissect_ber_set() to report missing fields and handle untagged CHOICEs
c) dissect_ber_choice() to handle untagged CHOICEs (within the CHOICE)
svn path=/trunk/; revision=15597
desired reported length and the remaining length, so we don't throw an
exception at tvbuff creation time if we don't have all the desired data
- we want to throw the exception at dissection time, so we can dissect
the data we do have.
Use "tvb_ensure_bytes_exist()" to force exceptions to be thrown.
When "dissect_unknown_ber()" is called from "call_ber_oid_callback()",
we're handing it a newly-created tvbuff, so the offset in that tvbuff
should be zero.
svn path=/trunk/; revision=15595
structure. Handle that.
Don't muck with the columns, or put a top-level Kerberos protocol item
into the protocol tree, until we decide that we really have a Kerberos
packet.
Do, however, clear the Info column if we're dissecting the Kerberos
protocol.
svn path=/trunk/; revision=15590
structure. Handle that.
Don't muck with the columns, or put a top-level Kerberos protocol item
into the protocol tree, until we decide that we really have a Kerberos
packet.
Do, however, clear the Info column if we're dissecting the Kerberos
protocol.
svn path=/trunk/; revision=15589
* I couldn't find any documentation on this protocol. Neither
* what it's good for nor what the elements do. This is purely
* reverse engineered by looking at the hex dump of the packets.
*
* TODO
* - Find out more about unknown fields
* - Currently only one type of packet is really handled at all
svn path=/trunk/; revision=15562
