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
acl chandle + direction + l2cap-CID to uniquely identify a single specific
flow of PDU packets.
So we need to pass the chandle upp from acl to l2cap at least.
It would have been nice to handle this using "conversations" but the bluetooth
stack does not eaily map to the idiom host:port<->host:port
instead in bluetooth you have unidirectional flows that are identified by ACL-chandle:L2CAP-CID:direction and additional state held inside l2cap would attach two such flows together into a "conversation".
Bluetooth packets themself only indentify "half" of the two way conversation.
svn path=/trunk/; revision=18218
The UMA-message Handover From UMAN Command includes the complete L3-message (and header) and not only the handover-IE's.
svn path=/trunk/; revision=18215
- Many DCT2000 protocols can be embedded within an IP primitive
message. Add a heuristic to see if we can find the protocol payload
within in IP primitive message, and look for an ethereal dissector
matching the DCT2000 protocol name (this is useful for simple protocol
testing where no physical links are involved)
- Make some more of these protocols (diameter, http, mgcp) findable by name
- Adds protocol 'variant' number to stub and dissector
- Break the duplicated writing of the stub header out into a separate
function
svn path=/trunk/; revision=18212
Gerald Combs