Change the name of the Windows package to "wireshark-setup-..." Other
Ethereal -> Wireshark updates.
We _really_ need a better Wireshark icon.
svn path=/trunk/; revision=18253
- shows profile-specific extension data at the end of SR/RR reports (if
packet length has not yet been reached after parsing normal data) and
advances offset (further packets were not recognised+dissected as this
data wasn't being skipped).
svn path=/trunk/; revision=18245
This version of the patch won't look for the authentication scheme (it
just skips that part for Authentication-Info headers). I tested it
using the enclosed file (pasted from the RFC and fed through
od/text2pcap, then messed around with so I could test the other new
parameters, even if they don't really belong in that header...).
svn path=/trunk/; revision=18244
- h245.asn renamed to MULTIMEDIA-SYSTEM-CONTROL.asn
- rollback changes in .asn sources to keep them in original ITU-T form and put necessary changes into .cnf files
- PER dissectors regenerated
svn path=/trunk/; revision=18238
- new directive #.SET_TYPE - enforce type for field
- T_... name is based on renamed field (if present) instead of original one
- report unused #.FN_HDR, #.FN_BODY, #.FN_FTR
- new directive #.TF_RENAME - renames type and field together
(example of usage will follow in H225 and H245 dissectors)
svn path=/trunk/; revision=18237
While in 3GPP spec, the last two (Down/up nextPDCP-PDU seq. no.) would be 2
BYTES. So ethreal could not read the message correctly. We have to modify the
log to make Ethreal analysis it.
Add disection of TargetID.
svn path=/trunk/; revision=18228
doing the reassembly internally in acl instead of calling reassembly.c since the fragmentation is so simple and packets are so small anyway so full reassembly.c support would be overkill.
svn path=/trunk/; revision=18223
this dissector will not yet detect when ppp is passed over the rfcomm link
but the old code to detect and deescapt the ppp data is still in the dissector, though ifdeffed out to serve as inspiration when ppp over rfcomm captures are made available.
the only captures i have with rfcomm are for raw serial communications so they dont contain any ppp frames. :-(
svn path=/trunk/; revision=18221
higher layer protocols need the chandle, cid and direction (from pinfo) in order to identify packets for the same "conversation"
(it is not a conversation per se in bluetooth butn one unidirectional flow that we track)
svn path=/trunk/; revision=18220
Gerald Combs