Currently Wireshark limits the Access Point Name length to 50 bytes. But
according to 3GPP 24.008 chapter 10.5.6.1, the maximum length is 100 bytes (102
bytes minus the IEI and length fields) and not 50.
The attached patch increases the MAX_APN_LENGTH define value and allow the
correct display of an APN with a size greater than 50 bytes.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6628
svn path=/trunk/; revision=40044
Add this new ID in GRE dissector
The frame with the new GRE ID is not 802.11 frame such as 80XX GRE ID but a 802.3 frame with curious ethertype (8211 the same id with PAPI Protocol...)
svn path=/trunk/; revision=40039
corba dissector generator improvement
Patch 2 : create a defaulf field hf_operationrequest which provides the requested operation on both the resquest and the reply messages.
From me :
Regenerate GIOP Plugins
svn path=/trunk/; revision=40038
corba dissector generator improvement
Patch 1 : field names is used in dissection instead of "enum value" which is not clear
From me :
Regenerate GIOP Plugins
svn path=/trunk/; revision=40037
For now use Jeff's fix:
"The REAL problem is that the GSM_MAP dissector is using this value_string_ext
in the hf without BASE_EXT_STRING:
{ &hf_gsm_old_localValue,
{ "localValue", "gsm_old.localValue",
FT_INT32, BASE_DEC, &gsm_old_GSMMAPOperationLocalvalue_vals_ext, 0,
"OperationLocalvalue", HFILL }},
This, in turn, appears to be caused because OperationLocalValue is an alias
for/of GSMMAPOperationLocalValue and only the latter is defined with
.USE_VALS_EXT.
I can fix it by doing:
Index: asn1/gsm_map/gsm_map.cnf
===================================================================
--- asn1/gsm_map/gsm_map.cnf (revision 39628)
+++ asn1/gsm_map/gsm_map.cnf (working copy)
@@ -54,6 +54,7 @@
#.USE_VALS_EXT
GSMMAPOperationLocalvalue
+OperationLocalvalue
#.EXPORTS
AddressString
But it seems to be that asn2wrs should arguably be figuring this out on its
own."
svn path=/trunk/; revision=40033
Part of patch:
2. BFD extension has been added as per RFC 6428, to decode the BFD packet with
ACH encapsulation(without IP/UDP header encapsulation). The channel type in ACH
header identifies the BFD payload as BFD CC or CV packet. Also decoding for
MPLS-TP source MEP-ID TLV in BFD CV packet has been added.
applied with a change to add packet-bfd.h
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6610#add_comment
svn path=/trunk/; revision=40029
LSP Ping extension has been added as per RFC 6426, to decode the LSP Ping
packet with ACH encapsulation(without IP/UDP header encapsulation). The channel
type in ACH header identifies the LSP Ping packet. Also support for decoding
new TLVs and Sub-TLVs defined in the RFC 6426 has been provided.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6610#add_comment
svn path=/trunk/; revision=40028
BFD extension has been added as per RFC 6428, to decode the BFD packet with
ACH encapsulation(without IP/UDP header encapsulation). The channel type in ACH
header identifies the BFD payload as BFD CC or CV packet. Also decoding for
MPLS-TP source MEP-ID TLV in BFD CV packet has been added.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6610#add_comment
svn path=/trunk/; revision=40027
- Removed some mpls preferences which are no longer relevant/needed like
decode PWAC payloads as PPP traffic and assume all channel types except 0x21
are raw BFD.
- MPLS extension from PW-ACH to MPLS Generic Associated Channel as per RFC 5586
- Updated Pseudowire Associated Channel Types as per
http://www.iana.org/assignments/pwe3-parameters
- Updated the VCCV bitmaps as per RFC 5885
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6574
svn path=/trunk/; revision=40026
Strictly speaking, it appears that __except(EXCEPTION_EXECUTE_HANDLER)
rather than __exept(TRUE) should be used altho in actuality there's
no difference since TRUE (as defined by GLIB) == EXCEPTION_EXECUTE_HANDLER.
svn path=/trunk/; revision=40022
- Remove unneeded #includes;
- Use val_to_str_const() in several places;
- Reformat long lines;
- Fix whitepace and indentation.
svn path=/trunk/; revision=40016
kNet (KristalliNet) dissector for Wireshark
kNet is a connection-oriented network protocol for transmitting arbitrary application-specific messages between network hosts. It is designed primarily for applications that require a method for rapid space-efficient real-time communication. kNet is an application-level protocol which can be ran either over UDP, TCP or SCTP transports.
From me :
* Add Modelines information and fix trailing whitespace
* Merge packet-knet.h in packet-knet.c
* Make Checkhf happy
* Fix Clang/GCC Warning about unused variable
* Add Authors info & CMakeList.txt
svn path=/trunk/; revision=40010
Chris Maynard