Also (for a few files):
- create/use some extended value strings;
- remove unneeded #include files;
- remove unneeded variable initialization;
- re-order fcns slightly so prefs_reg_handoff...() at end, etc
svn path=/trunk/; revision=44438
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_OID
Note: Encoding field set to ENC_NA only if the field was previously TRUE|FALSE|ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN
svn path=/trunk/; revision=39260
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224
(1) Trailing/leading spaces are removed from 'name's/'blurb's
(2) Duplicate 'blurb's are replaced with NULL
(3) Empty ("") 'blurb's are replaced with NULL
(4) BASE_NONE, NULL, 0x0 are used for 'display', 'strings' and 'bitmask' fields
for FT_NONE, FT_BYTES, FT_IPv4, FT_IPv6, FT_ABSOLUTE_TIME, FT_RELATIVE_TIME,
FT_PROTOCOL, FT_STRING and FT_STRINGZ field types
(5) Only allow non-zero value for 'display' if 'bitmask' is non-zero
svn path=/trunk/; revision=28770
RR has been split from DTAP, with common stuff going to the common files (plus a few minor knock-on consequences).
Fix the broken tap:
I had not realised that the register_tap call in the dissector registration actually _created_ the tap entry (not the register_tap_listener), and not just associated the tap_id returned with the tap registered by the listener. The use of separate statics by the split lead to 3 taps called "gsm_a", but only the first of which was ever found in the tap_queue_packet. Added (yet another) global for now to cope.
Also attached is a patch to tap.c which simply returns the same tap_id if the register_tap is called twice with the same name - I can't see any downside to this, can you? Anyway it seemed to work with deliberately keeping multiple calls.
svn path=/trunk/; revision=26039
--enable-extra-gcc-checks set.
If we turn on -pedantic, try turning on -Wno-long-long as well, so that
it's not *so* pedantic that it rejects the 64-bit integral data types
that we explicitly require.
Constify a bunch of stuff, and make some other changes, to get rid of
warnings.
Clean up some indentation.
svn path=/trunk/; revision=21526
most have been tagged unused (few have been deleted if dissector has not been
modified since a long time)
move packet-ssl-utils.c to DISSECTOR_SRC
svn path=/trunk/; revision=21431
Add a table of DPCs and SSNs that allow to override the protocol that would be choosen
so that the same SSN can use two different protocols in two different DPCs.
I did not believe it someone could have done it, then I saw the captures...
svn path=/trunk/; revision=21321
* add SUA to the "VoIP Calls" tap.
* propagate changes to packet-sccp.h to other dissectors
From Neil Piercy:
* add SLR, DLR and CAUSE to COL_INFO
svn path=/trunk/; revision=21126
add sccp_info to struct _packet_info (Sorry but the way private_data works and the fact that TCAP uses it and BSSAP/RANAP can be tunnelled on GSMMAP over TCAP makes it impossible to avoid)
SCCP
- Have SCCP to have a TAP,
- Fix associations so that every message belongs to the association.
- Export message type values so that they can be used by a tap listener
RANAP
- Have RANAP information attached to the sccp_info
BSSAP + GSM_A
- Have DTAP, BSSMAP and BSSAP info attached to the sccp_info
svn path=/trunk/; revision=21076
I found a rare situation in which the BSSAP dissector seems to wrongly
assume a packet.
When a RANAP DirectTransfer message contains the GSM Supplementary
Service 'Call Confirmed' this seems to yield a message that the BSSAP
dissector recognizes as a BSSMAP BLOCK message (and from the perspective
of BSSAP, this is perfectly correct).
My patch includes code that checks this very special case.
svn path=/trunk/; revision=20520
Jakub Zawadzki