Re: [Wireshark-dev] Patches for gsm-packet_sms dissector
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Willem Dekker Skickat: den 2 juli 2006 23:07 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Patches for gsm-packet_sms dissector Dear wireshark developers, After running same test trace files I noticed a lot of non-utf8 error messages from wireshark. The attached patch fixes this and converts the sms content (7 bit encoded, gms 03.38 alphabet) into utf8. The only difficutily I had is how to handle the platforms without a glib 2 library (windows? / older unix versions). I made some code for this, but have not tested this. Attached are is a patch to packet-gsm_sms.c (unified diff to the latest wireshark source tar files). If desired I can send a trace file exhibiting the problem. Regards, Willem Dekker ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] to voip_calls.c (bug 892 again)
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Martin Mathieson Skickat: den 4 juli 2006 11:49 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] [Patch] to voip_calls.c (bug 892 again) This time with patch attached Hi, Mike Oliveras has indicated that for MGCP voip calls, 2 seconds may be a better timeout for still matching DLCX requests to a hung-up endpoint, as in this patch. Regards, Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] More Diameter [patches]
Chjecked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Martin Mathieson Skickat: den 14 juli 2006 16:21 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] More Diameter [patches] Hi, These patches - add a few more chargecontrol AVPs, and add the vendor-id where needed - report as expert info when AVPs' lengths don't match their type Regards, Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] to MSRP dissector
Checked in.
Brg
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Martin Mathieson
Skickat: den 19 juli 2006 15:50
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] [Patch] to MSRP dissector
Joerg Mayer wrote:
On Wed, Jul 19, 2006 at 11:52:43AM +0100, Martin Mathieson wrote:
This patch:
- adds headers found in later versions of the msrp drafts
- fixes a problem where wrong length values were used while parsing the
request/status line and it was going beyond linelen
- Transaktion - Transaction
- status code now appears as a numerical field
- removes unused parameters from check_msrp_header()
- tidies up some indentation
It has survived some fuzz-testing.
Does anyone have a capture file that includes SDP setup traffic? If I
can see it I'll add setting up of the MSRP conversation.
Hmm, I'm wondering about the following piece of code:
+ while (tvb_offset_exists(tvb, offset)) {
+ tvb_find_line_end(tvb, offset, -1, next_offset, FALSE);
+ linelen = next_offset - offset;
...
+ offset = next_offset;
+ }
+}
if tvb_find_line_end returns -1, then next_offset will not be modified,
so if the first run returns a valid value and a later iteration fails,
then this loop might run endless? (Just reading code and docs, no
personal experience with this function).
Ciao
Joerg
I think this is OK, since the last parameter ('desegment') to
tvb_find_line_end() is FALSE, meaning that if no line-end is found it
will set next_offset past the end of the buffer, which means the test is
bound to fail next time around the loop. I've attached a second patch
though with comments explaining this added and a fix for the strange
indentation above.
Regards,
Martin
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] New DTD (xcap-caps)
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Martin Mathieson Skickat: den 19 juli 2006 18:12 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] New DTD (xcap-caps) Hi, Here is a DTD for xcap-caps and changes needed to install it (nsi change is untested). Regards, Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] Tracking setup of MSRP conversations
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Martin Mathieson Skickat: den 24 juli 2006 18:12 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] [Patch] Tracking setup of MSRP conversations Hi, These patches: - allow SDP to parse the IP address + port for the MSRP session from the path attribute - setup an MSRP conversation using this address, whose data points back to the SDP frame - link to the SDP setup frame while dissecting MSRP (can be switched off by a preference) - I also changed sdp.media.port to be a numeric field Best regards, Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] New packet disassembly module
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Sean Sheedy Skickat: den 14 juli 2006 22:35 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] New packet disassembly module Attached is a packet disassembly module I wrote for Pegasus Lightweight Stream Control, a protocol used by some cable set-top boxes for video-on-demand. I would appreciate it being added to the source base. Thanks. Sean -- Sean Sheedy [EMAIL PROTECTED] ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] New Plugin - Pro-MPEG Code of Practice #3 release 2FEC Protocol
Hi, Could you please add licence information to the file and make it a normal dissector not a plugin. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Mark Lewis Skickat: den 21 juni 2006 12:12 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] New Plugin - Pro-MPEG Code of Practice #3 release 2FEC Protocol Hi, I have developed a plugin for Pro-MPEG FEC packets over RTP (see previous posts on ethereal-dev). I have added a page and example capture file to the Wiki (http://wiki.wireshark.org/2dParityFEC). The source and Windows makefile for the plugin are attached. Unfortunately I do not have access to other systems so this plugin has been tested on Windows only. The attached files are from plugins/2dparityfec. Cheers, Mark ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch to conversation.c
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Peter Johansson Skickat: den 31 juli 2006 17:51 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Patch to conversation.c Hi, the supplied patch fixes a problem where the options value should really be used from the conversation found (using conversation_lookup_hashtable(...) to create a new conversation based on the already stored conversation template (the CONVERSATION_TEMPLATE bit is set in the stored conversation) rather from the options argument passed to the function(s). This solves a problem that otherwise shows itself where DISSECTOR_ASSERT(!(conv-options CONVERSATION_TEMPLATE) Use the conversation_create_from_template function when the CONVERSATION_TEMPLATE bit is set in the options mask); fails sometimes. / Regards, Peter ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [patch] capture_sync.c cosmetics
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 26 juli 2006 15:29 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] [patch] capture_sync.c cosmetics This patch fixes a couple of comments in capture_sync.c. -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] clopts test fix
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 26 juli 2006 15:33 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] clopts test fix An error message has been changed, such that the commandline options test doesn't work any more. This patch fixes the test accordingly. -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Ideas regarding bug 1025?
Hi, The GTK and Glib packages where obtained from: http://www.gimp.org/~tml/gimp/win32/downloads.html it might be worth trying a newer version to see if the problem has been resolved (or check the release notes). Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Neil Piercy Skickat: den 10 augusti 2006 20:01 Till: Joerg Mayer Kopia: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Ideas regarding bug 1025? Joerg Mayer wrote: OK, I've created a small testprogram (under Suse 10.1) which you should compile as similar as possible to the way you compile Wireshark. Let's see whether it crashes and if so, where. I hope the program doesn't much tweaking to compile on W32. Worse than you feared: it crashes on test2 (in exactly the same manner as the whole wireshark app does with the test capture, so the test looks valid) - i.e. as soon as the upper 32 bits are non-zero. I'm trying to build a debug version of the glib-2.6.6 from original source, but its a bit painful - does anyone know the exact source (including config) that the distributed glib dll was built from ? Neil ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] FW: Listen_rtp plugin
Hi, Checked in. The patch didn't apply cleanly so it's partly applied by hand please review it again. I also had to add #ifdef PORTAUDIO_DIR reset_rtp_player(); #endif and #ifdef PORTAUDIO_DIR add_rtp_packet(pi, pinfo); #endif In voip_calls.c to make it compile without the library. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Alejandro Vaquero Skickat: den 30 augusti 2006 20:35 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] FW: Listen_rtp plugin Here is a new patch with the following changes: - Change the listen_rtp to rtp_player - Change from a plugin to be part of the core - By default it will not compile with the rtp_player. In order to compile it is necessary to: + For windows: uncomment the line PORTAUDIO_DIR=$(WIRESHARK_LIBS)\portaudio_v18_1 in config.nmake + For linux: using the --with-portaudio=yes - The current /plugin/listen_rtp directory should be removed from the source It'll be good if someone can review all the make files staff to see if I did that correctly (I tested with and without the compile options in Windows and Fedora Core 4). Regards Alejandro Jacques, Olivier (OpenCall Test Infra) wrote: Anders Broman (AL/EAB) wrote: Alejandro I think your proposed plugin looks realy good and something we would have use for. From the recent mails I'm a bit confused to where we stand on this. I think Guy had some comments on the implementation, is that beeing worked on or is further discussions needed? I have a version that builds on OS X (not as a plugin) without doing any type-casting of function pointers. I couldn't test it with one capture, though, as it appears to expect that the RTP packets carrying the voice part of the call (as opposed to the signaling part of the call) are part of the call as displayed by the graph of the call - but that's not the case with the H.323 call in the capture. Is the intent that voice packets be part of the call, or not? Guy, are you awaiting an answer from Alejandro? What prevents the inclusion (or enablement) of listen_rtp now that we have just passed a Wireshark release? Thanks, Olivier. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Add Camel GPRS reference decoding
Checked in with debug code removed. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 31 augusti 2006 11:22 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Add Camel GPRS reference decoding Hi, Here is a patch to implement the decoding of the GPRS reference. The specific oid for the CAP-GPRS-ReferenceNumber is attached to a decoding function in the camel module. I do not know if this is the standart method to proceed or if it should be made in the ASN1 definition ?? Moreover, I did move the register_ber_oid_dissector_handle in proto_reg_handoff_camel function, to be sure that the camel_handle is initialized. (See attached file: packet-camel-template.c.diff.gz)(See attached file: camel_gprs_reference.rf5.gz) Regards Florent ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] A question about debug using DDD
Hi, You need to add packet-chlip.c and packet-chlip.h to makefile.common in epan\dissectors... Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För patrick Skickat: den 5 september 2006 08:23 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] A question about debug using DDD Hello, I have a question about wireshark debug. I want to add a new dissector in wireshark. After python compile, I added new packet-chlip.c and packet-chlip.h file in epan\dissectors，then I make it. When debug using DDD, I cannot find these packet-chlip.c and packet-chlip.h file in epan\dissectors, and cannot set a break. Is there anything wrong? Thanks Best Regards Patrick ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] query regarding gtp_handlefuntionanddecoderfunction.
Hi,
What you probably want to do is to change the current code to something
like:
static int
decode_gtp_priv_ext(tvbuff_t *tvb, int offset, packet_info *pinfo _U_,
proto_tree *tree) {
guint16 length, ext_id;
proto_tree *ext_tree_priv_ext;
proto_item *te;
tvbuff_t *new_tvb;
te = proto_tree_add_text(tree, tvb, offset, 1,
val_to_str(GTP_EXT_PRIV_EXT, gtp_val, Unknown message));
ext_tree_priv_ext = proto_item_add_subtree(te, ett_gtp_ext);
offset++;
length = tvb_get_ntohs(tvb, offset);
proto_tree_add_item(ext_tree_priv_ext, hf_gtp_ext_length, tvb,
offset, 2, FALSE);
offset = offset+2;
if (length = 2) {
ext_id = tvb_get_ntohs(tvb, offset);
proto_tree_add_uint(ext_tree_priv_ext, hf_gtp_ext_id, tvb,
offset, 2, ext_id);
offset = offset+2;
/*
* XXX - is this always a text string? Or should it be
* displayed as hex data?
*/
if (length 2)
proto_tree_add_item(ext_tree_priv_ext,
hf_gtp_ext_val, tvb, offset, length-2, FALSE);
switch (ext_id){
case MY_MANUFACTURER_ID:
new_tvb = tvb_new_subset(tvb, offset, length-2,
length-2);
dissect_private_ext_manufacturer_id(new_twb, pinfo,
ext_tree_priv_ext)
break;
default:
break;
}
}
return 3+length;
}
Brg
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För prashanth joshi
Skickat: den 6 september 2006 22:52
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] query regarding
gtp_handlefuntionanddecoderfunction.
Hi Anders,
how r u...
I have a query Anders.
If we consider for example the following statement,
proto_tree_add_item(ext_tree_priv_ext, hf_gtp_ext_val, tvb, offset+5,
length-2, FALSE);
So length-2 bytes of data is added in to tree ,starting from the location
number ofset + 5 of tvb.
My query is : is it absolutely necessary to have hf_gtp_ext_
as the second argument when ever we want to add an item?
Can not we do away with it by having a NULL as second argument instead? ( I
found it difficult to understand how the contents of the proto_register_gtp
array are built)
And what would be the limitations if we try to add an item using the
proto_tree_add_text( ) instead ?
regards,
Prashanth
Anders Broman (AL/EAB) [EMAIL PROTECTED] wrote:
Hi,
The function val_to_str(GTP_EXT_RAI, gtp_val, Unknown message));
searches the svalue_string gtp-val for a match to GTP_EXT_RAI and if found
returns the matching string, in this case
Routing Area Identity if no match is found it will print Unknown
message.
Best regards
Anders
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of prashanth joshi
Sent: den 6 september 2006 09:25
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] query regarding gtp_handle
funtionanddecoderfunction.
Hi Anders, thanks.
Now the things are much clearer. Now i understand why the return value from
the decoder function is 3 + length.
But yeah in val_to_str(GTP_EXT_XXX, gtp_val, UNKNOWN) , is the string
UNKNOWN concatenated with GTP_EXT_XXX and returned ?
regards,
Prashanth.
Anders Broman (AL/EAB) [EMAIL PROTECTED] wrote:
Hi,
Are you trying to add something thats defined in 3GPP TS 29.060 or to do
someting for a nonstandard extension to the protocol?
( 0x7F is also allready used (define GTP_EXT_CHRG_ID 0x7F)).
The code:
while (gtpopt[++i].optcode)
if (gtpopt[i].optcode == ext_hdr_val)
break;
offset = offset + (*gtpopt[i].decode)(tvb, offset, pinfo, gtp_tree);
Will call the function pointed out by the Extension type (GTP_EXT_XXX) with
a tvb containing the GTP message and the offset parameter pointing to the
Extension type
(octet 1 in the IE descriptions of TS 29.060)
in the function you'll have to increase offset to pont to the byte you want
to access.
Best regards
Anders
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of prashanth joshi
Sent: den 5 september 2006 17:35
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] query regarding gtp_handle funtion
anddecoderfunction.
Hi Anders,
Thanks for the reply.
But I'm affraid i did not put the whole thing very clearly.
I should have been more specific.
Actually i need to have in the define statement the following :
#define GTP_EXT_XXX 0x7f /* Satement 1 */
and then the ( extension field , function pointer) pair :
( GTP_EXT_XXX My_decode_fun) /* Statement 2 */
And then
I need to check whether the value of the next byte is 0x30 , in the
My_decode_fun(...),
and then call decode_XXX(...) function. /* Statement 3 */
Now in decode_XXX(...) function shall i include the same code
Re: [Wireshark-dev] Need info of recently added: GNUTLS, KFW, NETTLE, LUA and PortAudio for the Devel Guide and elsewhere
I will move relevant stuff from readme.win32 (unmaintained) to the Devel Guide and remove the devel part completely when I find some time. I'd just add a note that it's not maintained and point to the Devel. Guide For an up to date description... Best regards Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] IPFIX
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Andrew Feren Skickat: den 12 september 2006 20:19 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] [Patch] IPFIX This is a repost from April 2006. The original messages was From: Luca Deri [EMAIL PROTECTED] Date: Thu, 20 Apr 2006 11:29:51 +0200 Dear all, please find enclosed a patch to the CFlow dissector (packet-netflow.c) that enables it to decode IPFIX packet traces. Regards, Luca The original patch was 90+% whitespace diffs so it was never added. I was looking for IPFIX support so I applied the patch and then backed out the whitespace changes. Here is a new patch without any (or at least few) whitespace changes. This is definately not complete IPFIX support. Looks like all it does is identify the protocol as CFLOW/IPFIX and correctly identify the number of data records. I may flesh this out soon, but for now here are Luca's original changes. -Andrew -Andrew Feren [EMAIL PROTECTED] ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch to packet-tcp.h
Hi, The last time this was asked it was answered: http://www.ethereal.com/lists/ethereal-dev/200604/msg00097.html Hi, There doesn't seem to be a coding rule within the Ethereal code base that states that a header file itself must include the header files it depends on. If it is we have a whole lot of work to do... Thanx, Jaap On Tue, 11 Apr 2006, Thomas Boehne wrote: My dissector includes packet-tcp.h, which uses se_tree_t from emem.h without including it. Could someone please add an #include epan/emem.h to packet-tcp.h? Or is there a special reason for not including it? Regards, Thomas Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Peter Johansson Skickat: den 20 september 2006 11:14 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] Patch to packet-tcp.h This is a resend of a patch I sent September 8th, it seems to have been misplaced somwhere ;) / Regards, Peter ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Fwd: And again BER errorswhiledecodingH248packets
Hi, From below it looks like a SEQUENCE may NOT be coded as a Zero item but SEQUENCE OF may. Comments? ITU-T Recommendation X.690 International Standard 8825-1 Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) For SEQUENCE it says: 8.9 Encoding of a sequence value 8.9.1 The encoding of a sequence value shall be constructed. 8.9.2 The contents octets shall consist of the complete encoding of one data value from each of the types listed in the ASN.1 definition of the sequence type, in the order of their appearance in the definition, unless the type was referenced with the keyword OPTIONAL or the keyword DEFAULT. 8.9.3 The encoding of a data value may, but need not, be present for a type which was referenced with the keyword OPTIONAL or the keyword DEFAULT. If present, it shall appear in the encoding at the point corresponding to the appearance of the type in the ASN.1 definition. For SEQUENCE OF it says: 8.10Encoding of a sequence-of value 8.10.1 The encoding of a sequence-of value shall be constructed. 8.10.2 The contents octets shall consist of zero, one or more complete encodings of data values from the type listed in the ASN.1 definition. 8.10.3 The order of the encodings of the data values shall be the same as the order of the data values in the sequence of value to be encoded. And the length encoding: 8.1.3 Length octets 8.1.3.1 Two forms of length octets are specified. These are: a) the definite form (see 8.1.3.3); and b) the indefinite form (see 8.1.3.6). 8.1.3.2 A sender shall: a) use the definite form (see 8.1.3.3) if the encoding is primitive; b) use either the definite form (see 8.1.3.3) or the indefinite form (see 8.1.3.6), a sender's option, if the encoding is constructed and all immediately available; c) use the indefinite form (see 8.1.3.6) if the encoding is constructed and is not all immediately available. 8.1.3.3 For the definite form, the length octets shall consist of one or more octets, and shall represent the number of octets in the contents octets using either the short form (see 8.1.3.4) or the long form (see 8.1.3.5) as a sender's option. NOTE - The short form can only be used if the number of octets in the contents octets is less than or equal to 127. 8.1.3.4 In the short form, the length octets shall consist of a single octet in which bit 8 is zero and bits 7 to 1 encode the number of octets in the contents octets (which may be zero), as an unsigned binary integer with bit 7 as the most significant bit. EXAMPLE L = 38 can be encoded as 001001102 8.1.3.5 In the long form, the length octets shall consist of an initial octet and one or more subsequent octets. The initial octet shall be encoded as follows: a) bit 8 shall be one; b) bits 7 to 1 shall encode the number of subsequent octets in the length octets, as an unsigned binary integer with bit 7 as the most significant bit; c) the value 2 shall not be used. NOTE 1 - This restriction is introduced for possible future extension. Bits 8 to 1 of the first subsequent octet, followed by bits 8 to 1 of the second subsequent octet, followed in turn by bits 8 to 1 of each further octet up to and including the last subsequent octet, shall be the encoding of an unsigned binary integer equal to the number of octets in the contents octets, with bit 8 of the first subsequent octet as the most significant bit. EXAMPLE L = 201 can be encoded as: 10012 110010012 NOTE 2 - In the long form, it is a sender's option whether to use more length octets than the minimum necessary. 8.1.3.6 For the indefinite form, the length octets indicate that the contents octets are terminated by end-of-contents octets (see 8.1.5), and shall consist of a single octet. 8.1.3.6.1 The single octet shall have bit 8 set to one, and bits 7 to 1 set to zero. 8.1.3.6.2 If this form of length is used, then end-of-contents octets (see 8.1.5) shall be present in the encoding following the contents octets. 8.1.4 Contents octets The contents octets shall consist of zero, one or more octets, and shall encode the data value as specified in subsequent clauses. NOTE - The contents octets depend on the type of the data value; subsequent clauses follow the same sequence as the definition of types in ASN.1. 8.1.5 End-of-contents octets Brg Anders all that H.248 says about sequences is: NOTE 2 - The ASN.1 specification below contains a clause defining TerminationIDList as a sequence of TerminationIDs. The length of this sequence SHALL be one, except possibly when used in contextAuditResult. Is that our case? Luis. On 9/25/06, Anders Broman (AL/EAB) [EMAIL PROTECTED] wrote: On 9/25/06, ronnie sahlberg [EMAIL PROTECTED] wrote: Are these zero length constructs actually allowed by the standard? If they are not it might be better to just abort dissection completely
Re: [Wireshark-dev] Patch: Improvements for TIPC dissectorpackage-tipc.c
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Martin Peylo Skickat: den 28 september 2006 18:15 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Patch: Improvements for TIPC dissectorpackage-tipc.c Hi Jaap, thanks for the remarks! Till now I wasn't delivering many patches of that extend. I cleaned things up a little bit: 1. Don't know why I sent a tar.gz guess my brain I had an interrupt while I was compressing the file :-) 2. I didn't see Anders Borman updated packet-tipc.c. We discussed making the info column more conceise but I understood he wouln't go to change something in the near future. I adapted my code to Anders' version and the patch does now apply to to current version in svn. 3. I divided the patch in 2 parts: a. packet-tipc-svn-ignorews.patch.gz Here are the actual changes to the code. Explanation below! b. packet-tipc-patched-whitespaces.patch.gz Here are whitespaces removed/added. This is applied after a! -- A short explanation of packet-tipc-svn-ignorews.patch: From top till @@ -498,7 +520,7 @@ there are mainly changes that make what is shown in the info column more conceise. Also the end of the initializers are cleaned up then in the next section till @@ -516,62 +538,85 @@ there is the packet_info *pinfo argument removed which caused warnings while building because it's not used then in the next section till @@ -662,61 +707,55 @@ is where the info column is written. How it is done is a fist approach, discussed with people from the TIPC mailing list. For sure there can be more improvements. then till @@ -1027,10 +1134,9 @@ the internal header is dissected according to the current protocol spec available at http://tipc.sourceforge.net/documentation.html then till @@ -1477,10 +1577,25 @@ there is that pinfo from above removed. The error field in the info column is handled where the other entries for the info column are done. then in the next section till @@ -1517,7 +1632,7 @@ there is determined if it's an interal or payload header (instead of in tipc_v2_set_col_msgtype()) and if the info column is to be set (and this is not done anymore every time tipc_v2_set_col_msgtype() but only once and then tipc_v2_set_info_col() is called). then till @@ -1776,17 +1891,17 @@ that pinfo thing then till @@ -2166,8 +2326,8 @@ should be obvious then in the next section till the end this setting only applies to TIPCv1... -- If anything is not clear, please feel free to get back to me! Best Regards, Martin On 9/28/06, Jaap Keuter [EMAIL PROTECTED] wrote: Hi Martin, Some remarks: 1. The attachement was a actually a tar.gz 2. It's a BIG patch 3. It doesn't apply cleanly to the HEAD so, if you could: 1. send a 2 patch set, with a. protocol changes relative to HEAD first, for easier review b. cleanup changes to patched HEAD second. 2. also cleanup the end of the initializers, the last element shall not have a trailing comma. Thanx, Jaap On Thu, 28 Sep 2006, Martin Peylo wrote: Hi, The attached patch (against wireshark 0.99.3a) mainly improves following aspects of the TIPC dissector: - dissection of TIPCv2 internal messages now shows all fields used according to the protocol spec - there should be no issues with the current protocol spec anymore - the info column is more concise and gives more details - some code beautifications Could someone please review it and - if ok - commit it? If there are any issues left or raised please CC a mail to: martin dot peylo at siemens dot com Thanks, Martin Peylo ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 19372: /trunk/ /trunk/: Makefile.nmake
Hi, On my Windows2000 machine at work I get a syntax error from that line... (Not on the XP one at home though). Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 30 september 2006 02:45 Till: wireshark-commits@wireshark.org Ämne: [Wireshark-commits] rev 19372: /trunk/ /trunk/: Makefile.nmake http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=19372 User: ulfl Date: 2006/09/30 12:45 AM Log: that wasn't a typo, xcopy can't rename files that way Directory: /trunk/ ChangesPath Action +1 -1 Makefile.nmakeModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 19372: /trunk/ /trunk/: Makefile.nmake
Hi, It will have to wait untill Monday... Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Ulf Lamping Skickat: den 30 september 2006 10:57 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] [Wireshark-commits] rev 19372: /trunk/ /trunk/: Makefile.nmake Anders Broman wrote: Hi, On my Windows2000 machine at work I get a syntax error from that line... (Not on the XP one at home though). I don't have a Win2000 machine to test. Could you try if removing the /d helps? Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] s/asn2eth.py/asn2wrs.py/g inasn1/umts_rrc*/Makefile
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Reinhard Speyerer Skickat: den 30 september 2006 16:15 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] [Patch] s/asn2eth.py/asn2wrs.py/g inasn1/umts_rrc*/Makefile The attached patch updates asn1/umts_rrc*/Makefile for the renamed asn2eth.py - asn2wrs.py. Regards, Reinhard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] update to packet-newmail.c
Checked in. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Stephen Fisher Skickat: den 3 oktober 2006 01:24 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] [Patch] update to packet-newmail.c Attached is a patch that changes packet-newmail.c to always register itself on the port from the preferences (defaults to 0) upon launch. This allows the user to right-click and use decode as. Currently, the dissector only registers itself when the default port number changes from 0 or by packet-dcerpc-mapi.c when a MAPI register push notification packet is seen. Thanks, Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch for BACnet (packet-bacapp.c/.h)
Checked in. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För David Richards Skickat: den 3 oktober 2006 10:21 Till: Wireshark developer support list Ämne: [Wireshark-dev] Patch for BACnet (packet-bacapp.c/.h) Here is a patch for BACnet. It contains numerous changes, most notably: 1) BACnetStatusFlags is bit string, not enum, in NotificationParameters 2) Fixes many places where enclosing context tags were not handled properly. 3) Simplify tag decoding logic. Change to explicit decoding in many instances rather than read tags in a loop and do a switch based on tag number. Looping ignores out-of-order and other types of tagging errors. Could someone please commit these changes. I used TortoiseSVN Create Patch to generate this file. If there's a problem with it let me know. Thanks, Dave Richards ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Add camel statistics, for counter, and delay time.
Hi, I've checked in the new files but not the makefiles, nor the change to packet-camel-template.c because of problems to build with MSVC6: Linking tshark.exe link @C:\DOCUME~1\GAREN~1\LOKALA~1\Temp\nmc00492. tap-camelsrt.obj : error LNK2001: unresolved external symbol _gcamel_StatSRT tap-camelsrt.obj : error LNK2001: unresolved external symbol _gtcap_StatSRT tshark.exe : fatal error LNK1120: 2 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' This is with adding camel_opr_code_strings DATA to libwireshark.def which gave an error as well also the compiler is complaining about tap_queue_packet in camel-persistent-data.c Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 3 oktober 2006 16:25 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Add camel statistics, for counter, and delay time. Hello, Please find two new TAP for Camel Statistics. The first one updates counters related to camel operations. It is located in the GSM submenu. The second one , named Camel Service Response Time, gives the time ellapsed between a couple of camel specifics operations. (For example InitialDP/Continue or InitialDP GPRS/Continue GPRS). With Wireshark, you can have the Min/Max/Mean delay time for your traces files, and with Tshark, you have the additional information for percentile (1%,95% 99% etc ) To enable the use of the Camel statistics, you have 2 new parameters in the preferences, - SRT, enable the service Response Time calculation. - persistentSRT, keep the data in a context, even after the camel session has been closed. This is mandatory with Wireshark, to have a clean display of the stats. (See attached file: tapcamel.tar.gz) Regards Florent ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Add camel statistics, for counter, and delay time.
Hi, I got it to compile now please check that I didn't break anything. (I did not use your patches). BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 4 oktober 2006 16:04 Till: wireshark-dev@wireshark.org Ämne: Re: [Wireshark-dev] Add camel statistics, for counter,and delay time. Hello Ulf, Sorry for the undefined external symbols in tap-camelsrt.c I did remove the two unknown symbols gtcap_StatSRT and gcamel_StatSRT in the files ./tap-camelsrt.c ./epan/camel-persistentdata.c and ./epan/camel-persistentdata.c in the following patches. (See attached file: tcap-persistentdata.c.diff)(See attached file: camel-persistentdata.c.diff)(See attached file: tap-camelsrt.c.diff) Could you try this ? and if it works apply the patch for asn1/camel/packet-camel-templace.c and for the Makefile ? I just want to add, that I am working under linux, and I do not have any error, nor warning concerning these symbols. So it is for me a surprise to discover that I should have updated the libwireshark.def .. sorry again .. Best regards Florent Without looking at the patch: Did you noticed the note in libwireshark.def which I've added some weeks ago: ; DATA symbols must be declared WS_VAR_IMPORT in the header file! I've stumbled over this several times (and it looks like you've stumbled as well :-), so I've added a note in this file. Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch for gtk/capture_dlg.c (Bug 771)
Hi, (Ulf) did this get picked up in the latest changes? BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 3 oktober 2006 16:42 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Patch for gtk/capture_dlg.c (Bug 771) Hello Could you apply this patch to correct the Bug 771. The patch has been synchronized with SVN19401, and has been tested under linux (not Windows) There are still 2 existing drawbacks: - the menu history is not implemented, so when you reopen the dialog window, you have lost your configuration. - there is no association between Filter and Datalink, so you will have a default filtering for IP on MTP2 ... (See attached file: capture_dlg.c.diff) Regards Florent ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch for HMIP6
Checked in. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Nicolas DICHTEL Skickat: den 4 oktober 2006 16:10 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] Patch for HMIP6 Hi, M flag isn't for MCOA, but for HMIP (RFC4140 Section 4.1). Regards, Nicolas ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] New dissector for Enea's LINX protocol
Hi, Oh I forgot - I rearranged the code to look more like other dissectors and made it a regular dissector not a plugin. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Anders Broman Skickat: den 4 oktober 2006 20:04 Till: 'Developer support list for Wireshark' Ämne: Re: [Wireshark-dev] New dissector for Enea's LINX protocol Checked in. Could you add a page about the protocol in the protocol pages at http://wiki.wireshark.org and add the sample to the samples page. It would be good if you'd let us know when a proper Ethertype is assigned. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Martin Peylo Skickat: den 4 oktober 2006 11:20 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] New dissector for Enea's LINX protocol Hi, could anybody please check the attached dissector for Enea's LINX protocol? A protocol spec is available at http://www.enea.com/templates/Extension8947.aspx. The source of the kernel module could be obtained from Enea by sending a request to linx at enea dot com. Currently they use ethertype 0x which is not registered at IEEE. I was told they requested one - what should to be done about that? Please come back to me with any remarks! Regards, Martin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] RTP-MIDI
Hi, Hi Anders, I have now completed the plugin and it is working quite nice. It supports all of the current RTP-MIDI-spec, but does not decode the chapters of the system- and the channel-journal, I will probably add that still at a later time - for now I didn't think it was so important. But everything else is decoded - I have even included all of the Midi-Manufacturer-IDs that I could get a hold of that are used to specify System-Exclusive-data. If there are links to where this info can be found please add those links. I wanted to keep it a plugin until it has seen a little bit of use by some people... Where would I send the source-code of the plugin and the sample traces? Best regards, Tobias Please add the sample capture at: http://wiki.wireshark.org/SampleCaptures#head-6c6fb4051dfbe9b992057ea1533eb8 dc85c9a13a Some info about the protocol/dissector at http://wiki.wireshark.org/ProtocolReference would be nice. Send the (g)ziped source code to this list :) Brg Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] RTP-MIDI
Hi, At a quick glance you need to change the C++ style comments // To /* */ as all compilers do not like them. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Tobias Erichsen Skickat: den 8 oktober 2006 19:55 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] RTP-MIDI Well - here we go... Attached you will find two files: rtpmidi.zip - the source of the rtp-midi plugin capture.zip - an archive which contains two captures of rtp-midi-data The specification that is the basis for this dissector is: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-rtp-midi.txt The code compiles under Windows (cygwin vs 6), I have not tried compiling it with linux, so anyone who wants to give it a try, please do so. Additionally, I guess that the things I have done in the dissector could probably optimized. I have just used calls that I got a glimpse of within some of the other dissectors (rtp rtp-events, rudp). So comments on how to improve the code are highly welcome ;-) Best regards, Tobias -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Tobias Erichsen Gesendet: Freitag, 6. Oktober 2006 07:48 An: Developer support list for Wireshark Betreff: Re: [Wireshark-dev] RTP-MIDI [heur] I will do some final code-cleaning over the next couple of days, do some more testing and will post the code here some time during the weekend... Tobias -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Erwin Rol Gesendet: Donnerstag, 5. Oktober 2006 23:21 An: Developer support list for Wireshark Betreff: Re: [Wireshark-dev] RTP-MIDI On Thu, 2006-10-05 at 23:15 +0200, Tobias Erichsen wrote: The problem is that RTP-MIDI does some tweaking to the MIDI-data. For example: System-Exclusive-data can be segmented into multiple RTP-frames by ending a segment with a Status-Byte that would normally not be there. Another thing is the fact that Realtime-Status-Bytes (just one octet long) can be at any position in a normal midi-stream, but in RTP-MIDI they always stand alone... But they still share a lot of code, like all the command descriptions etc. Maybe the RTP-MIDI dissector can just be extended to also do normal MIDI (one MIDI message per packet kind). But anyway i hope your dissector is added soon, good work :-) - Erwin ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Release (0.99.4) next week
Hi, On the other hand it could be argued that Wireshark has been Out there with this (possible) bug for months/years. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Brian Vandenberg Skickat: den 10 oktober 2006 04:24 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Release (0.99.4) next week Blocker, by definition, means it blocks development or testing. That bug is likely giving me hell with a dissector I've been writing for work. At work we classify bugs as: blocker blocks development, testing, or use of the feature. Critical is crash/hang. Major is loss of functionality without a reasonable workaround. Normal is loss of functionality with a reasonable workaround. The classification here seems to be roughly the same. I think if you twist the words enough, you could claim (with a straight face) it's a blocker: it blocks you from testing with certain types of tcp packets. -Brian John R. wrote: On 10/9/06, Joerg Mayer [EMAIL PROTECTED] wrote: On Mon, Oct 09, 2006 at 04:08:04PM -0700, Gerald Combs wrote: I'd like to release 0.99.4 next Wednesday (the 18th). If you're planning on checking in any major changes, please hold off until the release branch is created (probably Friday or Monday). Hmm, there are still some open points on the roadmap: Pending: Version checking. Windows updater. Fix Coverity bugs. Fix blocker bugs: 396 - Saving flow data crashes Wireshark Finish capture privilege separation. Use the User's Guide as the online help system for Wireshark releases So does this mean only blocker bugs are fixed in the short term? http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1124 Seems pretty important since it means that in circumstances where packets are split across tcp segments there are significant issues with desegmentation and dissection, probably across all application layer protocols on top of TCP where PDU length is judged by header rather than trailer data. Is Severity of Major the right thing or not? I suppose it's not a crash/hang bug so it ain't an emergency but I am curious how bugs are prioritized for fix. Thanks, -- John. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Writing a new packet dissector
Hi,
Below is an example on how to register your dissector in the media_type
dissector table:
void
proto_reg_handoff_foo(void)
{
dissector_handle_t foo_handle;
dissector_handle_t application_foo_handle;
foo_handle = create_dissector_handle(dissect_foo, proto_foo);
application_foo_handle = create_dissector_handle(dissect_application_foo,
proto_foo);
dissector_add_string(media_type,application/isup,
application_foo_handle);
}
Then you start your dissection code at:
dissect_foo()
What dissector to look at to get examples on how to proceed depends on the
protocol, TVL type or text based or whatever.
Br
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Daniel Griscom
Skickat: den 14 oktober 2006 15:02
Till: Developer support list for Wireshark
Kopia: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] Writing a new packet dissector
At 10:46 AM +0200 10/14/06, Jaap Keuter wrote:
Hi,
Oke, here it goes: RTFM's at www.wireshark.org
Yes, I've already spent quite a while going over the user and
developer documentation. I've also already downloaded and sniffed
around the source. End result: little detailed enlightenment.
Bit more to the point: What platform are you developing on? Wild guess
Win32?
Well, I'm an OS X man by choice, but Wireshark is so much better
integrated into Windows that I use it there.
Then look into the Wireshark Developer Guide, which has the step by
step guide of setting up the build environment. With all that in place
check out doc/README.developer which contains lots of details on the
internals.
Ah: that's the info I was looking for. Suggestion: add a pointer to
the wireshark/doc directory to the very top of the developer's guide;
less-experienced open-source developers (like myself) might not know
to look there.
After a lot of grepping, I found the text-based media dissection code
at epan/dissectors/packet-text-media.c. I'll start my work there.
Thanks,
Dan
--
Daniel T. Griscom [EMAIL PROTECTED]
Suitable Systems http://www.suitable.com/
1 Centre Street, Suite 204(781) 665-0053
Wakefield, MA 01880-2400
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Lua breaks Windows build
Hi, Windows build is broken: register_wslua.c taps_wslua.c wslua_dumper.c wslua_field.c wslua_field.c(179) : error C2065: 'FieldInfo_get_data_source' : undeclared identifier wslua_field.c(179) : error C2099: initializer is not a constant wslua_field.c(181) : error C2065: 'FieldInfo_get_hidden' : undeclared identifier wslua_field.c(181) : error C2099: initializer is not a constant wslua_gui.c wslua_pinfo.c wslua_proto.c wslua_listener.c wslua_tree.c wslua_tvb.c wslua_util.c Generating Code... NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] packet-gsm_a.c: fix CLIR IEs for CC-SETUP
Checked in. Brg Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Reinhard Speyerer Skickat: den 24 oktober 2006 22:52 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] [Patch] packet-gsm_a.c: fix CLIR IEs for CC-SETUP The attached patch fixes the incorrect decoding of the CC-SETUP CLIR suppression and invoke info elements (which seem to have been copied from the location update accept PDU). Regards, Reinhard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Updated Wireshark-win32-lib files
Hi, I have updated the GTK 2.8 files for now GTK 2.8 is still disabled. New portaudio files (v19) is also there but currently untested(not downloaded). Please run nmake -f makefile.nmake clean_setup and nmake -f makefile.nmake setup As gettext is updated. For those who want to test with GTK 2.8 change the following lines in config.nmake Accordingly. #GTK2_INST_VERSION=2.2 #PANGO_INST_VERSION=1.2 #GTK2_INST_VERSION=2.4 #PANGO_INST_VERSION=1.4 # GTK 2.6 is the mainline since Ethereal 0.10.14 GTK2_INST_VERSION=2.6 PANGO_INST_VERSION=1.8 # Support for GTK 2.8 is currently experimental ... #GTK2_INST_VERSION=2.8 #PANGO_INST_VERSION=1.12 Best regards Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] OMG Still it doesn't compile!
Hi, Thats realy weird. Have you tried to do: Nmake -f makefile.nmake clean_setup Nmake -f makefile.nmake setup Then check: C:\wireshark-win32-libs\net-snmp-5.3.1\win32\lib\release\ For netsnmp.lib It's there on my system... BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 31 oktober 2006 14:48 Till: wireshark-dev@wireshark.org Ämne: Re: [Wireshark-dev] OMG Still it doesn't compile! Ok I've started over. This post is a little long, but it shows where I'm at, hopefully it'll give you guys an idea as to what I'm not doing or whats wrong All this is from the win32 command line. Run vcvar32.bat Nmake -f makefile.nmake distclean Nmake -f makefile.nmake verify_tools Nmake -f makefile.nmake setup Nmake -f makefile.nmake all And there's a whole load of compiling that goes on forever and a day, I get some compiler warnings (unreferenced locals, things like that), some fatal errors relating to winposixtype.h and netsnmp.h but still it keeps going! To get past all that I need to move some files locally and then it compiles up to: LINK : fatal error LNK1181: cannot open input file C:\wireshark-win32-libs\net-snmp-5.3.1\win32\lib\release\netsnmp.lib NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\link.exe' : return code '0x49d' Stop. NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' : return code '0x2' Stop. Now I don't have netsnmp.lib, I do have netsnmpagent.lib, which I rename and move locally which solves the immediate problem, but may cause yet to be discovered problems later! At that point I have another error relating to lua5.1 which I solve by renaming the vc6 directory to 'dll'. BUT... After this point I now get: Creating library libwireshark.lib and object libwireshark.exp dissectors.lib(packet-snmp.obj) : error LNK2001: unresolved external symbol _sprint_realloc_objid dissectors.lib(packet-snmp.obj) : error LNK2001: unresolved external symbol _sprint_realloc_value dissectors.lib(packet-snmp.obj) : error LNK2001: unresolved external symbol _netsnmp_ds_set_int dissectors.lib(packet-snmp.obj) : error LNK2001: unresolved external symbol _netsnmp_ds_set_boolean dissectors.lib(packet-snmp.obj) : error LNK2001: unresolved external symbol _read_configs dissectors.lib(packet-snmp.obj) : error LNK2001: unresolved external symbol _init_mib dissectors.lib(packet-snmp.obj) : error LNK2001: unresolved external symbol _read_premib_configs dissectors.lib(packet-snmp.obj) : error LNK2001: unresolved external symbol _register_mib_handlers dissectors.lib(packet-snmp.obj) : error LNK2001: unresolved external symbol _shutdown_mib dissectors.lib(packet-cops.obj) : error LNK2001: unresolved external symbol _sprint_realloc_by_type dissectors.lib(packet-cops.obj) : error LNK2001: unresolved external symbol _mib_to_asn_type dissectors.lib(packet-cops.obj) : error LNK2001: unresolved external symbol _get_tree dissectors.lib(packet-cops.obj) : error LNK2001: unresolved external symbol _tree_head lua5.1.lib(lauxlib.obj) : error LNK2001: unresolved external symbol _errno lua5.1.lib(loslib.obj) : error LNK2001: unresolved external symbol _errno lua5.1.lib(liolib.obj) : error LNK2001: unresolved external symbol _errno lua5.1.lib(lobject.obj) : error LNK2001: unresolved external symbol __pctype lua5.1.lib(llex.obj) : error LNK2001: unresolved external symbol __pctype lua5.1.lib(lstrlib.obj) : error LNK2001: unresolved external symbol __pctype lua5.1.lib(lbaselib.obj) : error LNK2001: unresolved external symbol __pctype lua5.1.lib(lobject.obj) : error LNK2001: unresolved external symbol ___mb_cur_max lua5.1.lib(llex.obj) : error LNK2001: unresolved external symbol ___mb_cur_max lua5.1.lib(lstrlib.obj) : error LNK2001: unresolved external symbol ___mb_cur_max lua5.1.lib(lbaselib.obj) : error LNK2001: unresolved external symbol ___mb_cur_max lua5.1.lib(lmathlib.obj) : error LNK2001: unresolved external symbol __HUGE libwireshark.dll : fatal error LNK1120: 17 unresolved externals NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\link.exe' : return code '0x460' Stop. NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' : return code '0x2' Stop. So I figure stop and ask you guys. I've got to write a dissector when I get this to compile, I hope its nowhere near as much fun! This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics UK Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or
Re: [Wireshark-dev] How can a TAP refer to external data ?
Have you added the corresponding lines to /epan/libwireshark.def ?
BR
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Michael Lum
Skickat: den 31 oktober 2006 20:12
Till: 'Developer support list for Wireshark'
Ämne: [Wireshark-dev] How can a TAP refer to external data ?
Hello,
I am trying to modify the ansi_a_stat.c file.
I want the TAP to use an array of structures (ext_value_string_t below) from
the packet-ansi_a.c dissector.
In the TAP I have a pointer to the array.
During linking I get the following error:
Linking wireshark.exe
link @C:\DOCUME~1\mlum.BC\LOCALS~1\Temp\nma04728.
libui.lib(ansi_a_stat.obj) : error LNK2001: unresolved external symbol
__imp__ansi_a_dtap_strings
libui.lib(ansi_a_stat.obj) : error LNK2001: unresolved external symbol
__imp__ansi_a_bsmap_strings wireshark.exe : fatal error LNK1120: 2
unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
The definition of ansi_a_dtap_strings is as follows from
epan/dissectors/packet-ansi_a.h:
typedef struct ext_value_string_t
{
guint32 value;
const gchar *strptr;
guint32 dec_index;
}
ext_value_string_t;
WS_VAR_IMPORT const ext_value_string_t *ansi_a_bsmap_strings; WS_VAR_IMPORT
const ext_value_string_t *ansi_a_dtap_strings;
From epan/dissectors/packet-ansi_a.c:
const ext_value_string_t *ansi_a_bsmap_strings = NULL; const
ext_value_string_t *ansi_a_dtap_strings = NULL;
The pointers are set in packet-ansi_a.c depending on a configuration
parameter, IOS version.
The previous version, which built and works correctly had the following
definition:
WS_VAR_IMPORT const value_string ansi_a_ios401_bsmap_strings[];
In the new code I have:
WS_VAR_IMPORT const value_string ansi_a_ios401_bsmap_strings[];
WS_VAR_IMPORT const value_string ansi_a_ios501_bsmap_strings[];
The pointer 'ansi_a_bsmap_strings' will be set to one of the above depending
on the current IOS version.
Thanks for your help.
Build environment:
Windows XP
Visual C++
--
Michael Lum Principal Software Engineer
4600 Jacombs Road+1.604.276.0055
Richmond, B.C.
Canada V6V 3B1
UTStarcom Canada, Inc.
CDMA Division
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] 0.99.4 packaging fails on Windows
Hi, An attempt to fix it was checked in in rev 19764 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=19764 I have not had the time to test it though. /Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Maynard, Chris Skickat: den 3 november 2006 01:11 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] 0.99.4 packaging fails on Windows I successfully compiled Wireshark 0.99.4 on a Win32 platform, but when I ran nmake -f Makefile.nmake packaging, it failed as follows: File: libtasn1-3.dll 538493 bytes File: lua5.1.dll 114688 bytes File: init.lua 5611 bytes File: ..\..\epan\wslua\console.lua - no files found. Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] | /oname=outfile one_file_only) Error in script wireshark.nsi on line 335 -- aborting creation process NMAKE : fatal error U1077: 'C:/program files/nsis/makensis.exe' : return code '0x1' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio\VC98\Bin\ MAKE.EXE' : return code '0x2' Stop. C:\wireshark-0.99.4 It seems that the wireshark.nsi file includes these 2 lines [335-336], but neither file is present in the epan\wslua\ directory: File ..\..\epan\wslua\console.lua File ..\..\epan\wslua\dtd_gen.lua Did nmake -f Makefile.nmake truly succeed and these 2 lines should simply be removed from the wireshark.nsi file, or should these 2 files actually be there and something went wrong during compilation, or something else? I commented out the 2 lines and the installer seemed to build and install OK, but I guess I just wanted to make sure nothing is missing, such as the ..\epan\wslua\template-init.lua file, for example. Thanks in advance, Chris Maynard - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Release 00.99.4 missing file?
-Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Bill Florac Skickat: den 7 november 2006 23:01 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Release 00.99.4 missing file? : Since this is the first time I tried to build since 0.99.3 it seems that some things have changed (but they do that) The correct DLLs are not found when you run wireshark.exe from the root directory (root of the build). It does work correctly if run from .\wireshark-gtk1. I looks like there were changes in the install-deps routines. I assume this was by design. Yes I can not get the gtk2 version to run. It spits out this errrorfailed: error about --- Pango-ERROR **: file shape.c: line 75 (pango_shape): assertion failed: (glyphs-num_glyphs 0) aborting... --- Then again, I really don't care at the moment. GTK1 work fine for me. Bill That problem is probably due to old things left in the /gtk2 dir. Running nmake -f makefile.nmake clean_setup and nmake -f makefile.nmake setup will probably solve that. BR Anders -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cook, Timothy Sent: Tuesday, November 07, 2006 10:58 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Release 00.99.4 missing file? This isn't a new issue! I haven't been able to use the CYGWIN version of Python to build WS, since I start with WS around March this year. I have install the Win32 native version of Python (v2.3), no problem. -Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Trybis Sent: Tuesday, November 07, 2006 11:50 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Release 00.99.4 missing file? I let cygwin do its default thing, plus adding in the additional downloads required for the Wireshark documentation. Then I went back to an earlier version of Bash. I only installed cygwin to get Wireshark working so it should be standard. The file system is NTFS. Regards RT -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaap Keuter Sent: 07 November 2006 16:32 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Release 00.99.4 missing file? Hi, This stuff is wierd. First cygpath that acts up, now it's env that can't find python from /usr/bin/ It seems that path isn't working. Do you have a nondefault cygwin installation? Maybe it's the filesystem type, what type is it? Thanx, Jaap ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev __ ___ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com __ ___ ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Issue in Data record Transfer Request code...
If you implemented TCP reassembly that code might be buggy BR Anders Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För prashanth joshi Skickat: den 9 november 2006 22:43 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] Issue in Data record Transfer Request code... prashanth joshi [EMAIL PROTECTED] wrote: Hi, We have written parsing code for the Data Record Transfer Request. The code wroks fine for some of the trace files we have. But for one trace file which has captured GTP packets over UDP our code is not working correct. If we run ethereal without our code addition it shows around 560 packets. However if we run the ethereal with our code addition the following error message shows up: The capture file appears to be damaged or corrupt. (pcap: File has 3858759680-byte packet, bigger than maximum of 65535) And there is an option OK. If we click on that then we do get the ethereal display , but now only 466 packets are shown. Please any one tell me the reason behind this. I am also not understanding how to fix this becos our code acts only from the Data Record Transfer Request in the GTP packet. In that case I dont understand how our code is affecting the other packets being received. Regards, Prashanth. Everyone is raving about the all-new Yahoo! Mail beta. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Release 00.99.4 missing file?
Hi, I have a build directory: c:/Wireshark where I build and modify the sources and an installed version (installed by the installer into c:/Program files/Wireshark) if I want to run the modified version I type Wireshark-gtk2/Wireshark from the command Line In the build directory as that's where the build process puts the Files. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Robert Trybis Skickat: den 12 november 2006 17:03 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Release 00.99.4 missing file? Okay, I think I have finally got a clean run through the build. The nmake seems to have run to completion without errors and I can see; 12/11/2006 14:58 135,056 capinfos.exe 12/11/2006 14:58 268,732 dumpcap.exe 12/11/2006 14:58 162,020 editcap.exe 12/11/2006 14:58 131,808 mergecap.exe 12/11/2006 14:5884,244 randpkt.exe 12/11/2006 14:3769,684 rdps.exe 12/11/2006 14:58 145,272 text2pcap.exe 12/11/2006 14:58 588,240 tshark.exe 12/11/2006 14:58 3,202,920 wireshark-gtk2.exe 12/11/2006 14:55 3,069,976 wireshark.exe Because I had been having problems with the build I started executing the build from within PFE (Programmer's File Editor) as an easy way to capture and examine the build output. This seemed a harmless thing to do as PFE appears to open a Command window and execute the commands. However it looks as if running the build in that way does not behave in exactly the same way as running the build directly in a Command window. Anyway, main problem build problems solved - now onto why the exe does not find the dlls. Thanks for all the help RT -Original Message- From: [EMAIL PROTECTED] [mailto:wireshark-dev- [EMAIL PROTECTED] On Behalf Of Bill Florac Sent: 08 November 2006 21:57 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Release 00.99.4 missing file? The cd.. will make epan would working directory. So it copies the mkstemp.c and strptime.c files from the root directory to the epan directory. (Odd but it does not copy the header file) I confimed this by deleting the files in epan, and the script copied them again. So, by deduction, it seems you are missing these files. They do not seem to be self-generated so you should find them in your C:\wireshark_source_00_99_4\ directory. They are in the SVN version sytem so you should have them. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Trybis Sent: Wednesday, November 08, 2006 3:33 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Release 00.99.4 missing file? Bill, Here is what I got in the build output; cd .. ..\tools\lemon\lemon t=..\tools\lemon\lempar.c dtd_grammar.lemon flex -odtd_parse.c dtd_parse.l flex -odtd_preparse.c dtd_preparse.l flex radius_dict.l xcopy ..\mkstemp.c . /d xcopy ..\strptime.c . /d Can you confirm which directories the two files appear in on your system? Regards RT -Original Message- From: [EMAIL PROTECTED] [mailto:wireshark-dev- [EMAIL PROTECTED] On Behalf Of Bill Florac Sent: 08 November 2006 16:22 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Release 00.99.4 missing file? I think you need to look further back into the nmake output. You should see this: -- cd .. ..\tools\lemon\lemon t=..\tools\lemon\lempar.c dtd_grammar.lemon flex -odtd_parse.c dtd_parse.l flex -odtd_preparse.c dtd_preparse.l flex radius_dict.l xcopy ..\mkstemp.c . /d ..\mkstemp.c 1 File(s) copied xcopy ..\strptime.c . /d ..\strptime.c 1 File(s) copied -- It may give you a clue as to what is going wrong. You could just copy the two file by hand... Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Trybis Sent: Wednesday, November 08, 2006 10:10 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Release 00.99.4 missing file? I have got the path correct for XCOPY, I get invalid number of parameters if I run it from the command line. Could I move mkstemp.c and strptime.c , by hand - where should I put them? I feel I am very close to getting this working. Regards RT -Original Message- From: [EMAIL PROTECTED] [mailto:wireshark-dev- [EMAIL PROTECTED] On Behalf Of Lars Ruoff Sent: 08 November 2006 15:15 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Release 00.99.4
[Wireshark-dev] Update to use the latest gtk 2.8 glib and pango libraries.
Hi, I have: Update to use the latest gtk 2.8 glib and pango libraries. Note from a mail on gtk dev list: -rwxr-xr-x1 tml Administ 224510 Oct 3 18:35 libpango-1.0-0.dll -rwxr-xr-x1 tml Administ37952 Oct 3 18:35 libpangocairo-1.0-0.dll -rwxr-xr-x1 tml Administ58749 Oct 3 18:35 libpangowin32-1.0-0.dll (That's the relevant DLLs from the bin folder in Pango 1.14.5, where the module(s) are built-in into the DLLs, so no lib/pango/1.5.0/modules folder is needed.) Please run distclean and setup again. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] Fix for bug #1163: Dissector bug.ISO8073COTP protocol.
Checked in. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Stephen Fisher Skickat: den 10 november 2006 23:42 Till: [EMAIL PROTECTED]; Developer support list for Wireshark Ämne: Re: [Wireshark-dev] [Patch] Fix for bug #1163: Dissector bug.ISO8073COTP protocol. Please apply the attached patch which is a new more accurate fix for bug #1163. Thanks to Graeme Lunt for pointing out that the first patch broke a different capture with legitimate SES data in it. My patch also corrects the check for number of bytes existing from 4 to 2 as the minimum length of an SES PDU is only 2 bytes: 1 byte type, 1 byte length. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Bug #1205 fix
Done in revision 19888. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Stephen Fisher Skickat: den 13 november 2006 23:04 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Bug #1205 fix Could someone apply the first part of the patch on bug #220 (to main.c. the second part to packet_list.c was done separately for bug 1159 in rev 19735). That patch fixes bug #1205 coincidentally. Thanks, Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Need help on Reassembly and building ethereal on windows.
Hi, The TCP reassembly code has been re-written since 0.10.8 Especially addressing the problem you are seeing I think. The GTP dissector has also been updated. As Jaap noted use the latest SVN version. On http://wiki.wireshark.org there are some instructions on how To build with Cygwin. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Jaap Keuter Skickat: den 14 november 2006 21:16 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Need help on Reassembly and building ethereal on windows. Hi, Two remarks: 1. Why use such ancient source code? 2. Detailed development instruction can be found in the Developer Guide found on the website www.wireshark.org Thanx, Jaap On Tue, 14 Nov 2006, Annie Misha wrote: Hi all, We have added E-GCDR parsing support for GTP' protocol into Ethereal. The code addition has been made in the file packet-gtp.c. We are facing two issues here. 1. Packet reassembly: Our code works fine when we have a Single GTP' PDU which starts in the beginning of the TCP segment and ends in the same segment. When we have a PDU that is segmented and spanning multiple TCP segments, the PDU is not assembled and parsed completely. The code parses only the first segment and gives a Malformed packet error. A GTP' PDU can begin anywhere in a TCP segment. There can be more that one GTP' PDU (Data record request) or only a portion of one in a single segment. But here, when a GTP PDU starts in the middle of the TCP segment then ethereal does not recognize this. It would be great help if you can throw some light on this and your valuable suggestions to resolve the issue. (We have tried using the tcp_dissect_pdus function - but this solves only one half of the issue. That is on using this, if a GTP' request starts in the beginning of the TCP segment and spans 1 and half segment, the code parses the complete request by combining the first and half of second segment. However it fails to identify the next GTP' request which is present in the next half of the second segment.) (Please note we have identified this issue by building an exe in Linux) 2. Building Ethereal on Windows: -- We are trying to build Ethereal exe for windows using cygwin (including our code changes). When we execute the ./configure command for this, we get the following error: checking for GTK+ - version = 2.0.0... no *** Could not run GTK+ test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GTK+ is incorrectly installed. checking for pkg-config... (cached) /usr/bin/pkg-config checking for GLIB - version = 2.0.0... yes (version 2.10.3) checking whether GLib supports loadable modules... yes checking for inttypes.h... (cached) yes checking whether inttypes.h defines the PRI[doxu]64 macros... yes checking for gethostbyname... yes checking for connect... yes checking whether to use libpcap for packet capture... yes checking for extraneous pcap header directories... not found checking pcap.h usability... no checking pcap.h presence... no checking for pcap.h... no configure: error: Header file pcap.h not found; if you installed libpcap from source, did you also do make install-incl, and if you installed a binary package of libpcap, is there also a developer's package of libpcap, and did you also install that package? Can someone please tell us what needs to be done here? It would be of great help if you could give us the exact procedure for building the exe for Windows. Do we have to set the PATH to any specific directory. Do we have to install any additional packages. If so, what are the additional packages to be installed? Your help in overcoming these bottlenecks will be very much appreciated. Thanks in advance. Version used: ethereal-0.10.8-SVN-13012 Thanks, Annie.D - Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] wierd display issue ..
Hi, I did some brief tests yesterday and it looked to me like the installer from the buildbot did not contain the same pango *-dll:s as my own build. I have tried to fix it by temporarily changing the setup script to overwrite files when unzipping. I haven't had the time to check the result yet. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För LEGO Skickat: den 17 november 2006 03:38 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] wierd display issue .. I believe it might have to do with the latest gtk upgrade. I looked for something similar in gnome's bugzilla I couldn't find anything that looked like this (There might be, I just cannot find it they got several Kbugs there!). As I cannot even verify it (no windows box for at least one more month); I think it would be unappropriate for me to file a bug like Some users had told us that if this and that then all boxes happen. As the worst case scenario we might want to back those changes (or go forward even more) and have someone (else) seeing what happens. The fix BTW is tough to verify, as the bug desc says: Sadly I can do this only once per machine so once tested once it cannot be tested again on the same box! On 11/17/06, Ulf Lamping [EMAIL PROTECTED] wrote: LEGO wrote: take a look to http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1223 for a workarround. On 11/17/06, Ravi Kondamuru [EMAIL PROTECTED] wrote: Hi, I just build the latest revision of wireshark rev: 19915. I am seeing a weird display issue. I cant see any text. I am attaching a screenshot to the email. I am not able to figure out what might have gone wrong. i did a distclean and rebuilt the wireshark again. The build is made on windows xp pro. Any ideas for a fix? If we get to the next release, we probably don't want to force our release users to downgrade to SVN xxx ;-) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch to ANSI A/ANSI MAP for IOS 5
Checked in. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Michael Lum Skickat: den 20 november 2006 23:42 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] Patch to ANSI A/ANSI MAP for IOS 5 Finally finished a lot of the changes for IOS 5 support. The attached files must be used together. Built in Windows XP Pro using Visual Studio C++ with the latest repository. packet-ansi_map.c.gz packet-ansi_a.gz This file contains both packet-ansi_a.c and packet-ansi_a.h changes. libwireshark.def.gz ansi_a_stat.c.gz Thanks to everybody who helps build and maintain Wireshark! -- Michael Lum Principal Software Engineer 4600 Jacombs Road +1.604.276.0055 Richmond, B.C. Canada V6V 3B1 UTStarcom Canada, Inc. CDMA Division ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch to packet-ansi_637.c for new teleservices
Checked in. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Michael Lum Skickat: den 20 november 2006 23:36 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] Patch to packet-ansi_637.c for new teleservices A small change in the number of teleservices recognized: Built in Windows XP Pro using Visual Studio C++ with the latest repository. Command used: svn diff packet-ansi_637.c | gzip packet-ansi_637.c.gz -- Michael Lum Principal Software Engineer 4600 Jacombs Road +1.604.276.0055 Richmond, B.C. Canada V6V 3B1 UTStarcom Canada, Inc. CDMA Division ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] new dissector for ETSI DCP (ETSI TS 102 821)
Hi, Could you gzip the c and h files and send them? Id prefer to make a regular dissector rather than a plugin. BR Anders Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Julian Cable Skickat: den 11 november 2006 15:17 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] new dissector for ETSI DCP (ETSI TS 102 821) Hi, please find attached a patch file (generated against the wireshark_0.99.4.orig.tar.gz from the debian unstable source package). for a dissector for the ETSI DCP protocol. This dissector has had significant use over the last months and is quite stable, so I thought it was time to try and get it into the main distribution. I think I did everything the README.plugins said to do. It compiles on linux fine, I use it all the time with a stand-alone build on windows using mingw. Let me know if there are any problems, things I've missed, etc. Julian Send instant messages to your online friends http://uk.messenger.yahoo.com ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] is sigcomp dissector maintained?
Hi, If the corresponding type 2 message with the bytecode isn't in the trace Wireshark can't decode the message. If you still think there is a problem we'd need the trace to be able to locate the problem. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För cco Skickat: den 22 november 2006 22:17 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] is sigcomp dissector maintained? hi! during some tests I have seen some (possible) misbehaviour of the sigcomp dissector: it cannot decompress a type 1 message (state access) which is actually decompressed by one of the peers. it seems to have to do with state management. (there are 3 nodes using sigcomp in the network where the capture is taken) bye now! cristian ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] is sigcomp dissector maintained?
-Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För cco Skickat: den 23 november 2006 00:18 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] is sigcomp dissector maintained? cristian: hi anders. some more questions: 1. is wireshark always using 64K dms? is this somehow configurable? (I saw cases when wireshark was able to decompress but the peer not due to lower dms; configuring dms in wireshark could help) Currently It's set to a fixed size of 64k. 2. any specific compartment mapping? if yes what about sms? Not as I can remember. 3. I am not an wireshark developer and I cannot figure out if showing exactly which sigcomp message from the trace has caused a NACK would be feasable. (when a lot of NACKs are there it is really difficult to figure out which message has caused it) Briefly going back to the RFC it looks like that would involve doing a SHA-1 of the message and keep a list of that and the frame number. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] is sigcomp dissector maintained?
-Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Anders Broman Skickat: den 23 november 2006 07:45 Till: 'Developer support list for Wireshark' Ämne: Re: [Wireshark-dev] is sigcomp dissector maintained? 3. I am not an wireshark developer and I cannot figure out if showing exactly which sigcomp message from the trace has caused a NACK would be feasable. (when a lot of NACKs are there it is really difficult to figure out which message has caused it) Briefly going back to the RFC it looks like that would involve doing a SHA-1 of the message and keep a list of that and the frame number. With a trace with some Messages and their NACK:s that might be fairly quick to implement. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] new dissector for ETSI DCP (ETSI TS 102 821)
Checked in as a regular disssector not a plugin and Code rearranged to look more like other Wireshark dissectors and some warnings/errors on Windows fixed. BR Anders _ Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Julian Cable Skickat: den 22 november 2006 23:55 Till: wireshark-dev@wireshark.org Ämne: Re: [Wireshark-dev] new dissector for ETSI DCP (ETSI TS 102 821) Hi Anders, here attached is the plugin directory as a tarball. There is a sample file with some DCP packets here: http://217.35.80.115/drm/example.pcap I'll try and get my viewcvs back up and running so that any updates can be downloaded. Once its working again it will be here: http://217.35.80.115/cgi-bin/viewcvs.cgi _ Now you can scan http://us.rd.yahoo.com/mail/uk/taglines/default/nowyoucan/reading_pane/*htt p:/us.rd.yahoo.com/evt=40565/*http:/uk.docs.yahoo.com/nowyoucan.html emails quickly with a reading pane. Get the new Yahoo! http://us.rd.yahoo.com/mail/uk/taglines/default/nowyoucan/reading_pane/*htt p:/us.rd.yahoo.com/evt=40565/*http:/uk.docs.yahoo.com/nowyoucan.html Mail. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] frame relay bugfix
Checked in. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Rene Pilz Skickat: den 27 november 2006 23:08 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] frame relay bugfix Hi This patch consists also the last issues. Additionally it solves: - For the SSCOP frames the AAL5 decoding was not performed due to an earlier patch. This caused that no SSCOP message was properly decoded. - As the detection between a LANE frame and a SSCOP frame is rather hard a switch within the atm dissector is included which enforce SSCOP dissecting over a LANE frame. At the moment I do not see a better solution for that. Rene Pilz On Fri, 2006-11-24 at 15:53 +0100, Rene Pilz wrote: Hi Attached is a patch for following items: - Frame Relay: Calculate the size of the frame relay header larger than 2 bytes correctly - ERF File: In approx 10% of the cases ethereal is not able to recognize the ERF file correctly. So the file format check of erf is moved more to the beginning of the function. This is not real a solution, but as erf files are not that seldom this might be acceptable. - Added Columns: Add columns for DLCI (Frame Relay) and TLLI (GSM BSSGP). As these are crucial Identifiers within this protocol this is rather useful. At least they asked me several times. So please take a look at it. Thanks. Best Regards Rene ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- Dipl-Ing (FH) MSc. C.E René Pilz ftw. Telekommunications Research Center Vienna http://www.ftw.at Tech Gate Vienna, Donaucitystraße 1, A-1220 Wien Mobile: +43 664 8269871 Office: +43 1 5052830-13 Fax: +43 1 5052830-99 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compiling under MSVC 6.0 - simple Q, clear cut A ?
Hi, And note that Wireshark can't be built without the other tools on any system. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Jaap Keuter Skickat: den 30 november 2006 22:16 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Compiling under MSVC 6.0 - simple Q, clear cut A ? Hi, Just faithfully follow the developer guides guidelines on setting up your development environment, including cygwin and its tools, as well gathering the libraries. Tried it a couple of times, never failed on me. Thanx, Jaap On Thu, 30 Nov 2006, Sleep Less wrote: Hi All, from Andre Martin's recent (Nov 2) posting it is not clear to me if Wireshark can be indeed compiled under MSVC 6.0 in a hassle free manner? The developers doc is really partial, e.g on page 24 section 2.6.2 the nmake example seems to give an example of a failure, not of the correct usage. Also instruction on how to run wireshark on MSVC6 debugger (2.5.3) are missing. So I'd be most appreciative on anyone who has done it can give a short description of what it involves. Initial system is assumed to be a clean MSVC 6.0, no other tools, Windows XP SP2. thanks, Haim - Access over 1 million songs - Yahoo! Music Unlimited. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compiling under MSVC 6.0 - simple Q, clear cut A ?
Hi, What version are you trying to build? What does the line DOWNLOAD_PREFIX In the file tools/win32-setup.sh say? BR Anders Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Sleep Less Skickat: den 1 december 2006 09:43 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Compiling under MSVC 6.0 - simple Q,clear cut A ? Hi, I have faithfully followed the Cygwin/packages installation, done the distclean and verify_tools stages. At the setup stage I get an error at the glib part: bash tools\win32-setup.sh --appverify cl link nmake bash bison flexenv grep/usr/bin/find perlenv python sed unzip wget Checking for required applications: cl: /cygdrive/d/PROGRA~1/MICROS~1/VC98/BIN/cl link: /cygdrive/d/PROGRA~1/MICROS~1/VC98/BIN/link nmake: /cygdrive/d/PROGRA~1/MICROS~1/VC98/BIN/nmake bash: /usr/bin/bash bison: /usr/bin/bison flex: /usr/bin/flex env: /usr/bin/env grep: /usr/bin/grep /usr/bin/find: /usr/bin/find perl: /usr/bin/perl env: /usr/bin/env python: /cygdrive/c/ibmtools/python22/python sed: /usr/bin/sed unzip: /usr/bin/unzip wget: /usr/bin/wget ** glib-2.6.6.zip ** No HTTP proxy specified (http_proxy and HTTP_PROXY are empty). Downloading gtk2.6/glib-2.6.6.zip into , installing into glib ERROR: Can't find glib So while I fully believe it cleanly works for many, obviously there is something missing in the manual. Any tips would be much appreciated. Thanks Anders Broman [EMAIL PROTECTED] wrote: Hi, And note that Wireshark can't be built without the other tools on any system. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Jaap Keuter Skickat: den 30 november 2006 22:16 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Compiling under MSVC 6.0 - simple Q, clear cut A ? Hi, Just faithfully follow the developer guides guidelines on setting up your development environment, including cygwin and its tools, as well gathering the libraries. Tried it a couple of times, never failed on me. Thanx, Jaap On Thu, 30 Nov 2006, Sleep Less wrote: Hi All, from Andre Martin's recent (Nov 2) posting it is not clear to me if Wireshark can be indeed compiled under MSVC 6.0 in a hassle free manner? The developers doc is really partial, e.g on page 24 section 2.6.2 the nmake example seems to give an example of a failure, not of the correct usage. Also instruction on how to run wireshark on MSVC6 debugger (2.5.3) are missing. So I'd be most appreciative on anyone who has done it can give a short description of what it involves. Initial system is assumed to be a clean MSVC 6.0, no other tools, Windows XP SP2. thanks, Haim - Access over 1 million songs - Yahoo! Music Unlimited. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev Everyone is raving about the all-new Yahoo! Mail beta. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] sigcomp - accessing state with a partial stateid 6 bytes
Checked in. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För cco Skickat: den 4 december 2006 10:25 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] sigcomp - accessing state with a partial stateid 6 bytes On Wed, Nov 29, 2006 at 09:50:21AM +0100, cco wrote: On Tue, Nov 28, 2006 at 02:46:01PM +0100, Anders Broman (AL/EAB) wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of cco Sent: den 28 november 2006 11:56 To: Developer support list for Wireshark Subject: [Wireshark-dev] sigcomp - accessing state with a partial state id 6 bytes hi! it seems that wireshark fails to access a previous saved state when the specified psi is longer than 6 bytes. and yes, the state was saved at END-MESSAGE(); at least this is what the debug message reports. here is the scenario: 1. sigcomp pkt with bytecode is recv. sucessful decompression, END-MESSAGE makes a state create request. state is saved (it seems that only the first six bytes of the state id are kept; no idea why) 2. sigcomp packet tries to access prev. saved state with a partial state id. partial state id is longer than 6 bytes and wireshark fails. since one of the peers is able to decompress it I suspect there is a problem in wireshark. thanks! bye now! cristian Hi, Wireshark will save the state id with the minimum access length in it's hash table. I guess that later when that state of 6 bytes is compareth with a state of 8 bytes the comparison fails. I think that ought to be changed to save the full 20 bytes state id and the minimum access length And the comparisson should then be made on the actual state id length used, if greater then minimum length. cristian: yes, this would be Signaling Compression (RFC 3320) compliant. I currently have little time to work on this you might want to file a bugzilla report on this preferably with an example trace. cristian: o.k. I will try that. cristian: hi again. here is a patch (for the svn version) which tries to fix this behaviour. compiled and tested it against the dumps that contain sigcomp packets accessing state with partial state id 6 bytes. seems to work now. however pls. have a look. (off-topic?) after patching and compiling (svn) wireshark on my debian notebook, when trying to access Preferences from gui, wireshark coredumped. here is a bt: (gdb) bt #0 0x080f70a6 in pcap_findalldevs () #1 0x080f719d in pcap_findalldevs () #2 0x08062d94 in get_interface_list_findalldevs (err=0xbfb8b2ec, err_str=0xbfb8b2f0 P\237\\b\u\u\u\u\u\u\u\u\u\u\ufff f\u\uN\u) at capture-pcap-util.c:271 #3 0x080a3da1 in capture_prefs_show () at capture_prefs.c:119 #4 0x08083ea0 in prefs_cb (w=0x8518148, dummy=0x0) at prefs_dlg.c:614 #5 0xb6b382a3 in gtk_item_factory_get_type () from /usr/lib/libgtk-x11-2.0.so.0 #6 0xb675ae1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #7 0xb674d98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #8 0xb675df2d in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #9 0xb675f429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #10 0xb675f5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #11 0xb6c431c2 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #12 0xb6b61a1b in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #13 0xb6b61d38 in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #14 0xb6b5799f in gtk_menu_reorder_child () from /usr/lib/libgtk-x11-2.0.so.0 #15 0xb6b51900 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #16 0xb674bf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #17 0xb674d98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #18 0xb675e56f in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #19 0xb675f208 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #20 0xb675f5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #21 0xb6c433e4 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #22 0xb6b4fd2d in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #23 0xb6b501a3 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #24 0xb69e3bfa in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #25 0xb66d2731 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #26 0xb66d57a6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #27 0xb66d5b67 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #28 0xb6b4f341 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #29 0x081a1180 in ?? () #30 0x0001 in ?? () #31 0x0001 in ?? () any idea what could be wrong? thanks! bye now! cristian ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http
Re: [Wireshark-dev] [PATCH] range_string and OSPF bcmodelid
-Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Stephen Fisher Skickat: den 7 december 2006 01:03 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] [PATCH] range_string and OSPF bcmodelid On Mon, Dec 04, 2006 at 10:03:57AM +0100, Francesco Fondelli wrote: So I defined a range_string struct. It's like value_string but stores range - string pairs. Moreover I wrote rval_to_str(), match_strrval_idx() match_strrval() which are behaving exactly as val_to_str(), match_strval_idx() and match_strval(). (almost cut paste :-)) Question to the other committers: Do you think the code for this new range_string be in value_string.[ch] or have its own files range_string.[ch]? Steve I think in value_string.[ch] is ok as it's really a variant of value string. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Update Camel ASN1 definition to 3GPP TS 29.0787.3.0 Release 7
Checked in. -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 19 december 2006 11:38 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Update Camel ASN1 definition to 3GPP TS 29.0787.3.0 Release 7 In fact, I am not sure to understand why we use this type for the CalledPartyBCDNumber definition, as it is not imported. I think I imported it from packet-gsm_map.c for two reasons: - Laziness :) - Common filter for ISDN-address which can be useful. There is still a conflict between Extensions and ExtensionsArray. I think we could remove one of both definitions. If you could have a look on it before applying the patch. Not done due to lack of time, but the patches looks ok so I applied them any way. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Update to use gtk 2.10.6
Hi, I have updated to use the gtk 2.10.6 package. Please run nmake -f makefile.nmake setup to download the libraries. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Portaudio v19
Hi, I have updated to use Portaudio v19, please run setup target. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits]rev20334:/trunk//trunk/asn1/ansi_map/:ansi_map.asnansi_map.cnfpacket-ansi_map-template.c/trunk/epan/dissectors/:packet-ansi_map.cpacket-ansi_map.h
Hi, The main reason is that we want to get rid of the old asn1.c and Use the ber helpers instead. Could you send samples privately or use tex2pcap to remove sensitive data? The BER errors may be IMPLICIT or OPTIONAL missing in some Tags or tags missing. Knowing which messages or tags is causing the errors may also help. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Michael Lum Skickat: den 9 januari 2007 21:33 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] [Wireshark-commits]rev20334:/trunk//trunk/asn1/ansi_map/:ansi_map.asnansi_ma p.cnfpacket-ansi_map-template.c/trunk/epan/dissectors/:packet-ansi_map.cpack et-ansi_map.h So far I have looked at two captures and they both report problems. The files decoded fine with Wireshark 0.99.4. The files are from customer sites so I can't submit them. In some cases the error messages is simply Malformed Packet: ANSI MAP in others it's a BER error. What was the motivation behind changing this dissector to ASN.1 ? -- Michael Lum Principal Software Engineer 4600 Jacombs Road +1.604.276.0055 Richmond, B.C. Canada V6V 3B1 UTStarcom Canada, Inc. CDMA Division -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas Sent: January 8, 2007 11:03 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] [Wireshark-commits] rev20334:/trunk//trunk/asn1/ansi_map/:ansi_map.asnansi_map.cnfpacket-ans i_map-template.c/trunk/epan/dissectors/:packet-ansi_map.cpacket-ansi_map .h OK I will commit changes tomorrow if no complain is received. Meantime I will look again at SSL/TLS desegmentation which makes me headache. Mailcode: C0gmHhFp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman (AL/EAB) Sent: Monday, January 08, 2007 4:35 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 20334:/trunk//trunk/asn1/ansi_map/: ansi_map.asnansi_map.cnfpacket-ansi_map-template.c/trunk/epan/dissectors /:packet-ansi_map.c packet-ansi_map.h Hi, I think thats a good idea. But perhaps we should wait a day or two to see if we get any complaints on The new ANSI MAP dissector and the plans to move the files. Lets say that if no one oposes we'll move the files on Wednesday. BR Anders -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas Sent: den 8 januari 2007 09:25 To: wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 20334: /trunk//trunk/asn1/ansi_map/: ansi_map.asn ansi_map.cnfpacket-ansi_map-template.c /trunk/epan/dissectors/:packet-ansi_map.c packet-ansi_map.h Hello, the only ASN.1 plugin uses old asn1.c/.h files now. I would propose to move them into plugin/asn1 directory. (I have it tested and it works) Does anybody still need them in the epan directory? Tomas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, January 06, 2007 9:51 PM To: wireshark-commits@wireshark.org Subject: [Wireshark-commits] rev 20334: /trunk/ /trunk/asn1/ansi_map/: ansi_map.asn ansi_map.cnf packet-ansi_map-template.c /trunk/epan/dissectors/: packet-ansi_map.c packet-ansi_map.h http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20334 User: etxrab Date: 2007/01/06 08:51 PM Log: Check in the asn2wrs generated ANSI map dissector. Directory: /trunk/asn1/ansi_map/ ChangesPath Action +6 -1 ansi_map.asn Modified +1 -1 ansi_map.cnf Modified +5 -5 packet-ansi_map-template.cModified Directory: /trunk/epan/dissectors/ ChangesPath Action +13477 -10472 packet-ansi_map.cModified +21 -4 packet-ansi_map.hModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Changes to the BER dissector
Hi, Can some one have a look at the changes in packet BER and See if they make sense or if a different solution should be sought? BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] proto_tree_add_item() with range_string
Hi, Does some have an idea on how to implement proto_tree_add_item() with a range_string? That would be really useful. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] proto_tree_add_item() with range_string
Hi,
I had a brief look some time ago and it looked
To me like it would require new FT_x:s or
That the macros VAL and TFS would have to be changed to supply
the needed functions. Is there a better way to do it?
BR
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Jaap Keuter
Skickat: den 12 januari 2007 15:48
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] proto_tree_add_item() with range_string
Hi,
Yeah, that would be nice, having stuff like this:
static const range_string rs_value[] = {
{ 0, 49, Little },
{ 50, 99, Some },
{100,199, Considerable },
{200,255, High },
{ 0, 0, NULL }
};
proto_tree_add_item(tree, hf_proto_value, tvb, offset, 1, FALSE);
static hf_register_info hf[] = {
{ hf_proto_value,
{ Value, proto.value,
FT_UINT8, BASE_DEC,
RS(rs_value), 0x0,
How much is it worth, HFILL }}
};
+ Frame
+ Ethernet II
+ IP
+ TCP
+ Proto
Value: High (220)
That would require weaving in the range string handling along the types
where VALS() and TFS() handling applies (FT_*INT*, and FT_BOOLEAN).
epan/proto.c comes to mind.
Thanx,
Jaap
On Fri, 12 Jan 2007, Anders Broman wrote:
Hi,
Does some have an idea on how to implement proto_tree_add_item() with a
range_string?
That would be really useful.
BR
Anders
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] New GTK Glib Pango for Windows
Hi, There's been a new update to the GTK libraries do we want to bring them in or is it to close to the release? (The files are on our server). BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] New GTK Glib Pango for Windows
-Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Ulf Lamping Skickat: den 17 januari 2007 00:30 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] New GTK Glib Pango for Windows Anders Broman wrote: Hi, There's been a new update to the GTK libraries do we want to bring them in or is it to close to the release? (The files are on our server). Couldn't find the release notes - gtk.org doesn't even list the versions - so it's difficult to say if somethings interesting for us changed! GTK+ = http://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00052.html Overview of Changes from GTK+ 2.10.6 to 2.10.7 == * GtkNotebook - Tab reordering is a less intrusive - Rendering fixes on win32 * GtkTreeView - Column resizing works correctly in right-to-left languages - Many scrolling bugs have been fixed * GtkTextView: - Improved scrolling during DND. * GtkRecentManager is more robust against bad URIs * Print support: - The cups backend works with 'BrowseShortNames Off' in the cups configuration - Multi-valued options are properly passed to cups - Fix build with cups 1.3 - A few IPP compliance issues have been fixed - Make the lpr backend work on BSD * Input methods: - GtkEntryCompletion works with input methods - The Thai input method has been replace by a functional Thai and Lao input method based on libthai * Accessibility support: - GtkMessageDialog sets accessible name role explicitly * Theme support: - The semantics of the gtk-color-scheme setting has been slightly changed. Values from rc files are still merged together, but the X setting just overrides the prior table. * GdkPixbuf: - gdk_pixbuf_loader_write() now closes the loader when returning FALSE, as documented - The BMP loader supports more BMP variants, including transparency and 10-bit channels. * Bugs fixed: 122688 modal dialog popup + drag in progress = mouse freeze 315732 gnome-session crash on login 335622 Click Description field causes Evolution to crash. 357050 Crash replacing \n\n with \n or undoing after paste 359537 printing custom page 373466 crash in Text Editor: 388041 crash in Open Folder: nada 390873 crash in Text Editor: I had just opened it up ... 367529 gtk_combo_box_set_model(combo, NULL) generates warning wh... 381499 xdgmime requires getc_unlocked, darwin 6 lacks 349119 GtkUIManager crashes on wrong action names in an XML file 363437 gnome-panel crash to gtkrecentmanager code 366782 GtkTreeView expand_all can crash if a node's children a... 374378 Crash as GTK tries to blink cursor in defocused spinbutto... 381236 apps crash when using a mouse cursor theme as icon theme 320465 gtk_window_parse_geometry is almost completely broken 355350 Page Setup, Range and Copy information ignored 387170 Fairly large leak in gtk+ 390159 printing with BSD lpr does not work properly 64998 GtkEntry - gtk_entry_set_text emits changed twice 92387 unfriendly drag-n-drop in textview - scrolls too fast 172188 io-bmp.c should sanity check the size given by the OffBit... 304482 GtkComboBoxEntry editable entry should be centered vertic... 315440 Problem with gtkpaned inside gtknotebook(mouse wheel over... 317064 GtkTextBuffer signals documentation 317080 Incorrect gtk.immodules might make GTK+ lose its translation 330683 Changing selection by up/down does not move to top/bottom. 335473 gtk_file_chooser_button_new_with_dialog() is too strict 337261 about dialogue initial focus 339752 Please use LOCALE_IFIRSTDAYOFWEEK for GtkCalendar on Windows 339756 LANG and LC_* environment variables should affect the C r... 349638 Cannot Compose (multi_key) polish l (or L) with stroke, ł 350342 Alt+Left/Right reorders tabs if not swallowed by Gecko 351678 Notebooks not with PositionType.Top drawn incorrectly 351679 Notebooks drawn with extra line below tab in MS-Windows t... 352276 Location of G_GNUC_INTERNAL breaks Solaris build 352435 GtkProgressBar text rendering errors 352738 gtk_tree_view_column_set_sort_indicator() fails to show a... 352795 configure.in: Bug in checking Whether to write dependenc... 353438 Add tiny extra docs to gdk_beep 353709 GtkEntry shift-click inside selected text can behave funny 354495 Compose key doesn't work on location entry 357578 No grid lines are drawn 357974 Crashes (failed assertatin) 359231 validate_visible_area() sometimes passes mismatches (tree... 359542 scale capability for Unix print dialog box can not be set... 359581 GtkCellView clobbers parent's GdkWindow on style-set 360350 leak in gtk_radio_button_focus 362439 gtkicontheme::pixbuf_supports_svg leaks GList 362614 gtk_widget_show does not check for NULL arg 363191 gtk_tree_view_set_cursor() does not make row fully visible 364514 gtk leaks GDI objects on the win32 classic look and feel 364866 CUPS http_t type is becoming opaque 364868 GDI resource leak
Re: [Wireshark-dev] [Wireshark-commits] rev 20463: /trunk/ /trunk/tools/: win32-setup.sh /trunk/: Makefile.nmake
-Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Ulf Lamping Skickat: den 18 januari 2007 00:38 Till: wireshark-dev@wireshark.org Ämne: Re: [Wireshark-dev] [Wireshark-commits] rev 20463: /trunk/ /trunk/tools/: win32-setup.sh /trunk/: Makefile.nmake [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20463 User: etxrab Date: 2007/01/17 07:14 PM Log: Update to use the latest GTK packages. Win32-setup.sh changed to overwrite existing folders. This way one can end up in a version mix of files not overwritten. Wouldn't it instead be better to do the cleanup target before? Regards, ULFL Yes you're right the problems I'm after is - The buildbot - People tend to forget to do the clean_setup first Should we instead change the setup target to first run clen_setup? In that way we are sure to have a clean environment on the buildbot. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] h.223 dissector: maybe a bug, mabe a fix?
Hi,
It would be more interesting and useful to add the capability in
wiretap to read the raw h.223 data with a pcap header. Others can perhaps
help with hints on how to do that.
BR
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Still Life
Skickat: den 18 januari 2007 18:28
Till: wireshark-dev@wireshark.org
Ämne: [Wireshark-dev] h.223 dissector: maybe a bug, mabe a fix?
...or maybe a version mismatch between Wireshark and
the H.223 dissector?
Hi to all,
I'm trying to do a fake h.223 over TCP/IP traffic
between two terminals using, as sources, two raw
h.223 dump files.
The idea is to make an approximate Ethernet-TCP/IP
header and fill it's datagram payload with the
content of the two file (swapping the source and
destination IP to distinguish direction) and using
the WinPcap library to generate a Wireshark compatible dump.
One general question:
Is there another way, more correct, to put the H.223
stream into Wireshark and use the h223 dissector?
(The goal is the ability to analyze the stream within
Wireshark in the simplest way possible).
The h.223 dissector that came with Wireshark 0.99.4
(http://wiki.wireshark.org/H223)
fail to dissect this traffic.
I've done some debug work over the h.223 dissector's code
and maybe I've found a problem.
The point is this boolean flag:
dirdata-first_pdu
this flag is set to TRUE in the following function when
the dissector is called the first time over a single packet:
static h223_call_info *find_or_create_call_info ( packet_info * pinfo )
{
[...]
if( data == NULL )
{
data = se_alloc(sizeof(h223_call_info));
[OTHER1]
[ code that put to FALSE dirdata-first_pdu ]
[OTHER2]
}
[...]
}
At this point the first execution of the packet dissection seems
correct, during the execution the flag is set to FALSE.
Wireshark, I don't know why, call the dissector other times
on the same packet but when this happens data is already
allocated so [ code that put to FALSE dirdata-first_pdu ]
is not executed. This lead to a
[Dissector bug, protocol H.223: proto.c:1190:
failed assertion (guint)hfindex gpa_hfinfo.len]
I change the dissector code in this way:
static h223_call_info *find_or_create_call_info ( packet_info * pinfo )
{
[...]
if( data == NULL )
{
data = se_alloc(sizeof(h223_call_info));
[OTHER1]
[OTHER2]
}
[ code that put to FALSE dirdata-first_pdu ]
[...]
}
But I'm not able to determine if this modification
introduce some wrong side effects.
I put in attachment a zipped file with:
h223.dll the modified h223 plugin dissector
h223_first_60.cap the first 60 packet of the tcp stream
packet-h223.c the dissector's source file modified
Please, in Wireshark uncheck this TCP option:
edit--preference--protocols--TCP--Analyze TCP sequence numbers
Open the h223_first_60.cap and use
Analyze--decode as...--transport label--tcp port both--h223.
Now try to put my h223.dll in the Wireshark plugins
directory (backup the original one) and re-open
h223_first_60.cap
Is there anyone who would give me any comments or suggestions?
Thanks,
Fabio Sguanci
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Vuoi stupirla con un gesto d'amore? Ricorda... un Diamante è per sempre!
* Regalale un gioiello con Diamante e punta dritto al suo cuore!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5632d=18-1
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Dual screen initial window position initialwindow size bugs
Hi, What OS are you using and what version of Wireshark? If you are using Windows you could try out the new 0.99.5Pre1 version which has updated GTK packages which may have fixed the problem already. BR Anders Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Michael Curry Skickat: den 22 januari 2007 23:07 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Dual screen initial window position initialwindow size bugs Dear wireshark-dev team, Let me first describe my dual screen setup: +---+ | | +---+ | | | Primary screen | | Secondary Screen | (1600x1200) | | (1024x768) | | | | | +---+---+ When wireshark starts, the window will appear mostly off the top of the secondary screen. There is also a problem that if wireshark was maximised when closed, it will remember the dimensions it had when maximised, so when the window is restored it stays large! (I think the usual way to solve this is to un-maximise the window before closing, if I remember projects Ive worked on). Best regards, and keep up the good work! Michael Curry ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] VB: [Wireshark-commits] rev 20605: /trunk/gtk/ /trunk/gtk/: dlg_utils.c uat_gui.c uat_gui.h
Hi, It's using gtk_window_present() which is only available in GTK2 so the Windows build fails. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 29 januari 2007 15:14 Till: wireshark-commits@wireshark.org Ämne: [Wireshark-commits] rev 20605: /trunk/gtk/ /trunk/gtk/: dlg_utils.c uat_gui.c uat_gui.h http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20605 User: lego Date: 2007/01/29 02:14 PM Log: Finish (?) UAT's GUI Directory: /trunk/gtk/ ChangesPath Action +9 -0 dlg_utils.cModified +293 -23 uat_gui.c Modified +1 -1 uat_gui.h Modified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] IS-41 ANSI-MAP
Hi, There is two sample fiple files at the Wiki Sampletraces page BR Anders _ Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Andreas Fink Skickat: den 3 februari 2007 08:34 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] IS-41 ANSI-MAP Is there anyone on this list who has access to a ANSI-MAP network who could provide me with a few specific trace files so the MAP decoder could be enhanced for them? Andreas Fink Fink Consulting GmbH Global Networks Schweiz AG BebbiCell AG --- Tel: +41-61-330 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] www.finkconsulting.com www.global-networks.ch www.bebbicell.ch --- ICQ: 8239353 MSN: [EMAIL PROTECTED] AIM: smsrelay Skype: andreasfink Yahoo: finkconsulting SMS: +41792457333 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] SCTP Reassembly
Hi, Has anybody done something about SCTP reassembly? I think something was mentioned on the list a while back but nothing looks to have been implemented. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] SCTP Reassembly
Hi, Thanks works nicely for the trace I've got. BR Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Michael Tuexen Skickat: den 9 februari 2007 18:14 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] SCTP Reassembly Hi Anders, SCTP reassembly support from Robin Seggelmann has been added in revision 20756. Best regards Michael On Feb 8, 2007, at 11:38 PM, Anders Broman wrote: Hi, Has anybody done something about SCTP reassembly? I think something was mentioned on the list a while back but nothing looks to have been implemented. BR Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Update gsmmap to V7.5.0 Rel 7
Checked in. Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 16 februari 2007 13:13 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Update gsmmap to V7.5.0 Rel 7 Hello, Here is a patch to update the gsm map definition up to 3GPP TS 29.002 V7.5.0 (2006-09) Release 7 There is a little impact on the GTP dissector, because I had to change the name of the Local ErrorCode in the gsm map asn1 definition due to a conflict with the Camel dissector. If you have some difficulties to apply the patch on packet-gtp.c, just replace the map local error in the file. ( gsm_map_LocalErrorcode_vals becomes gsm_map_GSMMAPLocalErrorcode_vals ) (See attached file: gsmmap.diff.gz)(See attached file: packet-gtp.c.diff.gz) Regards Florent ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Update camel dissector
Checked in /Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 16 februari 2007 13:27 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Update camel dissector Hello, I did update the Camel dissector to have the same structure as the gsm map dissector. Now the dissector correctly handles the Tcap return error component. Some improvement have been made for ApplyChargingReport too. (See attached file: camel.diff.gz) Regards Florent ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] H.223 dissector - separate bitswapping into separate dissector
-Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Guy Harris Skickat: den 19 februari 2007 05:19 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] H.223 dissector - separate bitswapping into separate dissector Richard van der Hoff wrote: Well, if your H.223 is over TCP, it may or may not be bitswapped Guy wrote: That presumably means that either 1) call setup negotiates the bit order or 2) the bit order is chosen out of band (e.g., manually). If it's negotiated at call setup time, presumably if the call setup traffic is present, Wireshark can determine the bit order, so this presumably would be needed only in the case where the call setup traffic *isn't* present, so you would have to manually specify that the TCP connection is carrying H.223 traffic.¨ For H.223 over TDM I know there has been trouble on agreeing what the proper Bit order is between manufacturers so at least some implementations determine the bit order heuristically... Anders ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Build problem (was Re: Patch for bug 310)
Hi, You are building with MSVC6, right? Have you tried to download a recent SVN snapshot and doing: nmake f makefile.nmake setup nmake f makefile.nmake distclean nmake f makefile.nmake without changing anything else first. Best regards Anders Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Prokash Sinha Skickat: den 20 februari 2007 00:41 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] Build problem (was Re: Patch for bug 310) Now I turn the pcap back on ( since the previous one giving me head file pcap.h was not found ). Watch how link problems comes up ( but the pcap build is almost done ). If I try to rebuld the pcap by going down that path and issue the same command, I would be fine. And later build from the root again would go further along. There got to be a better way -pro C:\Documents and Settings\psinha\wiresharknmake -f Makefile.nmake Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. sed -e s/@VERSION@/0.99.6/ -e s/@HAVE_GNU_ADNS@// -e s/@HAVE_PC RE@// -e s/@HAVE_KFW@// -e s/@HAVE_NETTLE@// -e s/@HAVE_LIBZ@// -e s /@HAVE_LIBPCAP@/#define HAVE_LIBPCAP 1/ -e s/@HAVE_PCAP_FINDALLDEVS@/#define HAVE_PCAP_FINDALLDEVS 1/ -e s/@HAVE_PCAP_DATALINK_NAME_TO_VAL@/#define HAVE_P CAP_DATALINK_NAME_TO_VAL 1/ -e s/@HAVE_PCAP_DATALINK_VAL_TO_NAME@/#define HAV E_PCAP_DATALINK_VAL_TO_NAME 1/ -e s/@HAVE_PCAP_BREAKLOOP@// -e s/@HAVE_LIB WIRESHARKDLL@/#define HAVE_LIBWIRESHARKDLL 1/ -e s/@WPCAP_CONSTIFIED@/#define WPCAP_CONSTIFIED 1/ -e s/@HAVE_LIBGNUTLS@// -e s/@HAVE_LIBGCRYPT@// -e s/@HAVE_LUA@// -e s/@HAVE_LUA_5_1@// -e s/@HAVE_AIRPCAP@// -e s/@HAVE_ AIRPDCAP@// -e s/@HAVE_LIBPORTAUDIO@// -e s/@PORTAUDIO_API_1@// -e s/@H AVE_NET_SNMP@// config.h.win32 config.h cd tools NMAKE / -f Makefile.nmake Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd lemon NMAKE / -f Makefile.nmake Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd .. cd .. cd image NMAKE / -f Makefile.nmake Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. sed -e s/@VERSION_MAJOR@/0/ -e s/@VERSION_MINOR@/99/ -e s/@VERSION_MIC RO@/6/ wireshark.exe.manifest.in wireshark.exe.manifest sed -e s/@VERSION@/0.99.6/ -e s/@RC_VERSION@/0,99,6/ wireshark.r c.in wireshark.rc sed -e s/@VERSION@/0.99.6/ -e s/@RC_VERSION@/0,99,6/ libwireshar k.rc.in libwireshark.rc sed -e s/@VERSION@/0.99.6/ -e s/@RC_VERSION@/0,99,6/ tshark.rc.i n tshark.rc sed -e s/@VERSION@/0.99.6/ -e s/@RC_VERSION@/0,99,6/ capinfos.rc .in capinfos.rc sed -e s/@VERSION@/0.99.6/ -e s/@RC_VERSION@/0,99,6/ editcap.rc. in editcap.rc sed -e s/@VERSION@/0.99.6/ -e s/@RC_VERSION@/0,99,6/ text2pcap.r c.in text2pcap.rc sed -e s/@VERSION@/0.99.6/ -e s/@RC_VERSION@/0,99,6/ mergecap.rc .in mergecap.rc sed -e s/@VERSION@/0.3.1/ -e s/@RC_VERSION@/0,3,1/ wiretap.rc.in w iretap.rc sed -e s/@VERSION@/0.99.6/ -e s/@RC_VERSION@/0,99,6/ dumpcap.rc. in dumpcap.rc cd .. cd codecs NMAKE / -f Makefile.nmake Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. 'codecs.lib' is up-to-date cd .. cd wiretap NMAKE / -f Makefile.nmake Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. sed -e s/@VERSION@/0.3.1/ -e s/@HAVE_LIBZ@// config.h.win32 conf ig.h rc /r ..\image\wiretap cl -DWIN32 -DNULL=0 -D_MT -D_DLL -DHAVE_CONFIG_H /IC:\cygwin\lib\glib\in clude\glib-2.0 /IC:\cygwin\lib\glib\lib\glib-2.0\include /IC:\cygwin\lib\WPdpa ck/include -D_U_= /Zi /W3 /MD -DMSC_VER_REQUIRED=1200 -Fd.\ -c 5views.c airop eek9.c ascend.c atm.c ber.c buffer.c catapult_dct2000.c cosine.c csids.c dbs-eth erwatch.c erf.c etherpeek.c eyesdn.c file_access.c file_wrappers.c hcidump.c i4b trace.c iptrace.c iseries.c k12.c lanalyzer.c libpcap.c netmon.c nettl.c network _instruments.c netxray.c ngsniffer.c pppdump.c radcom.c snoop.c toshiba.c visual .c vms.c wtap.c ascend-grammar.c ascend-scanner.c file_util.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. 5views.c airopeek9.c ascend.c atm.c ber.c buffer.c catapult_dct2000.c cosine.c csids.c dbs-etherwatch.c erf.c etherpeek.c eyesdn.c file_access.c
Re: [Wireshark-dev] Function to decode messages when several encodingcan be used
Committed revision 20878. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 20 februari 2007 13:07 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Function to decode messages when several encodingcan be used This patch provide a new function to decode messages when several ASN1 encoding can be used. This is the case, for example, when a same message has different encoding according to the MAP version, or in case of ASN1 encoder optimization. At the same time, I did remove the configuration variable old_gsm_map_version, which is taken into account in the patch. And likewise, for all the messages defined with the ASN1 sequence [3] SEQUENCE, this function is called for the decoding. (See attached file: packet-gsm_map-template.c.diff.gz) Regards Florent ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] reassembly.c: fragment_set_partial_reassembly() forfragment_add_seq
Committed revision 20888. Without the makefile changes to build the test program as I can't test it on Windows. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 15 februari 2007 22:36 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] reassembly.c: fragment_set_partial_reassembly() forfragment_add_seq Hi guys, I've been working on support for reassembly of protocols over RTP; for this I needed to be able to do fragment_set_partial_reassembly() on fragments added with fragment_add_seq(). Here are a bunch of patches... I'd be much obliged if they could be reviewed and hopefully committed; there will be a bunch of other patches to follow soon! Cheers, Richard 01_reassemble_test.patch I didn't want to do anything without some unit tests, so here they are. This allows a standalone binary, epan/reassemble_test, to be built; this can be run from the commandline and should end up printing out success if all goes well. Incidentally: is it possible to get the buildbot to run things like this, exntest and tvbtest? 02_reassemble_refactor.patch fragment_add_seq, fragment_add_dcerpc_dg and fragment_add_seq_check_work were all pretty much carbon-copies of each other. This patch factors out the common parts of the routines into a new routine, fragment_add_seq_key(). 03_reassemble_partial_reassembly.patch --- This makes fragment_set_partial_reassembly() work for datagrams assembled with fragment_add_seq(). The patch itself is actually quite small, but it adds another unit test which is reasonably lengthy. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] g_assert - DISSECTOR_ASSERT in stream.c
Committed revision 20889. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 15 februari 2007 22:44 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] g_assert - DISSECTOR_ASSERT in stream.c Hi, This patch replaces g_assert() calls in epan/stream.c with DISSECTOR_ASSERT(). Cheers Richard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] defragmentation over RTP
Committed revision 20891.
Best regards
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Richard van der Hoff
Skickat: den 16 februari 2007 16:20
Till: Developer support list for Wireshark
Ämne: [Wireshark-dev] defragmentation over RTP
Hi,
Here's a patch which adds an option enabling subdissectors to request
defragmentation of packets over RTP streams, using the
pinfo-desegment_{len,offset} API.
Please be aware that it depends on my patches yesterday to make
fragment_set_partial_reassembly() work for datagrams
assembled with fragment_add_seq().
Cheers,
Richard
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] DESEGMENT_ONE_MORE_SEGMENT over iax
Committed revision 20892. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 16 februari 2007 19:12 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] DESEGMENT_ONE_MORE_SEGMENT over iax Hi, This patch makes the defragmentation code in the iax2 dissector handle pinfo-desegment_len=DESEGMENT_ONE_MORE_SEGMENT, in line with Ronnie's changes to the tcp dissector of 11 November. Incidentally, Ronnie: I think there's a problem with the tcp dissector. Basically if the subdissector sets pinfo-desegment_len=DESEGMENT_ONE_MORE_SEGMENT, this causes the tcp dissector to set MSP_FLAGS_REASSEMBLE_ENTIRE_SEGMENT for the datagram being reassembled. However, if the same packet is revisited (as it appears it can be sometimes), no more data is added, and MSP_FLAGS_REASSEMBLE_ENTIRE_SEGMENT is cleared. The next fragment is then deemed to start a new datagram. Cheers Richard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] H.223 dissector - separate bitswapping intoseparate dissector
Committed revision 20893. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 19 februari 2007 02:33 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] H.223 dissector - separate bitswapping intoseparate dissector The H.223 dissector contains code to deal with bitswapped captures - ie, where all of the bytes have their bits backwards. It seems that this is much better handled as a separate dissector entry point, so that the right one can be chosen when the dissector is registered, rather than the current dubious heuristics. Please could this patch be reviewed and checked in, as a precursor to my forthcoming addition of H.223-over-RTP dissection? Thanks, Richard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] h.223 robustness fixes
Hi, Compile failes on Windows with: packet-h223.c packet-h223.c(596) : warning C4018: '' : signed/unsigned mismatch packet-h223.c(1156) : error C2065: 'uint' : undeclared identifier packet-h223.c(1156) : error C2146: syntax error : missing ';' before identifier 'needed' packet-h223.c(1156) : error C2065: 'needed' : undeclared identifier NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 20 februari 2007 13:12 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] h.223 robustness fixes Hi, This patch improves the general robustness of the h.223 dissector (making it less likely to crash on malformed data). Hopefully this also fixes a bug raised by Fabio Sguanci a few weeks ago. Fabio: I think a better way to fix the problem is to stop the dissector crashing when it finds a malformed PDU, so that it just treats the first pdu as malformed; there is then no need to special-case it. I don't think this patch will apply cleanly without the bitswapping patch I submitted yesterday. Thanks, Richard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] h.223 robustness fixes
Committed revision 20898 together with the other patch. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 22 februari 2007 16:59 Till: Developer support list for Wireshark Ämne: Re: [Wireshark-dev] h.223 robustness fixes Thanks, Anders. Here's an updated patch - sorry about that. Anders Broman wrote: Hi, Compile failes on Windows with: packet-h223.c packet-h223.c(596) : warning C4018: '' : signed/unsigned mismatch packet-h223.c(1156) : error C2065: 'uint' : undeclared identifier packet-h223.c(1156) : error C2146: syntax error : missing ';' before identifier 'needed' packet-h223.c(1156) : error C2065: 'needed' : undeclared identifier NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 20 februari 2007 13:12 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] h.223 robustness fixes Hi, This patch improves the general robustness of the h.223 dissector (making it less likely to crash on malformed data). Hopefully this also fixes a bug raised by Fabio Sguanci a few weeks ago. Fabio: I think a better way to fix the problem is to stop the dissector crashing when it finds a malformed PDU, so that it just treats the first pdu as malformed; there is then no need to special-case it. I don't think this patch will apply cleanly without the bitswapping patch I submitted yesterday. Thanks, Richard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] Add space between RTP info and payload info
Committed revision 20899. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Charles Lepple Skickat: den 23 februari 2007 04:48 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] [PATCH] Add space between RTP info and payload info This patch is against the trunk, rev 20898. When dissecting RTP packets with a H.263 payload, the Mark flag runs into the Mode A/B flag in the info column. I don't have an H.263 capture on hand to demonstrate this, but based on the RTP audio captures on the wiki, I don't think the extra space is going to break formatting of other RTP payloads. -- - Charles Lepple ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] local operation code in MAP
Hi, What is the hex value shown in the bytes pane when marking localvalue in the middle pane? Best regards Anders Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 25 februari 2007 10:06 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] local operation code in MAP Hi All, Greetings to you. Im adding an operation with local value 153 to GSMMAP. But dissector does not recognize 153, it reports Unknown -103. Kindly tell me how to set this value. Thanks, Bhavani. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Mixed application contexts in MAP
Hi,, Im not sure what you want but see: register_ber_oid_dissector(1.3.12.2.1006.53.2.1.3, dissect_gsm_mapext_PlmnContainer, in the packet-gsm_map-template.c file and PlmnContainer in the asn1 file. Best regards Anders _ Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 25 februari 2007 13:47 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Mixed application contexts in MAP Hi, Can I add application context with iso(1) . OID along with contexts of itu-t(0) OIDs in the same dissector development file? Thanks, Bhavani The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Fwd: H.223 over rtp]
Committed revision 20935.
Best regards
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Richard van der Hoff
Skickat: den 26 februari 2007 18:28
Till: Developer support list for Wireshark
Ämne: [Wireshark-dev] [Fwd: H.223 over rtp]
Now that the predependent patches for this have been applied (thanks for
all that, Anders), please could this one be applied?
Original Message
Subject: [Wireshark-dev] H.223 over rtp
Date: Tue, 20 Feb 2007 12:29:45 +
From: Richard van der Hoff [EMAIL PROTECTED]
Reply-To: Developer support list for Wireshark wireshark-dev@wireshark.org
To: Developer support list for Wireshark wireshark-dev@wireshark.org
This patch registers H.223 as a dissector for RTP CLEARMODE payloads -
and makes some other modifications to the H.223 dissector to make this
work correctly.
It assumes that both my earlier patches to the H.223 dissector ('H.223
dissector - separate bitswapping into separate dissector' and 'h.223
robustness fixes') have been applied; it also depends on my
'defragmentation over RTP' patch (submitted on 16/2/2007) for correct
operation.
I've added some sample captures to the wiki.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] makefile fixes for reassemble_test
Committed revision 20935. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 26 februari 2007 18:41 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] makefile fixes for reassemble_test A couple of weeks ago, I submitted a patch with a load of unit tests for the reassemble.c API. Anders applied the patch, but didn't want to apply the part that referred to the Makefile as he uses Windows and couldn't test under Linux. It would be really good if this could be applied - else the unit tests are pretty useless. It's worth noting that the patch doesn't do anything until you do a make reassemble_test. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch for GTK version in simple_dialog.c
Committed revision 20936. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 23 februari 2007 16:58 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Patch for GTK version in simple_dialog.c This patch add a test on the GTK version to avoid a warning with the gtk-label-select-on-focus configuration parameter, introduced in GTK-2.9.0. (See attached file: simple_dialog.c.diff) Regards Florent ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [patch] update for ETHERNET Powerlink dissector
Committed revision 20937. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Daniel Krüger Skickat: den 24 februari 2007 16:57 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] [patch] update for ETHERNET Powerlink dissector Hello, thanks to David Buechi for his EPL v2 dissector. I attached a patch to this dissector, which includes some corrections, updates and SDO by UDP support. I will upload a sample capture of SDO by UDP to the wiki. The patch is fuzzy tested against the current SVN rev under Linux and it builds also under MSVC2005. Maybe I will provide further updates in the future. I have a feature request: is it possible to add a shortcut for Start capture. I start and stop capturing very often and a shortcut is very handy. I know that capturing must be configured at first. cu Daniel ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] Short section on building RPM fordevelopers guide
Committed revision 20938. Best regards Anders _ Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Douglas Pratley Skickat: den 26 februari 2007 15:37 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] [PATCH] Short section on building RPM fordevelopers guide Hi guys This patch gives brief instructions on how to build the RPM package target for Wireshark. It just contains the steps that worked for me, and a warning on the issues I ran into. It does not contain any instructions on how to install tools for building RPMs on platforms that dont have them, because I dont know (although it references www.rpm.org http://www.rpm.org/ ). Its an incremental improvement on XXX I dont know; someone more familiar with Linux / RPMs might be able to flesh out the instructions. Cheers Doug __ Douglas Pratley t +44 845 050 7640 | f +44 845 644 5436 a Detica | PO Box 383 | Horley | Surrey | RH6 7WX | UK __ file:///M:\exchweb\bin\redir.asp?URL=http://www.detica.com/ www.detica.com This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies. Detica Limited is registered in England under No: 1337451. Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] local operation code in MAP
Hi,
My bad the complete encoding should be 02 02 88 99 ( Integer(02) length(02)
Value(88 99).
Best regards
Anders
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Anders Broman (AL/EAB)
Skickat: den 27 februari 2007 17:55
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] local operation code in MAP
Hi,
Shouldn't the encoded value be H'81 H'19(153) ?
Best regards
Anders
From: [EMAIL PROTECTED] on behalf of
[EMAIL PROTECTED]
Sent: Tue 2/27/2007 3:14 PM
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] local operation code in MAP
Hi,
Ive given the value for operation code, not the ASN1 compiler.
Ive tried below suggestion but still got the problem.
Operation code length : 02, and the operation code : H81 H99.
I tried to print the opcode value read from dissect_ber_integer,
dissect_ber_integer64
They print negative number for int format huge positive number for
unsigned format.
Best Regards,
Bhavani.
From: [EMAIL PROTECTED]
Date: Tue, 27 Feb 2007 13:05:42 +0100
Hi,
You said:
Hex value shown, in the bytes pane is 99.
Is this value field by yourself, or by an ASN1 compiler ?
I think, It could be a problem of long form encoding.
Could you try to use H'81 H'99 instead of H'99 for the operation code in
the message to decode ?
Regards
Florent
From: DurgaBhavani Uppuluru
Sent: Tuesday, February 27, 2007 12:08 PM
To: 'wireshark-dev@wireshark.org'
Subject: RE: local operation code in MAP
Hi Again,
Ive tried latest svn version files too, still I get the same problem.
Ive added gsmmap, ranap directories packet-gtp.c from svn Revision 20934,
on top of wireshark-0.99.5 sources.
Please help me.
Best Regards,
Bhavani.
From: DurgaBhavani Uppuluru
Sent: Tuesday, February 27, 2007 9:41 AM
To: 'wireshark-dev@wireshark.org'
Subject: RE: local operation code in MAP
Hi,
Im using wireshark 0.99.5 sources.
The below code is right.
Ive added the operations in the same way.
Here are the steps followed:
My GSMMAP.asn files looks
1. OperationLocalvalue ::= INTEGER{
updateLocation (2),
:
noteMM-Event (89),
operation1(152),
operation2(153)
}
2. Operation descriptions of operation1 operation2 are added
3. packet-gsm_map-template.c is updated with
gsm_map_opr_code_strings[]={
{ 2, updateLocation },
:
{ 152, operation1 },
{ 153, operation2 }
}
dissect_invokeData()
switch(opcode){
case 2: /*updateLocation*/ dissect_gsm_map_UpdateLocationArg(); break;
:
case 152: /*operation 1*/ dissect_gsm_map_Operation1Arg(); break;
case 153: /*operation 2*/ dissect_gsm_map_Operation2Arg(); break;
}
return offset;
}
3. makefile is used to generate packet-gsm_map.c, packet-gsm_map.h.
Options used with asn2wrs are:
python ../../tools/asn2wrs.py -b -e -p gsm_map -c gsmmap.cnf -s
packet-gsm_map-template GSMMAP.asn
4. Generated packet-gsm_map.c, packet-gsm_map.h are copied to
../../epan/dissectors folder.
Standard makefile present in the wireshark-0.99.5 directory is used to build
the wireshark exe.
The same steps when followed with operation codes with 90,91 or 94,95 work
fine.
Thanks for your time.
Best Regards,
Bhavani.
From: Anders Broman \(AL/EAB\) [EMAIL PROTECTED]
Date: Mon, 26 Feb 2007 16:21:09 +0100
Hi,
Are you running the latest SVN version of Wireshark?
I asume that adding an operation with local value 153 to GSMMAP means that
you are editing the sources,
what happens if you change:
GSMMAPOperationLocalvalue ::= INTEGER{
updateLocation (2),
:
noteMM-Event (89)
}
To:
noteMM-Event (89),
your-string(153)
}
in GSMMAP.asn and rebuild the dissector using asn2wrs?
Best regards
Anders
From: DurgaBhavani Uppuluru
Sent: Monday, February 26, 2007 10:46 AM
To: 'wireshark-dev@wireshark.org'
Subject: RE: local operation code in MAP
Hi Anders,
Hex value shown, in the bytes pane is 99.
Ive tried other numbers too (150) and I get similar result.
Best Regards,
Bhavani.
From: Anders Broman [EMAIL PROTECTED]
Date: Sun, 25 Feb 2007 19:55:43 +0100
Hi,
What is the hex value shown in the bytes pane when marking localvalue in the
middle pane?
Best regards
Anders
From: DurgaBhavani Uppuluru
Sent: Sunday, February 25, 2007 2:36 PM
To: 'wireshark-dev@wireshark.org'
Subject: local operation code in MAP
Hi All,
Greetings to you.
Im adding an operation with local value 153 to GSMMAP.
But dissector does not recognize 153, it reports Unknown -103.
Kindly tell me how to set this value.
Thanks,
Bhavani.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] User information in the packet
Hi,
If its in tha map dialouge you use the extension container. Like in:
MAP-OpenInfo ::= SEQUENCE {
destinationReference [0] IMPLICIT AddressString OPTIONAL,
originationReference [1] IMPLICIT AddressString OPTIONAL,
...,
extensionContainer ExtensionContainer OPTIONAL
-- extensionContainer must not be used in version 2
}
Best regards
Anders
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För
[EMAIL PROTECTED]
Skickat: den 4 mars 2007 11:32
Till: wireshark-dev@wireshark.org
Ämne: Re: [Wireshark-dev] User information in the packet
Hi,
Thanks for the attachment.
Unfortunately, I could not make much use of it.
I need to test proprietary information, which is added as a data item in the
GSMMAP asn file.
All I could see in the interrogate_ss packet is its dialogue portion has
destination origination references.
My point is: in that portion of dialogue, can I transfer proprietary
information?
Best Regards,
Bhavani
From: [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 17:21:48 +0100
You can have a look to the following message.
I think it should help you.
(See attached file: interrogate_ss.cap.gz)
Regards
Florent
durgabhavani.uppuluru
To:
[EMAIL PROTECTED]
Sent by:
cc:
[EMAIL PROTECTED] Subject:
[Wireshark-dev] User information in the packet
reshark.org
02/03/2007
07:14
Please respond
to
Developer support
list
for
Wireshark
Hi,
How to transfer proprietary information in TCAP?
Can the packet contain component portion?
Can it also contain MAP OPEN information along with proprietary information
in the dialogue portion?
I'm using GSMMAP as TC user.
Any hints are welcome.
Thanks in advance.
Best Regards,
Bhavani
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Fwd: H.223 over rtp]
Of course
Committed revision 20975.
Best regards
Anders
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Richard van der Hoff
Skickat: den 5 mars 2007 13:47
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] [Fwd: H.223 over rtp]
Anders Broman wrote:
Committed revision 20935.
Thanks for all that, Anders.
Would it be possible for my colleague Dave Butt (who did much of the
work for this) to get a credit in the AUTHORS file?
I've attached a patch.
-Ursprungligt meddelande-
Från: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] För Richard van der Hoff
Skickat: den 26 februari 2007 18:28
Till: Developer support list for Wireshark
Ämne: [Wireshark-dev] [Fwd: H.223 over rtp]
Now that the predependent patches for this have been applied (thanks for
all that, Anders), please could this one be applied?
Original Message
Subject: [Wireshark-dev] H.223 over rtp
Date: Tue, 20 Feb 2007 12:29:45 +
From: Richard van der Hoff [EMAIL PROTECTED]
Reply-To: Developer support list for Wireshark
wireshark-dev@wireshark.org
To: Developer support list for Wireshark wireshark-dev@wireshark.org
This patch registers H.223 as a dissector for RTP CLEARMODE payloads -
and makes some other modifications to the H.223 dissector to make this
work correctly.
It assumes that both my earlier patches to the H.223 dissector ('H.223
dissector - separate bitswapping into separate dissector' and 'h.223
robustness fixes') have been applied; it also depends on my
'defragmentation over RTP' patch (submitted on 16/2/2007) for correct
operation.
I've added some sample captures to the wiki.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
Richard van der Hoff [EMAIL PROTECTED]
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
