Added option "ANSI MAP" in Preferences menu, that ansi_map protocol dissector can parse packets with non-standart SSN.
svn path=/trunk/; revision=18358
- 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).
- checks that the length of the RTCP data in the whole frame matches the
combined length from the length fields (the last check in RFC 3550, "A.2
RTCP Header Validity Checks") with a generated field and expert info
when wrong.
- reports the length field in all of the message types consistently (the
length was confusingly shown multiplied by 4 only in APP packets...)
svn path=/trunk/; revision=18357
- while parsing fmtp lines, the dissector looks for the MPEG4 'profile-level-id' parameter. If there is no '=' present, it was throwing an exception and the frame marked as malformed (see e.g. the attached
capture)
- I've added a few comments where the code wasn't obvious to me...
svn path=/trunk/; revision=18332
Q.931:I
mprovesthe dissection of Q.931 Channel
Identification information elements, by using proper (filterable) header
fields rather than text tree items.
H253:
make the h.263 dissector dissect the group-of-block
number which comes after a GOB start code.
svn path=/trunk/; revision=18323
H225.cnf
I noticed is that the voip call flow graph does not have a label for the setupAck packet. I traced this to the empty frame_label.
voip_calls.c
It seems to me that in gtk/voip_calls.c tmp_h323info->guid is pointer itself, therefore:
memcmp(&tmp_h323info->guid
should in fact read:
memcmp(tmp_h323info->guid
svn path=/trunk/; revision=18304
if the interval spans the entire 32 bit range.
special case the two common cases when this may happen until a real fix is included.
if the range variable becomes 0 due to 32bit overflow do a g_assert_not_reached to prevent an infinite loop.
this function should be enhanced to work with 64 bit integers.
svn path=/trunk/; revision=18299
- 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
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
- step to new ASN.1 API - pass asn_ctx_t* through PER dissectors instead of packet_info*
- PER ALIGNED/UNALIGNED flag moved to asn_ctx_t
- PER created tree item pointer moved to asn_ctx_t
- add nbap into PER dissectors in asn1/Makefile.nmake
- use add_oid_str_name() instead of register_ber_oid_name() in H.225 and H.245
- export asn_ctx_init from library
- PER dissectors regenerated
svn path=/trunk/; revision=18209
Anders Broman