Re: [Wireshark-dev] [Wireshark-commits] rev 20918: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-ndr.c packet-dcerpc-winreg.c packet-dcerpc.h
On Sun, Feb 25, 2007 at 01:34:42AM +, [EMAIL PROTECTED] wrote: Log: add new PIDL friendly helpers for dissection of integer types. these new helpers take a parameter that can be used to decorate the tree and summary line (when this parameter is acted upon/implemented in the code inside the helpers) WINREG was regenerated using a patched version of PIDL. Mainline version of PIDL does not yet have this patch applied. I've just updated ws to samba head. make test seems to fail with: tests/wireshark-ndr...ok 1/11Can't use string (hf_bla) as a HASH ref while strict refs in use at /home/jmayer/work/wireshark/trunk/tools/pidl/tests/../lib/Parse/Pidl/Wireshark/NDR.pm line 1067. # Looks like your test died just after 11. Is this normal? ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] What do you use to get a boolean
Steve, Its more what the documentation does not say that caused me the problem. The function is called 'add_boolean' and it has a parameter 'value'. I had assumed, incorrectly, that 'value' would be a 1 or a 0. It is not, it is the value of the packet byte that requires to be masked and shifted to get the boolean. It would be helpful if the documentation defined 'value' more explicitly. Also Wireshark has functions which do the masking and shifting to get the boolean value. It would be helpful if these functions were exposed in the API so that dissector writers can use them. If I want to find the actual boolean value of the field I have to write my own functions for masking and shifting. That is not a big issue, but it is duplicating existing code, requires testing and is another source of bugs - better to use the Wireshark functions if they could be made available. I hope this is helpful, the effort required to generate documentation is much appreciated and how Wireshark works is gradually starting to clik into place in my mind. Hal. From: Stephen Fisher [EMAIL PROTECTED] Reply-To: Developer support list for Wireshark wireshark-dev@wireshark.org To: Developer support list for Wireshark wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] What do you use to get a boolean Date: Wed, 21 Feb 2007 23:25:44 -0800 On Mon, Feb 12, 2007 at 06:15:43AM -0900, Hal Lander wrote: It does look like the value you pass to proto_tree_add_boolean(tree, id, tvb, start, length, value); is not a 1 or a 0 it is the raw data byte containing the boolean at the position defined by the mask. If I am correct this makes the documentation a bit missleading. As Guy said, you have to do the masking yourself. What part of the documentation did you find misleading? I ask so that we can take a look at improving it. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev _ Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE. http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] What do you use to get a boolean
Hi, Reading from README.developer it states: quote For proto_tree_add_boolean(), the 'value' argument is a 32-bit integer; zero means false, and non-zero means true. /quote That is misleading. You have to take into account the field info to determine the interpretation of this value (see epan/proto.c : proto_tree_set_uint() ). You can define a mask of the relevant bit(s) and this will be applied (mask AND shift) before adding the value to the tree. So how about this text for README.developer: quote For proto_tree_add_boolean(), the 'value' argument is a 32-bit integer. It is masked and shifted as defined by the field info, then zero means false, and non-zero means true. /quote Thanx, Jaap On Mon, 26 Feb 2007, Hal Lander wrote: Steve, Its more what the documentation does not say that caused me the problem. The function is called 'add_boolean' and it has a parameter 'value'. I had assumed, incorrectly, that 'value' would be a 1 or a 0. It is not, it is the value of the packet byte that requires to be masked and shifted to get the boolean. It would be helpful if the documentation defined 'value' more explicitly. Also Wireshark has functions which do the masking and shifting to get the boolean value. It would be helpful if these functions were exposed in the API so that dissector writers can use them. If I want to find the actual boolean value of the field I have to write my own functions for masking and shifting. That is not a big issue, but it is duplicating existing code, requires testing and is another source of bugs - better to use the Wireshark functions if they could be made available. I hope this is helpful, the effort required to generate documentation is much appreciated and how Wireshark works is gradually starting to clik into place in my mind. Hal. From: Stephen Fisher [EMAIL PROTECTED] Reply-To: Developer support list for Wireshark wireshark-dev@wireshark.org To: Developer support list for Wireshark wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] What do you use to get a boolean Date: Wed, 21 Feb 2007 23:25:44 -0800 On Mon, Feb 12, 2007 at 06:15:43AM -0900, Hal Lander wrote: It does look like the value you pass to proto_tree_add_boolean(tree, id, tvb, start, length, value); is not a 1 or a 0 it is the raw data byte containing the boolean at the position defined by the mask. If I am correct this makes the documentation a bit missleading. As Guy said, you have to do the masking yourself. What part of the documentation did you find misleading? I ask so that we can take a look at improving it. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev _ Play Flexicon: the crossword game that feeds your brain. PLAY now for FREE.? http://zone.msn.com/en/flexicon/default.htm?icid=flexicon_hmtagline ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] U3 package fails to install
I built a U3 version from SVN 20915, but the resulting .u3p fails to install on my SanDisk MicroCruzer. When I run the U3 add programs applet, it reports: U3 Launchpad failed to install U3 program, due to a possible error in the program package. Try downloading and installing the program again. If the problem persists, contact the program software vendor. The version of U3 Launchpad in use is 1.4.0.2 -- Regards, Graham Bloice Software Developer Trihedral UK Limited Tel: +44 (0)7002 874433 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH] Short section on building RPM for developers 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 don't have them, because I don't know (although it references www.rpm.org http://www.rpm.org/ ). It's an incremental improvement on XXX - I don't 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 __ www.detica.com file:///M:\exchweb\bin\redir.asp?URL=http://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. rpm.patch Description: rpm.patch ___ 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 Anders, Hex value shown, in the bytes pane is 99. I've tried other numbers too (150) and I get similar result. Best Regards, Bhavani. From: Anders Broman [EMAIL PROTECTED] mailto:[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. I'm 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. 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] Mixed application contexts in MAP
Hi, I'm adding proprietary operations application contexts to GSMMAP. I'm updating the same GSMMAP.asn file with the operations. Please let me know whether I can add them directly, to the GSMMAP file or not. I couldn't find the below PlmnContainer in the wireshark soure. Did you mean the below 'line' to be an example? Best Regards, Bhavani From: Anders Broman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Date: Sun, 25 Feb 2007 20:01:34 +0100 Hi,, I'm 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 From: DurgaBhavani Uppuluru Sent: Sunday, February 25, 2007 6:17 PM To: 'wireshark-dev@wireshark.org' Subject: 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] local operation code in MAP
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: den 26 februari 2007 06:16
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] local operation code in MAP
Hi Anders,
Hex value shown, in the bytes pane is 99.
I've tried other numbers too (150) and I get similar result.
Best Regards,
Bhavani.
From: Anders Broman [EMAIL PROTECTED]
mailto:[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.
I'm 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.
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] Mixed application contexts in MAP
Hi, Are you using the 0.99.5 sources or a fresh SVN checkout? That code is only in the latest sources I think. Best regards Anders From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: den 26 februari 2007 11:45 To: wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] Mixed application contexts in MAP Hi, I'm adding proprietary operations application contexts to GSMMAP. I'm updating the same GSMMAP.asn file with the operations. Please let me know whether I can add them directly, to the GSMMAP file or not. I couldn't find the below PlmnContainer in the wireshark soure. Did you mean the below 'line' to be an example? Best Regards, Bhavani From: Anders Broman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Date: Sun, 25 Feb 2007 20:01:34 +0100 Hi,, I'm 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 From: DurgaBhavani Uppuluru Sent: Sunday, February 25, 2007 6:17 PM To: 'wireshark-dev@wireshark.org' Subject: 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] U3 package fails to install
Graham Bloice wrote: I built a U3 version from SVN 20915, but the resulting .u3p fails to install on my SanDisk MicroCruzer. When I run the U3 add programs applet, it reports: U3 Launchpad failed to install U3 program, due to a possible error in the program package. Try downloading and installing the program again. If the problem persists, contact the program software vendor. The version of U3 Launchpad in use is 1.4.0.2 I'm also unable to install either a home built version from the latest SVN (20933) or the buildbot version of the same. -- Regards, Graham Bloice Software Developer Trihedral UK Limited Tel: +44 (0)7002 874433 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 20908: /trunk/ /trunk/epan/dissectors/: packet-h248.c packet-h248.h packet-h248_3gpp.c packet-h248_annex_c.c packet-h248_annex_e.c packet-h248_q1950.c packe
I got it clear now. But I have thought of another way to relate both sides: TSN. Other than the table indexed by [spt,dpt,vtag] from where we look for known half associations we can have a table indexed by (spt,dpt,highest_tsn_seen_so_far). If we find an entry in that table that is equal to the cummulative_tsn_ack of a sack's half association, its very unlikelly that we get anything but the right other half. I have traces where there's no way to correlate the IP of two different paths. IP_A1-IP_B1 PT_A PT_B VTAG_AB IP_A2-IP_B2 PT_B PT_A VTAG_BA on the other hand for all traces I have TSN values are different (by far) for every direction on every association. Is there any reason why this should not work? n 2/24/07, Michael Tuexen [EMAIL PROTECTED] wrote: Hi Luis, see my comments in-line. Best regards Michael On Feb 23, 2007, at 11:14 PM, Luis Ontanon wrote: It's heuristic, not having the setup of the association. I mantain two tables. pl_table conatinig a list of assocs indexed by port_labels a 32bit label out of the ports being used (low_pt 16 | high_pt) THis will break in scenarios where the same port is used on both sides and on multiple associations. This is pretty common on SIGTRAN szenarios where all sides use the registered port. and plvt_table indexed by port_label and verification_tag of one direction which I assume to be unique. That is OK. Experience has shown that you can use the port number pair and the vtag as an identifier for one direction of an association. if match in plvt_table then we got it. if match on pl_table then for each assoc in list if assoc is missing the other direction then we got this and add it to the plvt_table. if no assoc was found so far this is a new assoc add it to both tables I'm not sure it will always work, but so far (with the traces I have available) it appears to do so... at least the perl prototype against which I played text files derived from captures did. I think what you need to do is the following: - Identify one direction of an association by the pair of port numbers and the v-tag. - Add information about the addresses to it while you are going through the trace file. - Connect both directions based on IP-addresses. For example if you find DATA chunk from A - B and a SACK from B-A, the port numbers are OK, then tie the two association directions together. This is done (and more complex stuff) in the sctp related code in the gtk directory. AFAIU, there's very little chances to have two different associations match... if I actually see it happening I'll start to play the lottery! From what I understand this is pretty likely: You assume that there in randomness in the port numbers. This is recommended in general but not used in the SIGTRAN scenarios. It is pretty likely that multiple association use all the same port number. I have still problems matching the CTSN ack to the right TSN frames without falling in an infinite loop but that's another story. And serial arithmetic makes that a hard thing to deal with. BTW, if you have captures where the counter cycles I would love to have them. Or else I'll have to hope that an association on the lab I'm working stays up long enough and does not catch me unprepared when it happens.Or I'll have to generate fake packets but my experience as a telecom troubleshooter tells me that the fact that something works with generated traffic does not imply it will work in the real world. I think I can provide you with a trace. The BSD stack (which runs on Mac OS X) has a socket option to set the Initial TSN for debugging As per Association Restart I do not think I'll ever implement it, I'll treat the restarted Association as a new one (I need traces for this too, but this given slack time in the lab I can force it to happen). We consider it also a new association... Luis. On 2/23/07, Michael Tuexen [EMAIL PROTECTED] wrote: Hi Lego, I'm wondering how you tie together both directions of an SCTP association? Best regards Michael On Feb 23, 2007, at 8:57 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi? view=revrevision=20908 User: lego Date: 2007/02/23 08:57 PM Log: fix some bugs introduced in the latest releases and add value_strings for param, evt, sig and stat ids s well as sub- parameters. Directory: /trunk/epan/dissectors/ ChangesPath Action +39 -33packet-h248.cModified +20 -14packet-h248.hModified +103 -39 packet-h248_3gpp.c Modified +4 -4 packet-h248_annex_c.cModified +83 -30packet-h248_annex_e.cModified +23 -11packet-h248_q1950.c Modified +486 -52 packet-sctp.cModified Directory: /trunk/asn1/h248/ ChangesPath Action
[Wireshark-dev] [PATCH] README.developer corrections
I posted this a few weeks ago, but I guess it got overlooked. It's some
updates to the section on datagram reassembly in README.developer which
I hope will save someone the confusion I suffered!
Index: README.developer
===
--- README.developer (.../svn+ssh://svn/svn-ethereal/mirror/ethereal/trunk/doc/README.developer) (revision 11728)
+++ README.developer (.../README.developer) (working copy)
@@ -3287,37 +3287,33 @@
The second reassembly mode is preferred when the dissector cannot determine
how many bytes it will need to read in order to determine the size of a PDU.
+It may also be useful if your dissector needs to support reassembly from
+protocols other than TCP.
-This reassembly mode relies on Wireshark's mechanism for processing
-multiple PDUs per frame. When a dissector processes a PDU from a tvbuff
-the PDU may not be aligned to a frame of the underlying protocol.
-Wireshark allows dissectors to process PDUs in an idempotent
-way--dissectors only need to consider one PDU at a time. If your
-dissector discovers that it can not process a complete PDU from the
-current tvbuff the dissector should halt processing and request
-additional bytes from the lower level dissector.
+Your dissect_PROTO will initially be passed a tvbuff containing the payload of
+the first packet. It should dissect as much data as it can, noting that it may
+contain more than one complete PDU. If the end of the provided tvbuff coincides
+with the end of a PDU then all is well and your dissector can just return as
+normal. (If it is a new-style dissector, it should return the number of bytes
+successfully processed.)
-Your dissect_PROTO will be called by the lower level dissector whenever
-sufficient new bytes become available. Each time your dissector is called it is
-provided a different tvbuff, though the tvbuffs may contain data that your
-dissector declined to process during a previous call. When called a dissector
-should examine the tvbuff provided and determine if an entire PDU is available.
-If sufficient bytes are available the dissector processes the PDU and returns
-the length of the PDU from your dissect_PROTO.
+If the dissector discovers that the end of the tvbuff does /not/ coincide with
+the end of a PDU, (ie, there is half of a PDU at the end of the tvbuff), it can
+indicate this to the parent dissector, by updating the pinfo struct. The
+desegment_offset field is the offset in the tvbuff at which the dissector will
+continue processing when next called. The desegment_len field should contain
+the estimated number of additional bytes required for completing the PDU. Next
+time your dissect_PROTO is called, it will be passed a tvbuff composed of the
+end of the data from the previous tvbuff together with desegment_len more bytes.
-Completion of a PDU is signified by dissect_PROTO returning a positive
-value. The value is the number of bytes which were processed from the
-tvbuff. If there were insufficient bytes in the tvbuff to complete a
-PDU then dissect_PROTO must update the pinfo structure to indicate that
-more bytes are required. The desegment_offset field is the offset in
-the tvbuff at which the dissector will continue processing when next
-called. The desegment_len field should contain the estimated number of
-additional bytes required for completing the PDU. The dissect_PROTO
-will not be called again until the specified number of bytes are
-available. pinfo-desegment_len may be set to -1 if dissect_PROTO
-cannot determine how many additional bytes are required. Dissectors
-should set the desegment_len to a reasonable value when possible rather
-than always setting -1 as it will generally be more efficient.
+If the dissector cannot tell how many more bytes it will need, it should set
+desegment_len=DESEGMENT_ONE_MORE_SEGMENT; it will then be called again as soon
+as any more data becomes available. Dissectors should set the desegment_len to a
+reasonable value when possible rather than always setting
+DESEGMENT_ONE_MORE_SEGMENT as it will generally be more efficient. Also, you
+*must not* set desegment_len=1 in this case, in the hope that you can change
+your mind later: once you return a positive value from desegment_len, your PDU
+boundary is set in stone.
static hf_register_info hf[] = {
{hf_cstring,
@@ -3327,7 +3323,7 @@
};
/**
-* Dissect a buffer containing a C string.
+* Dissect a buffer containing C strings.
*
* @param tvb The buffer to dissect.
* @param pinfo Packet Info.
@@ -3336,32 +3332,38 @@
static void dissect_cstr(tvbuff_t * tvb, packet_info * pinfo, proto_tree * tree)
{
guint offset = 0;
-gint available = tvb_reported_length_remaining(tvb, offset);
-gint len = tvb_strnlen(tvb, offset, available);
+while(offset tvb_reported_length(tvb)) {
+gint available = tvb_reported_length_remaining(tvb, offset);
+gint len = tvb_strnlen(tvb,
Re: [Wireshark-dev] U3 package fails to install
Hi, Graham Bloice wrote: I built a U3 version from SVN 20915, but the resulting .u3p fails to install on my SanDisk MicroCruzer. Does the package downloaded from: http://prdownloads.sourceforge.net/wireshark/wireshark-0.99.5.u3p install OK? When I run the U3 add programs applet, it reports: U3 Launchpad failed to install U3 program, due to a possible error in the program package. Try downloading and installing the program again. If the problem persists, contact the program software vendor. The version of U3 Launchpad in use is 1.4.0.2 I'm also unable to install either a home built version from the latest SVN (20933) or the buildbot version of the same. I have seen this sort of error when the manifest.u3i file is corrupt. Have a look at the file in packaging/u3/win32/manifest - or extract it from the u3p using a zip tool. Does it look OK? Graeme ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[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.
Index: plugins/h223/packet-h223.c
===
--- plugins/h223/packet-h223.c (revision 11941)
+++ plugins/h223/packet-h223.c (working copy)
@@ -388,103 +388,168 @@
return vc_info;
}
-static void init_logical_channel( packet_info* pinfo, h223_call_info* call_info, int vc, int direction, h223_lc_params* params )
+static void init_logical_channel( guint32 start_frame, h223_call_info* call_info, int vc, int direction, h223_lc_params* params )
{
guint32 circuit_id = circuit_chain_lookup(call_info, vc);
circuit_t *subcircuit;
h223_vc_info *vc_info;
-subcircuit = find_circuit( CT_H223, circuit_id, pinfo-fd-num );
+subcircuit = find_circuit( CT_H223, circuit_id, start_frame );
if( subcircuit == NULL ) {
-subcircuit = circuit_new( CT_H223, circuit_id, pinfo-fd-num );
+subcircuit = circuit_new( CT_H223, circuit_id, start_frame );
#ifdef DEBUG_H223
-g_debug(%d: Created new circuit %d for call %p VC %d, pinfo-fd-num, circuit_id, call_info, vc);
+g_debug(%d: Created new circuit %d for call %p VC %d, start_frame, circuit_id, call_info, vc);
#endif
vc_info = h223_vc_info_new( call_info );
circuit_add_proto_data( subcircuit, proto_h223, vc_info );
} else {
vc_info = circuit_get_proto_data( subcircuit, proto_h223 );
}
-add_h223_lc_params( vc_info, direction, params, pinfo-fd-num );
+add_h223_lc_params( vc_info, direction, params, start_frame );
}
-static void init_control_channels( packet_info* pinfo, h223_call_info* call_info )
+/* create a brand-new h223_call_info structure */
+static h223_call_info *create_call_info( guint32 start_frame )
{
-h223_lc_params *vc0_params = se_alloc(sizeof(h223_lc_params));
+h223_call_info *data;
+h223_lc_params *vc0_params;
+
+data = se_alloc(sizeof(h223_call_info));
+
+/* initialise the call info */
+init_direction_data(data - direction_data[0]);
+init_direction_data(data - direction_data[1]);
+
+/* FIXME shouldn't this be figured out dynamically? */
+data - h223_level = 2;
+
+vc0_params = se_alloc(sizeof(h223_lc_params));
vc0_params-al_type = al1Framed;
vc0_params-al_params = NULL;
vc0_params-segmentable = TRUE;
vc0_params-subdissector = srp_handle;
-init_logical_channel( pinfo, call_info, 0, P2P_DIR_SENT, vc0_params );
-init_logical_channel( pinfo, call_info, 0, P2P_DIR_RECV, vc0_params );
+init_logical_channel( start_frame, data, 0, P2P_DIR_SENT, vc0_params );
+init_logical_channel( start_frame, data, 0, P2P_DIR_RECV, vc0_params );
+return data;
}
-static h223_call_info *find_or_create_call_info ( packet_info * pinfo )
+/* find or create call_info struct for calls over circuits (eg, IAX) */
+static h223_call_info *find_or_create_call_info_circ(packet_info * pinfo)
{
-circuit_t *circ;
-conversation_t *conv = NULL;
h223_call_info *data;
+circuit_t *circ = NULL;
-/* look for a circuit (eg, IAX call) first */
-circ = find_circuit( pinfo-ctype, pinfo-circuit_id, pinfo-fd-num );
-if( circ == NULL ) {
- /* assume we're running atop TCP; use the converstion support */
- conv = find_conversation( pinfo-fd-num,
- pinfo-src,pinfo-dst,
- pinfo-ptype,
- pinfo-srcport,pinfo-destport, 0 );
- if( conv == NULL ) {
- conv = conversation_new( pinfo-fd-num,
- pinfo-src,pinfo-dst,
- pinfo-ptype,
- pinfo-srcport,pinfo-destport, 0 );
- }
-
+if(pinfo-ctype != CT_NONE)
+circ = find_circuit( pinfo-ctype, pinfo-circuit_id, pinfo-fd-num );
+if(circ == NULL)
+return NULL;
+
+data = (h223_call_info *)circuit_get_proto_data(circ, proto_h223);
+
+if( data == NULL ) {
+data = create_call_info(pinfo-fd-num);
+
+#ifdef DEBUG_H223
+g_debug(%u: Created new call %p for circuit %p ctype %d, id %u,
+pinfo-fd-num, data, circ, pinfo-ctype, pinfo-circuit_id);
[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. Index: epan/Makefile.am === --- epan/Makefile.am (.../svn+ssh://svn/svn-ethereal/mirror/ethereal/trunk) (revision 12016) +++ epan/Makefile.am (working copy) @@ -75,6 +75,7 @@ make-sminmpec.pl \ radius_dict.l \ tvbtest.c \ + reassemble_test.c \ uat_load.l \ exntest.c \ doxygen.cfg.in @@ -104,6 +105,9 @@ libwireshark_la_LIBADD = @G_ASCII_STRTOULL_LO@ @INET_ATON_LO@ @INET_PTON_LO@ @INET_NTOP_LO@ crypt/libairpdcap.la ftypes/libftypes.la dfilter/libdfilter.la dissectors/libdissectors.la $(wslua_lib) @ADNS_LIBS@ @LIBGNUTLS_LIBS@ @LIBICONV@ @KRB5_LIBS@ @SNMP_LIBS@ @SSL_LIBS@ -lm libwireshark_la_DEPENDENCIES = @G_ASCII_STRTOULL_LO@ @INET_ATON_LO@ @INET_PTON_LO@ @INET_NTOP_LO@ crypt/libairpdcap.la ftypes/libftypes.la dfilter/libdfilter.la dissectors/libdissectors.la $(wslua_lib) +EXTRA_PROGRAMS = reassemble_test +reassemble_test_LDADD = $(GLIB_LIBS) libwireshark.la + tvbtest: tvbtest.o tvbuff.o except.o strutil.o emem.o $(LINK) $^ $(GLIB_LIBS) -lz ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 20908: /trunk/ /trunk/epan/dissectors/: packet-h248.c packet-h248.h packet-h248_3gpp.c packet-h248_annex_c.c packet-h248_annex_e.c packet-h248_q1950.c packe
Comments in-line. Best regards Michael On Feb 26, 2007, at 5:32 PM, Luis Ontanon wrote: I got it clear now. But I have thought of another way to relate both sides: TSN. Other than the table indexed by [spt,dpt,vtag] from where we look for known half associations we can have a table indexed by (spt,dpt,highest_tsn_seen_so_far). If we find an entry in that table that is equal to the cummulative_tsn_ack of a sack's half association, its very unlikelly that we get anything but the right other half. You are assuming one thing: You do not see multiple association using the ame TSN range. This is true when 1. you have short captures 2. the initial TSN is selected by random The second point is true for a lot of implementations but I know of implementations which always start with TSN=0. This is fully compliant with the SCTP spec. I have traces where there's no way to correlate the IP of two different paths. IP_A1-IP_B1 PT_A PT_B VTAG_AB IP_A2-IP_B2 PT_B PT_A VTAG_BA Are you sure? Are you talking about two end-points A and B having port number PT_A and PT_B. So the situation should look like IP_A1-IP_B1 PT_A PT_B VTAG_AB IP_B2-IP_A2 PT_B PT_A VTAG_BA RFC 2960 states that if a packet with DATA chunks is sent from IP_A1 to IP_B1 the corresponding SACK should be sent to IP_A1. But this might not apply if both send continuously data and A uses IP_B1 as its primary and B uses A_2 as its primary path. This is valid. However, this would mean the A should send HEARTBEATS to IP_B2. and you should be able to tie both halves together by these messages. So I think the following would be appropriate: - consider triple od src port, dst port and v-tag identifying half associations. - use the addresses to typ two half associations together by looking at at INIT-ACK chunks, DATA/SACK pairs, HEARTBEAT/HEARTBEAT-ACK pairs, INIT-ACK/COOKIE pairs, COOKIE/COOKIE-ACK pairs. The pairing is based on IP-addresses. This should be a pretty good heuristic. If you are not able to tie two half associations together, you could try to use DATA/SACK paris based on TSN, as you are suggesting. But I would only do this if the above does not work out. This heuristic makes assumptions which are not covered by the RFC, but if you only us it when the rest is not working, it is better to do something which is possibly wrong, than to do nothing. on the other hand for all traces I have TSN values are different (by far) for every direction on every association. Is there any reason why this should not work? n 2/24/07, Michael Tuexen [EMAIL PROTECTED] wrote: Hi Luis, see my comments in-line. Best regards Michael On Feb 23, 2007, at 11:14 PM, Luis Ontanon wrote: It's heuristic, not having the setup of the association. I mantain two tables. pl_table conatinig a list of assocs indexed by port_labels a 32bit label out of the ports being used (low_pt 16 | high_pt) THis will break in scenarios where the same port is used on both sides and on multiple associations. This is pretty common on SIGTRAN szenarios where all sides use the registered port. and plvt_table indexed by port_label and verification_tag of one direction which I assume to be unique. That is OK. Experience has shown that you can use the port number pair and the vtag as an identifier for one direction of an association. if match in plvt_table then we got it. if match on pl_table then for each assoc in list if assoc is missing the other direction then we got this and add it to the plvt_table. if no assoc was found so far this is a new assoc add it to both tables I'm not sure it will always work, but so far (with the traces I have available) it appears to do so... at least the perl prototype against which I played text files derived from captures did. I think what you need to do is the following: - Identify one direction of an association by the pair of port numbers and the v-tag. - Add information about the addresses to it while you are going through the trace file. - Connect both directions based on IP-addresses. For example if you find DATA chunk from A - B and a SACK from B-A, the port numbers are OK, then tie the two association directions together. This is done (and more complex stuff) in the sctp related code in the gtk directory. AFAIU, there's very little chances to have two different associations match... if I actually see it happening I'll start to play the lottery! From what I understand this is pretty likely: You assume that there in randomness in the port numbers. This is recommended in general but not used in the SIGTRAN scenarios. It is pretty likely that multiple association use all the same port number. I have still problems matching the CTSN ack to the right TSN frames without falling in an infinite loop but that's another story. And serial arithmetic makes that a hard thing to deal with. BTW, if you have captures where the
Re: [Wireshark-dev] [Patch] Add Copy as Filter to the detail-pane context menu
On Sat, Feb 24, 2007 at 09:17:20AM +0100, Sake Blok wrote: Hi, Many times I find myself using prepare as filter, just to copy the filter to another instance of wireshark with a second trace (think of selecting the tcp.seq to match packets between two traces). As this distroys the filter that was currently active, I wrote a little patch that adds a Copy as Filter item to the context-menu in the detail-view. Could someone review this patch and add it to the trunk? I took another look at all the sources (grepping for Apply as) and updated the following files with the Copy as Filter functionality: ./doc/wireshark.pod ./docbook/wsug_src/WSUG_chapter_work.xml ./docbook/wsug_src/WSUG_chapter_use.xml ./gtk/menu.c ./gtk/main.c ./gtk/main.h I did not change the following files: ./gtk/expert_comp_table.c ./gtk/service_response_time_table.c ./gtk/conversations_table.c ./gtk/hostlist_table.c Personally I don't need the Copy as Filter there. But if other people would like it there also (or if it should be there because of GUI- consistency) I'm more than happy to spend some more time to implement it there also. Please also note that I did not use the and|or|not|... options since it would be unclear if the new filter string would be merged with the clipboard or the filter currently in the filter strip. Also it would not add any value imho. Please review this second patch (and discard the first one) and add it to the trunk if it is found useful :) Cheers, Sake Index: doc/wireshark.pod === --- doc/wireshark.pod (revision 20934) +++ doc/wireshark.pod (working copy) @@ -970,30 +970,34 @@ Edit the saved list of display filters, allowing filters to be added, changed, or deleted. -=item Analyze:Apply as Filter +=item Analyze:Copy as Filter -Create a display filter, or add to the display filter strip at the -bottom, a display filter based on the data currently highlighted in the -packe details, and apply the filter. +Create a display filter based on the data currently highlighted in the +packet details and copy that filter to the clipboard. If that data is a field that can be tested in a display filter expression, the display filter will test that field; otherwise, the -display filter will be based on absolute offset within the packet, and -so could be unreliable if the packet contains protocols with +display filter will be based on the absolute offset within the packet. +Therefore it could be unreliable if the packet contains protocols with variable-length headers, such as a source-routed token-ring packet. +=item Analyze:Apply as Filter + +Create a display filter based on the data currently highlighted in the +packet details and apply the filter. + The BSelected option creates a display filter that tests for a match of the data; the BNot Selected option creates a display filter that tests for a non-match of the data. The BAnd Selected, BOr Selected, BAnd Not Selected, and BOr Not Selected options add to the end of -the display filter in the strip at the bottom an AND or OR operator -followed by the new display filter expression. +the display filter in the strip at the top (or bottom) an AND or OR +operator followed by the new display filter expression. =item Analyze:Prepare a Filter -Create a display filter, or add to the display filter strip at the -bottom, a display filter based on the data currently highlighted in the -packet details, but don't apply the filter. +Create a display filter based on the data currently highlighted in the +packet details. The filter strip at the top (or bottom) is updated but +it is not yet applied. =item Analyze:Enabled Protocols Index: docbook/wsug_src/WSUG_chapter_work.xml === --- docbook/wsug_src/WSUG_chapter_work.xml (revision 20934) +++ docbook/wsug_src/WSUG_chapter_work.xml (working copy) @@ -101,6 +101,16 @@ entry/entry /row row + entrycommandCopy as Filter/command/entry + entryAnalyze/entry + entry + para + Prepare a display filter based on the currently selected item + but copy it to the clipboard. + /para + /entry + /row + row entrycommandApply as Filter/command/entry entryAnalyze/entry entry @@ -430,6 +440,16 @@ entry/entry /row row + entrycommandCopy as Filter/command/entry + entryAnalyze/entry + entry + para + Prepare a display filter based on the currently selected item + but copy it to the clipboard. + /para + /entry + /row + row entrycommandApply as Filter/command/entry
Re: [Wireshark-dev] [Patch] Add Copy as Filter to the detail-pane context menu
On Mon, Feb 26, 2007 at 11:30:30PM +0100, Sake Blok wrote: On Sat, Feb 24, 2007 at 09:17:20AM +0100, Sake Blok wrote: Please review this second patch (and discard the first one) and add it to the trunk if it is found useful :) Oops, I see that I did not test this patch properly... please ignore it for now. I will work on it some more until it does exactly what I intend it to do :) Cheers, Sake ___ 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,
I'm using wireshark 0.99.5 sources.
The below code is right.
I've 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]
mailto:[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.
I've tried other numbers too (150) and I get similar result.
Best Regards,
Bhavani.
From: Anders Broman [EMAIL PROTECTED]
mailto:[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.
I'm 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.
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
[Wireshark-dev] Regarding Dissector
Hi all, I used ethereal / wireshark to sniffing WLAN ( IEEE 802.11 ) packet. Now for some of my research purpose i like to add a new dissector. I red through README.developer of dissector. I am not clear how to add a new protocol and also the flow of packet in the ethereal / wireshark I like to know is there is any other document to understand better way or how i can start going through the code. Please help me. Thank You -- Vipin M MS ( By Research ) Student, AU - KBC Research Centre, MIT Campus, Anna University, Chrompet, Chennai, India - 600 044 Tel/Fax : 91-44-2223-2711 /4885 /1034 /6958 /6959 Ext No : 29 Url : http://comm.au-kbc.org ___ 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] local operation code in MAP
Hi Again,
I've tried latest svn version files too, still I get the same problem.
I've 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,
I'm using wireshark 0.99.5 sources.
The below code is right.
I've 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]
mailto:[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.
I've tried other numbers too (150) and I get similar result.
Best Regards,
Bhavani.
From: Anders Broman [EMAIL PROTECTED]
mailto:[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.
I'm 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.
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] [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
