Ensure that ALL response PDUs are displayed, and the corresponding description text for the reserved or vendor-specific error code is displayed.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6108
svn path=/trunk/; revision=40848
Since SMPP knows the time zone of its (absolute) times and since we don't
have access to a mktime() routine that doesn't take into account the local
time zone (and since I don't think repeatedly setting the TZ environment
variable is a healthy choice):
1) subtract the 'timezone' (or '_timezone' on Windows) back out after calling
mktime()
2) then adjust the time to take into the protocol-specified time zone
3) and (finally) display the time in UTC (since we don't have the
infrastructure to display it in the protocol-specified time zone).
(I *think* (1) is portable: POSIX says that variable should exist...)
svn path=/trunk/; revision=40742
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
proto_tree_add_*(): just use proto_tree_add_item().
Replace some tvb_get_ptr()s with tvb_get_ephemeral_string() or
tvb_get_const_stringz().
Use tvb_memeql() & tvb_memcmp().
svn path=/trunk/; revision=35558
ABSOLUTE_TIME_LOCAL or ABSOLUTE_TIME_UTC, indicating whether to display
the date/time in local time or UTC. (int)ABSOLUTE_TIME_LOCAL ==
(int)BASE_NONE, so there's no source or binary compatiblity issue,
although we might want to eliminate BASE_NONE at some point and have the
BASE_ values used with integral types start at 0, so that you can't
specify BASE_NONE for an integral field.
svn path=/trunk/; revision=31319
(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
a protocol tree;
the column values.
This includes stats-tree listeners.
Have the routines to build the packet list, and to retap packets, honor
those requirements. This means that cf_retap_packets() no longer needs
an argument to specify whether to construct the column values or not, so
get rid of that argument.
This also means that there's no need for a tap to have a fake filter
to ensure that the protocol tree will be built, so don't set up a fake
"frame" filter.
While we're at it, clean up some cases where "no filter" was represented
as a null string rather than a null pointer.
Have a routine to return an indication of the number of tap listeners
with filters; use that rather than the global num_tap_filters.
Clean up some indentation and some gboolean vs. gint items.
svn path=/trunk/; revision=28645
"I have chosen _not_ to use the value_string array in the header field for the
tag because the information appears in too many places - once in the sub-tree
and again once in the field which displays the value. Displaying the tag name
again in the tag field would make the same information appear three times in
four lines."
See Bug #3369 [https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3369]
From me: Use consistent indentation throughout packet-smpp.c
svn path=/trunk/; revision=27922
There was an ugly hack while creating the menu, that tried to detect the stat_group a stats_tree belongs to by looking at the name string. That makes it unnecessarily hard to understand how the menu is really created.
Fix: Add a new function stats_tree_register_with_group() that takes the stat_group as a parameter. Use this function where a stats_tree doesn't fit into the default "unsorted" group.
svn path=/trunk/; revision=27407
The SMPP optional parameter 'network_error_code' is decoded incorrectly. This field is
present in SMPP (v3.4 and higher) deliver_sm messages containing a delivery notification.
This TLV contains 3 bytes of data, which is decoded in two steps, each adjusting the
offset in the message. After that the offset is increased *again*, causing the next
TLVs to not recognised. Removing the indicated increase in offset fixes the problem.
svn path=/trunk/; revision=27177
The SMPP dissector currently supports only version 3.4. The latest version of
the protocol is version 5.0 and it has been around for a while. However, the
usage of this version of the protocol is only now picking up.
This patch adds basic support for SMPP 5.0. By basic I mean:
- New Operations and Responses.
- New TLVs.
- New Error codes.
- Any changes to earlier values.
svn path=/trunk/; revision=25787
there are many reasons why some protocols actually need to be able to access the pinfo structure while determining the pdu size
svn path=/trunk/; revision=19751
Here is a patch for gsm_map dissector that adds USSD string decoding (mainly used in processUnstructuredSS-Request, UnstructuredSS-Request, UnstructuredSS-Notify). For now, it assumes that it will be GSM 7 bits.
It re-use packet-gsm_sms.c "gsm_sms_char_7bit_unpack" and "gsm_sms_char_ascii_decode" functions, as well as packet-smpp.c "smpp_handle_dcs" function.
svn path=/trunk/; revision=17739
I've changed all settings I could find to TRUE. It might be reasonable to change some protocol settings back to FALSE, if reassembling fails very often.
svn path=/trunk/; revision=16048
Anders Broman