Re: [Wireshark-dev] [Wireshark-commits] rev 21195: /trunk/ /trunk/: configure.in
Me and automake/configure are not on friendly terms. Is there someone who is on friendly terms with them? ;) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] gsm_map dissector question
Hi List, I have been capturing and decoding some live traffic on a GSM network, and find a problem in decoding of GSM MAP operations. The GSM MAP dissector is currently based on 3GPP TS 29.002 v7.5.0. This leads to incorrect decoding of packets which are working on lower MAP versions. For example, a MAP v2 ShortMsgMT-Relay gets decoded as MAP v3 ShortMsgMO-Relay (because the opcodes are same). This leads to all kinds of warnings, and sometimes incorrect decoding. I don't suppose there is a (simple) way around this, is there? I guess a complex (and resource hungry) method would be for the TCAP dissector to follow dialogs and then pass the application context information to the MAP dissector for MAP to interpret the operation based on the application context in addition to the op-code. I am sorry if this has already been discussed, I searched the archives, but could not find anything relevant... perhaps I didn't use the correct search string. Thanks, Abhik. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH][UPDATE] analyzing SHIM6 protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I did indeed! I deleted a line that didn't matter, but screwed up the accounting numbers apparently. It is now fixed. Regards, Matthijs Sebastien Tandel wrote: Hi, your patch is malformed line 63. You've probably deleted some hf_items or some comments directly in the patch but that must be reflected in the accounting numbers of the patch format ;) Regards, Sebastien Tandel Matthijs Mekking wrote: Thanks for the advice. I have attached a new patch, were you can apply shim6 elements as filter easier. more info at www.pletterpet.nl/shim6/ Regards, Matthijs Mekking [EMAIL PROTECTED] NLNetLabs Amsterdam / Radboud University Nijmegen Sebastien Tandel wrote: I think most the proto_tree_add_text could be replaced by proto_tree_add_item which could allow (i.e. at least Sébastien Barré ;)) to perform an easy search on specific items. ;) Regards, Sebastien Tandel Matthijs Mekking wrote: Hello, The last two months I have been working on a SHIM6 enabled version of Wireshark. The subject of my final thesis is about SHIM6 and I needed to analyze the SHIM6 communication exchange. SHIM6 is an IPv6 based solution for multihoming.(www.shim6.org) SHIM6 is handled as an IPv6 extension header. So I have changed the source and header files of packet-ipv6. I have added dissecting functions for different the message formats of the SHIM6 protocol. I also needed to change the ipproto files to add the new extension header. The included patch is pretty clear about that. The message formats are conform the latest draft specification of SHIM6: http://tools.ietf.org/html/draft-ietf-shim6-proto-07 http://tools.ietf.org/html/draft-ietf-shim6-failure-detection-07 Regards, Matthijs Mekking [EMAIL PROTECTED] NLNetLabs Amsterdam / Radboud University Nijmegen ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGB4BUNiaStnTWEtYRAkKYAJ4xHOE+wwI4MPdd2hLeL95KHwosZACgmTvu khifVtUswHRLvaJDr9h9Q8c= =b38s -END PGP SIGNATURE- ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21195: /trunk/ /trunk/: configure.in
Thanks sorry for the trouble. Unfortunately something was stripping the []'s out of the test in configure.in so the resulting configure just had if $? == 0 ; which didn't work. I just checked in a new version which should work for everyone. ronnie sahlberg wrote: I just checked in a different test for configure.in in trunk that works for me. Please review. On 3/26/07, Jeff Morriss [EMAIL PROTECTED] wrote: Hmmm, that's weird, it works for me. What version of GCC are you using? What does: echo yes | gcc -E -Wfoodeclaration-after-statement - produce for you? For me I get only: cc1: error: unrecognized command line option -Wfoodeclaration-after-statement # 1 stdin (but no yes). Oh, OK, it looks like older versions of GCC (I just tried 3.2) don't error out when presented an invalid command line argument. Hmmm, at least it should still compile on those GCC versions, but now I have to think of a different test... ronnie sahlberg wrote: The checks in configure.in for this doesnt work properly for GCC versions which do not support this -W directive. Eventhough it is not supported by GCC AC_MSG_CHECKING(to see if we can add '-Wdeclaration-after-statement'... still adds it to the compile flags. I will see if i can figure out why the test fails. Me and automake/configure are not on friendly terms. On 3/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21195 User: morriss Date: 2007/03/26 12:32 AM Log: If we're using gcc, try to use -Wdeclaration-after-statement to catch more non-portable commits. I'm not sure if this is the Right Way to test to see if the compiler can handle a specific option but it's simple and efficient enough. Directory: /trunk/ ChangesPathAction +8 -0 configure.inModified ___ 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
Re: [Wireshark-dev] [Wireshark-commits] rev 21195: /trunk/ /trunk/: configure.in
Note that '==' is not portable on BSD unix. Jeff Morriss wrote: Thanks sorry for the trouble. Unfortunately something was stripping the []'s out of the test in configure.in so the resulting configure just had if $? == 0 ; which didn't work. I just checked in a new version which should work for everyone. ronnie sahlberg wrote: I just checked in a different test for configure.in in trunk that works for me. Please review. On 3/26/07, Jeff Morriss [EMAIL PROTECTED] wrote: Hmmm, that's weird, it works for me. What version of GCC are you using? What does: echo yes | gcc -E -Wfoodeclaration-after-statement - produce for you? For me I get only: cc1: error: unrecognized command line option -Wfoodeclaration-after-statement # 1 stdin (but no yes). Oh, OK, it looks like older versions of GCC (I just tried 3.2) don't error out when presented an invalid command line argument. Hmmm, at least it should still compile on those GCC versions, but now I have to think of a different test... ronnie sahlberg wrote: The checks in configure.in for this doesnt work properly for GCC versions which do not support this -W directive. Eventhough it is not supported by GCC AC_MSG_CHECKING(to see if we can add '-Wdeclaration-after-statement'... still adds it to the compile flags. I will see if i can figure out why the test fails. Me and automake/configure are not on friendly terms. On 3/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21195 User: morriss Date: 2007/03/26 12:32 AM Log: If we're using gcc, try to use -Wdeclaration-after-statement to catch more non-portable commits. I'm not sure if this is the Right Way to test to see if the compiler can handle a specific option but it's simple and efficient enough. Directory: /trunk/ ChangesPathAction +8 -0 configure.inModified ___ 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
Re: [Wireshark-dev] [PATCH][UPDATE] analyzing SHIM6 protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I did indeed. I fixed the patch. Regards, Matthijs Sebastien Tandel wrote: Hi, your patch is malformed line 63. You've probably deleted some hf_items or some comments directly in the patch but that must be reflected in the accounting numbers of the patch format ;) Regards, Sebastien Tandel Matthijs Mekking wrote: Thanks for the advice. I have attached a new patch, were you can apply shim6 elements as filter easier. more info at www.pletterpet.nl/shim6/ Regards, Matthijs Mekking [EMAIL PROTECTED] NLNetLabs Amsterdam / Radboud University Nijmegen Sebastien Tandel wrote: I think most the proto_tree_add_text could be replaced by proto_tree_add_item which could allow (i.e. at least Sébastien Barré ;)) to perform an easy search on specific items. ;) Regards, Sebastien Tandel Matthijs Mekking wrote: Hello, The last two months I have been working on a SHIM6 enabled version of Wireshark. The subject of my final thesis is about SHIM6 and I needed to analyze the SHIM6 communication exchange. SHIM6 is an IPv6 based solution for multihoming.(www.shim6.org) SHIM6 is handled as an IPv6 extension header. So I have changed the source and header files of packet-ipv6. I have added dissecting functions for different the message formats of the SHIM6 protocol. I also needed to change the ipproto files to add the new extension header. The included patch is pretty clear about that. The message formats are conform the latest draft specification of SHIM6: http://tools.ietf.org/html/draft-ietf-shim6-proto-07 http://tools.ietf.org/html/draft-ietf-shim6-failure-detection-07 Regards, Matthijs Mekking [EMAIL PROTECTED] NLNetLabs Amsterdam / Radboud University Nijmegen ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGB4diNiaStnTWEtYRAhp3AJwJnIepZKHOdyfWhwsfCMKnpalTggCgkFB0 u85t1UcbAfL1lRXeqRHYN3A= =+Juy -END PGP SIGNATURE- ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] gsm_map dissector question
Hi, If you could supply a sample trace we could see what can be done. Best regards Anders From: [EMAIL PROTECTED] on behalf of Abhik Sarkar Sent: Mon 3/26/2007 9:49 AM To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] gsm_map dissector question Hi List, I have been capturing and decoding some live traffic on a GSM network, and find a problem in decoding of GSM MAP operations. The GSM MAP dissector is currently based on 3GPP TS 29.002 v7.5.0. This leads to incorrect decoding of packets which are working on lower MAP versions. For example, a MAP v2 ShortMsgMT-Relay gets decoded as MAP v3 ShortMsgMO-Relay (because the opcodes are same). This leads to all kinds of warnings, and sometimes incorrect decoding. I don't suppose there is a (simple) way around this, is there? I guess a complex (and resource hungry) method would be for the TCAP dissector to follow dialogs and then pass the application context information to the MAP dissector for MAP to interpret the operation based on the application context in addition to the op-code. I am sorry if this has already been discussed, I searched the archives, but could not find anything relevant... perhaps I didn't use the correct search string. Thanks, Abhik. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev winmail.dat___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compilation failure on MSVC 6.0 with Platform SDK
Ulf Lamping wrote: Graham Bloice wrote: When compiling with MSVC 6.0 and the platform SDK, there are failures due to the redefinition of sockaddr_storage in capture_wpcap_packet.c and gtk/capture_if_details_dlg.c. The definition is conditional on the version of MSVC used, whereas the actual definition depends on the version of winsock defined, which is indicated by the symbol _WINSOCK2API_. I think that using this symbol would be preferable. Ah, thanks for pointing this out. At the time I was implementing this, I got the strong feeling that there might be a better way - but I was just too lazy to find out :-) I've updated both files in SVN 21162. Could you have a try if it works with MSVC 6 SDK? BTW: Is this official MSDN, or something you've got from the include files? From the include files. I haven't been able to check your changes yet, but I imagine that they are close to my tests so that they should be OK. I'll check tomorrow. -- Regards, Graham Bloice ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH][UPDATE] analyzing SHIM6 protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, - in hf_register_info, there are two items of the same name : hf_ipv6_shim6_opt_len This is fixed in the source and in the patch. - you should create an helper function to add hf_ipv6_shim6_ct to the tree. I know, but at the moment I don't have the time to figure that out. - instead of dissect_shim_ip_addr, use proto_tree_add_item/proto_tree_add_ipv6. The type of the item is then FT_IPv6. Replaced all occurences of dissect_shim_ip_addr. In two weeks time I should have more time. Than I will look at the hf_ipv6_shim6_ct. Expect a new patch at that time. Regards, Matthijs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGB5JpNiaStnTWEtYRAhopAKC+IftlWBK+fuT0p3n9S9s8xD0E+wCcCdc3 eqOz1UMNMsmM0xc6n+T/r6c= =Fm6B -END PGP SIGNATURE- ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] gsm_map dissector question
Hi Anders, Thanks for your reply. Attached are sample captures. The MSUs are syslog encapsulated, so you need to be running SVN rev 21109 or higher. Decode UDP destination port 7890 as syslog and you will see the MTP3 and higher layers. example1.cap : A simple MAPv2 mt-fsm showing up as mo-fsm. example2.cap : The gsm_map dissector throwing up a BER decode error because it thinks there are some extra invalid field beyond the sm-RP-UI of the mo-fsm, but the extra field is actually the more-messages-to-send flag in a MAPv2 mt-fsm. I had one more example, but I can't find it anymore. I will send it on if I do find it. Best regards, Abhik. On 3/26/07, Anders Broman (AL/EAB) [EMAIL PROTECTED] wrote: Hi, If you could supply a sample trace we could see what can be done. Best regards Anders From: [EMAIL PROTECTED] on behalf of Abhik Sarkar Sent: Mon 3/26/2007 9:49 AM To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] gsm_map dissector question Hi List, I have been capturing and decoding some live traffic on a GSM network, and find a problem in decoding of GSM MAP operations. The GSM MAP dissector is currently based on 3GPP TS 29.002 v7.5.0. This leads to incorrect decoding of packets which are working on lower MAP versions. For example, a MAP v2 ShortMsgMT-Relay gets decoded as MAP v3 ShortMsgMO-Relay (because the opcodes are same). This leads to all kinds of warnings, and sometimes incorrect decoding. I don't suppose there is a (simple) way around this, is there? I guess a complex (and resource hungry) method would be for the TCAP dissector to follow dialogs and then pass the application context information to the MAP dissector for MAP to interpret the operation based on the application context in addition to the op-code. I am sorry if this has already been discussed, I searched the archives, but could not find anything relevant... perhaps I didn't use the correct search string. Thanks, Abhik. ___ 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 example1.cap Description: Binary data example2.cap Description: Binary data ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH] bunch of warnings fixes
One big patch is provided to apply all the changes. It contains warnings fixes and removed some declarations after statement too. I also provide patch-per-file.tar.gz containing one patch for each file affected by big patch, in case some modifs have been committed on one of these files : packet-alcap packet-ansi_637 packet-ansi_a packet-atalk packet-beep packet-ber packet-bootp packet-bpdu packet-bthci_acl packet-btsdp packet-cops packet-cups packet-ssh packet-synergy packet-t38 packet-tacacs packet-tali packet-tcp packet-tds packet-telnet packet-ucp packet-uma packet-vtp packet-wbxml packet-who packet-x11 packet-x25 packet-xdmcp packet-xml packet-yhoo Regards, Sebastien Tandel rev21208-dissectors-warnings-fixes.diff.gz Description: application/gzip patch-per-file.tar.gz Description: application/gzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] gsm_map dissector question
Hi, In which specification is mt-fsm(MT-ForwardSM?) given with Opcode 46? I supose a solution would be to introduce a preference if MAPv2 or V3 is used. I have little time to look at this currently. Best regards Anders -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Abhik Sarkar Sent: den 26 mars 2007 11:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] gsm_map dissector question Hi Anders, Thanks for your reply. Attached are sample captures. The MSUs are syslog encapsulated, so you need to be running SVN rev 21109 or higher. Decode UDP destination port 7890 as syslog and you will see the MTP3 and higher layers. example1.cap : A simple MAPv2 mt-fsm showing up as mo-fsm. example2.cap : The gsm_map dissector throwing up a BER decode error because it thinks there are some extra invalid field beyond the sm-RP-UI of the mo-fsm, but the extra field is actually the more-messages-to-send flag in a MAPv2 mt-fsm. I had one more example, but I can't find it anymore. I will send it on if I do find it. Best regards, Abhik. On 3/26/07, Anders Broman (AL/EAB) [EMAIL PROTECTED] wrote: Hi, If you could supply a sample trace we could see what can be done. Best regards Anders From: [EMAIL PROTECTED] on behalf of Abhik Sarkar Sent: Mon 3/26/2007 9:49 AM To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] gsm_map dissector question Hi List, I have been capturing and decoding some live traffic on a GSM network, and find a problem in decoding of GSM MAP operations. The GSM MAP dissector is currently based on 3GPP TS 29.002 v7.5.0. This leads to incorrect decoding of packets which are working on lower MAP versions. For example, a MAP v2 ShortMsgMT-Relay gets decoded as MAP v3 ShortMsgMO-Relay (because the opcodes are same). This leads to all kinds of warnings, and sometimes incorrect decoding. I don't suppose there is a (simple) way around this, is there? I guess a complex (and resource hungry) method would be for the TCAP dissector to follow dialogs and then pass the application context information to the MAP dissector for MAP to interpret the operation based on the application context in addition to the op-code. I am sorry if this has already been discussed, I searched the archives, but could not find anything relevant... perhaps I didn't use the correct search string. Thanks, Abhik. ___ 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] Diameter AVP decoding : Same AVP codes with different names
Hello I have a question about the way Wireshark decodes Diameter AVP. Is the ApplicationID taken into account when Wireshark decodes an AVP ? Example : - in 3GPP CX/DX Application(ID=16777216, 3GPP TS 29.228 and 29.229), the AVP code 1 is Visited-Network-Identifier. The vendor-Id for this AVP is TGPP (10415) - in 3GPP Gmb Application (ID=16777223, 3GPP TS 29.061), the AVP code 1 is 3GPP-IMSI. The vendor-Id for this AVP is also TGPP (10415) I created my own dictionnary for 3GPP Gmb Application and, normally, Wireshark should display the right name according to the ApplicationID but I don't think it is the case... Wireshark always displays me the value in 3GPP Gmb dictionnary. If I erase the AVP code 1 from my 3GPP Gmb dictionnary, it displays the AVP name contained in the 3GPP CD/DX dictionnary...as if it doesn't take into account the ApplicationID... Is it normal ? Do I make a mistake somewhere in my understanding ? Thanks by advance Xavier - Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses.___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] bunch of warnings fixes
checked in On 3/26/07, Sebastien Tandel [EMAIL PROTECTED] wrote: One big patch is provided to apply all the changes. It contains warnings fixes and removed some declarations after statement too. I also provide patch-per-file.tar.gz containing one patch for each file affected by big patch, in case some modifs have been committed on one of these files : packet-alcap packet-ansi_637 packet-ansi_a packet-atalk packet-beep packet-ber packet-bootp packet-bpdu packet-bthci_acl packet-btsdp packet-cops packet-cups packet-ssh packet-synergy packet-t38 packet-tacacs packet-tali packet-tcp packet-tds packet-telnet packet-ucp packet-uma packet-vtp packet-wbxml packet-who packet-x11 packet-x25 packet-xdmcp packet-xml packet-yhoo Regards, Sebastien Tandel ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] gsm_map dissector question
Hi Anders, It is in ETSI GSM MAP specification GSM 09.02 version 4.19.1 quote -- short message service operation codes sendRoutingInfoForSM SendRoutingInfoForSM ::= 45 forwardSM ForwardSM ::= localValue 46 ... /quote There is no distinction between mt-fsm and mo-fsm. Thanks for looking into this. No hurry. Regards, Abhik. On 3/26/07, Anders Broman (AL/EAB) [EMAIL PROTECTED] wrote: Hi, In which specification is mt-fsm(MT-ForwardSM?) given with Opcode 46? I supose a solution would be to introduce a preference if MAPv2 or V3 is used. I have little time to look at this currently. Best regards Anders -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Abhik Sarkar Sent: den 26 mars 2007 11:31 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] gsm_map dissector question Hi Anders, Thanks for your reply. Attached are sample captures. The MSUs are syslog encapsulated, so you need to be running SVN rev 21109 or higher. Decode UDP destination port 7890 as syslog and you will see the MTP3 and higher layers. example1.cap : A simple MAPv2 mt-fsm showing up as mo-fsm. example2.cap : The gsm_map dissector throwing up a BER decode error because it thinks there are some extra invalid field beyond the sm-RP-UI of the mo-fsm, but the extra field is actually the more-messages-to-send flag in a MAPv2 mt-fsm. I had one more example, but I can't find it anymore. I will send it on if I do find it. Best regards, Abhik. On 3/26/07, Anders Broman (AL/EAB) [EMAIL PROTECTED] wrote: Hi, If you could supply a sample trace we could see what can be done. Best regards Anders From: [EMAIL PROTECTED] on behalf of Abhik Sarkar Sent: Mon 3/26/2007 9:49 AM To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] gsm_map dissector question Hi List, I have been capturing and decoding some live traffic on a GSM network, and find a problem in decoding of GSM MAP operations. The GSM MAP dissector is currently based on 3GPP TS 29.002 v7.5.0. This leads to incorrect decoding of packets which are working on lower MAP versions. For example, a MAP v2 ShortMsgMT-Relay gets decoded as MAP v3 ShortMsgMO-Relay (because the opcodes are same). This leads to all kinds of warnings, and sometimes incorrect decoding. I don't suppose there is a (simple) way around this, is there? I guess a complex (and resource hungry) method would be for the TCAP dissector to follow dialogs and then pass the application context information to the MAP dissector for MAP to interpret the operation based on the application context in addition to the op-code. I am sorry if this has already been discussed, I searched the archives, but could not find anything relevant... perhaps I didn't use the correct search string. Thanks, Abhik. ___ 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] Regarding buiding Ethereal
I am a newbie to Wireshark development. My aim is to have a protocol dissector. I have Windows XP along with cygwin installed on my m/c. I have downloaded source from http://www.wireshark.org/download/src/wireshark-0.99.5.tar.gz I read the INSTALL file and tried to do a ./configure in wireshark folder through cygwin. Then, I got this error and stops. xxxstartxxx 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? xxxENDx I downloaded libpcap source from www.tcpdump.org and put inside wireshark directory. I tried to compile this libcap separately and got an error checking for u_int16_t using gcc... yes checking for u_int32_t using gcc... yes checking how to run the C preprocessor... gcc -E checking for sys/ioccom.h... no checking for sys/sockio.h... no checking for ifaddrs.h... no checking for limits.h... yes checking for netinet/if_ether.h... no checking for ANSI ioctl definitions... no configure: error: see the INSTALL for more info How to move forward in the building process.??? ---Manju SASKEN BUSINESS DISCLAIMER - This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Regarding buiding Ethereal
Hi Manjunath, On WIN32, there are several other requirements than just cygwin to compile WS. Please check out the documentation at http://wireshark.org/develop.html and http://wireshark.org/download/docs/developer-guide-a4.pdf to start with. If you follow the instructions in the developer guide without deviating, you can will almost certainly be successful on the first compile attempt. Regards, Abhik On 3/26/07, Manjunath P [EMAIL PROTECTED] wrote: I am a newbie to Wireshark development. My aim is to have a protocol dissector. I have Windows XP along with cygwin installed on my m/c. I have downloaded source from http://www.wireshark.org/download/src/wireshark-0.99.5.tar.gz I read the INSTALL file and tried to do a ./configure in wireshark folder through cygwin. Then, I got this error and stops. xxxstartxxx 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? xxxENDx I downloaded libpcap source from www.tcpdump.org and put inside wireshark directory. I tried to compile this libcap separately and got an error checking for u_int16_t using gcc... yes checking for u_int32_t using gcc... yes checking how to run the C preprocessor... gcc -E checking for sys/ioccom.h... no checking for sys/sockio.h... no checking for ifaddrs.h... no checking for limits.h... yes checking for netinet/if_ether.h... no checking for ANSI ioctl definitions... no configure: error: see the INSTALL for more info How to move forward in the building process.??? ---Manju SASKEN BUSINESS DISCLAIMER - This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email ___ 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] preference tree for SS7
Hi list, I finally had a chance to look at the new feature from revision 21066: http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=21066 and see what it looks like if I put, say, all the SS7 dissectors' preferences in one preference tree called SS7. The result was a little startling: I was able to put *21* dissectors' preferences in that category: ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, TALI, TCAP It looks good to me because I tend to think hierarchically and because I don't like how long the current list of dissectors with preferences is (too much scrolling before I find the one I want). What does anyone else (especially signaling users) think? Any objections? Regards, -Jeff ps. Yes, I defined SS7 a bit loosely as anything for transporting SS7 or which is (or was) transported over SS7. And yes, maybe I missed some: each time I've gone through the list of preferences I found another one... ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
I agree! On 3/26/07, Jeff Morriss [EMAIL PROTECTED] wrote: Hi list, I finally had a chance to look at the new feature from revision 21066: http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=21066 and see what it looks like if I put, say, all the SS7 dissectors' preferences in one preference tree called SS7. The result was a little startling: I was able to put *21* dissectors' preferences in that category: ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, TALI, TCAP It looks good to me because I tend to think hierarchically and because I don't like how long the current list of dissectors with preferences is (too much scrolling before I find the one I want). What does anyone else (especially signaling users) think? Any objections? Regards, -Jeff ps. Yes, I defined SS7 a bit loosely as anything for transporting SS7 or which is (or was) transported over SS7. And yes, maybe I missed some: each time I've gone through the list of preferences I found another one... ___ 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] Expert info missing entries
Team, I came across a problem that is described in posting http://www.wireshark.org/lists/wireshark-dev/200607/msg04326.html I can confirm that the change as described there works, e.g. in expert_dlg_init() I call: cf_redissect_packets(cfile); instead of cf_retap_packets(cfile, FALSE); I was not able to locate any followup on the posting. Is this problem not important? I am adding many expert infos in my dissector, and would like to understand if they should appear in the expert info list or not. Alternatively, can someone try to figure out why the expert_item value is null when performing a retap (this is from the comment in expert_comp_dlg.c)? I am afraid I would need too much time for it. Thanks in advance Andrej ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
I'll second that! Olivier. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Morriss Sent: Monday, March 26, 2007 16:05 To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] preference tree for SS7 Hi list, I finally had a chance to look at the new feature from revision 21066: http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=21066 and see what it looks like if I put, say, all the SS7 dissectors' preferences in one preference tree called SS7. The result was a little startling: I was able to put *21* dissectors' preferences in that category: ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, TALI, TCAP It looks good to me because I tend to think hierarchically and because I don't like how long the current list of dissectors with preferences is (too much scrolling before I find the one I want). What does anyone else (especially signaling users) think? Any objections? Regards, -Jeff ps. Yes, I defined SS7 a bit loosely as anything for transporting SS7 or which is (or was) transported over SS7. And yes, maybe I missed some: each time I've gone through the list of preferences I found another one... ___ 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] preference tree for SS7
Hi list, I finally had a chance to look at the new feature from revision 21066: http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=21066 and see what it looks like if I put, say, all the SS7 dissectors' preferences in one preference tree called SS7. The result was a little startling: I was able to put *21* dissectors' preferences in that category: ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, TALI, TCAP It looks good to me because I tend to think hierarchically and because I don't like how long the current list of dissectors with preferences is (too much scrolling before I find the one I want). What does anyone else (especially signaling users) think? Any objections? There are both reasons for and against it. I'll agree that the current list is pretty long and I tend to like it to be hierarchical as well. The drawback is: You'll have to know to search for protocol xy under SS7 (BTW: is this basically the same as http://wiki.wireshark.org/SIGTRAN ?). This might be obvious for frequent protocol user, but makes it probably more complicated for newbies (like me :-). So if we want to group protocols, we should group (at least) most protocols, to have the protocol list length dastically reduced. Maybe the current Protocol Family overview http://wiki.wireshark.org/ProtocolReference could work as a guideline to sort protocols into such groups. Regards, ULFL P.S: Some time ago, I've tried grouping some of the protocols in the menu structure, and immediately got objections from other developers against my grouping thoughts - so this discussion might become very controverse ;-) P.P.S: Will the packet tree context Protocol Preferences ... still work with this? This feature is pretty useful! ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
Now I have to type [Ctrl-Shift-P][p][r][o][RET][fw-arrow][t][c][TAB] and I can modify TCAP's prefs. Tomorrow I'll have to: [Ctrl-Shift-P][p][r][o][RET][fw-arrow][s][s][RET][fw-arrow][t][c][TAB] for a keyboard animal like me that's a loss... On the other hand I know that TCAP is an SS7 protocol so *I* would look there, for someone that does not know what SS7 is how he would ever know where to look. SS7 is not a good example for this... if you do not know what's SS7 you probably won't see any SS7 traffic not even by accident, lest you'll now or need to know what's TCAP. But my point is that categorizing protocols can hide many of these from users. The flat list is easy to search while for the categorized one you need to know where the protocol belongs. Luis 3/26/07, Jacques, Olivier (PDE IT Test) [EMAIL PROTECTED] wrote: I'll second that! Olivier. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Morriss Sent: Monday, March 26, 2007 16:05 To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] preference tree for SS7 Hi list, I finally had a chance to look at the new feature from revision 21066: http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=21066 and see what it looks like if I put, say, all the SS7 dissectors' preferences in one preference tree called SS7. The result was a little startling: I was able to put *21* dissectors' preferences in that category: ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, TALI, TCAP It looks good to me because I tend to think hierarchically and because I don't like how long the current list of dissectors with preferences is (too much scrolling before I find the one I want). What does anyone else (especially signaling users) think? Any objections? Regards, -Jeff ps. Yes, I defined SS7 a bit loosely as anything for transporting SS7 or which is (or was) transported over SS7. And yes, maybe I missed some: each time I've gone through the list of preferences I found another one... ___ 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 -- 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
Re: [Wireshark-dev] preference tree for SS7
On 3/26/07, Ulf Lamping [EMAIL PROTECTED] wrote: Hi list, I finally had a chance to look at the new feature from revision 21066: http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=21066 and see what it looks like if I put, say, all the SS7 dissectors' preferences in one preference tree called SS7. The result was a little startling: I was able to put *21* dissectors' preferences in that category: ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, TALI, TCAP It looks good to me because I tend to think hierarchically and because I don't like how long the current list of dissectors with preferences is (too much scrolling before I find the one I want). What does anyone else (especially signaling users) think? Any objections? There are both reasons for and against it. I'll agree that the current list is pretty long and I tend to like it to be hierarchical as well. The drawback is: You'll have to know to search for protocol xy under SS7 (BTW: is this basically the same as http://wiki.wireshark.org/SIGTRAN ?). This might be obvious for frequent protocol user, but makes it probably more complicated for newbies (like me :-). Whether SIGTRAN belongs to SS7 or just complements it or supersedes it is a perfect example of an endless categorization discussion. SIGTRAN is a set of protocols to have SS7 run over IP. So if we want to group protocols, we should group (at least) most protocols, to have the protocol list length dastically reduced. Maybe the current Protocol Family overview http://wiki.wireshark.org/ProtocolReference could work as a guideline to sort protocols into such groups. Regards, ULFL P.S: Some time ago, I've tried grouping some of the protocols in the menu structure, and immediately got objections from other developers against my grouping thoughts - so this discussion might become very controverse ;-) P.P.S: Will the packet tree context Protocol Preferences ... still work with this? This feature is pretty useful! ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 ___ 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] Duplicate posts?
Hi All, Sorry for the slightly off-topic post but since we have no postmaster I am pinging the list. Is anyone else receiving duplicate posts? The mailing list site shows me only subscribed once but I am receiving duplicate messages for all posts. Certainly not life threatening but very aggravating... Cheers ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] preference tree for SS7
What about calling it SS7/SIGTRAN ? Best regards Michael On Mar 26, 2007, at 4:05 PM, Jeff Morriss wrote: Hi list, I finally had a chance to look at the new feature from revision 21066: http://anonsvn.wireshark.org/viewvc/viewvc.py?view=revrevision=21066 and see what it looks like if I put, say, all the SS7 dissectors' preferences in one preference tree called SS7. The result was a little startling: I was able to put *21* dissectors' preferences in that category: ALCAP, ANSI BSMAP, ANSI MAP, BSSAP, BSSGP, CAMEL, GSM SMS UD, GSM_MAP, INAP, ISUP, isup_thin, IUA, M2PA, M2UA, M3UA, MTP2, MTP3, SCCP, SUA, TALI, TCAP It looks good to me because I tend to think hierarchically and because I don't like how long the current list of dissectors with preferences is (too much scrolling before I find the one I want). What does anyone else (especially signaling users) think? Any objections? Regards, -Jeff ps. Yes, I defined SS7 a bit loosely as anything for transporting SS7 or which is (or was) transported over SS7. And yes, maybe I missed some: each time I've gone through the list of preferences I found another one... ___ 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 21195: /trunk/ /trunk/: configure.in
Sebastien Tandel wrote: Note that '==' is not portable on BSD unix. For the test/[ command, the standard string-comparison operator is =, rather than ==. (There's also -eq for a numerical comparison.) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] dissecting and decoding an 8 byte field
Is there recommended way to decode 8 byte fields? I see I can use FT_NONE with a size of 8 bytes and the appropriate bytes highlight in the bytes of the packet, but the value does not display in the decoded details? Bill - No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started.___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Wireshark-commits] rev 21110: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-eventlog.c packet-dcerpc-eventlog.h /trunk/epan/dissectors/pidl/: eventlog.cnf
Ronnie, Can we get a copy of the patched pidl program you used below? Is all of pidl maintained by the Samba team so that they would be the ones that would permanently make the _U_ change to it? On Thu, Mar 22, 2007 at 08:45:02AM +, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21110 User: sahlberg Date: 2007/03/22 08:45 AM Log: Using a patched version of pidl that decorates all parameters with _U_ and updates to the conformance file, regenerate the eventlog dissector to remove a lot of compiler warnings Directory: /trunk/epan/dissectors/ ChangesPathAction +261 -261 packet-dcerpc-eventlog.cModified +5 -5 packet-dcerpc-eventlog.hModified Directory: /trunk/epan/dissectors/pidl/ ChangesPathAction +3 -3 eventlog.cnfModified ___ 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 21110: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-eventlog.c packet-dcerpc-eventlog.h /trunk/epan/dissectors/pidl/: eventlog.cnf
Yes, PIDL is maintained by the samba team. Jelmer is a bit busy right now but he will hopefully check the pathces i sent in when he gets time. Once that is done I will regenerate the other PIDL dissectors. On 3/26/07, Stephen Fisher [EMAIL PROTECTED] wrote: Ronnie, Can we get a copy of the patched pidl program you used below? Is all of pidl maintained by the Samba team so that they would be the ones that would permanently make the _U_ change to it? On Thu, Mar 22, 2007 at 08:45:02AM +, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21110 User: sahlberg Date: 2007/03/22 08:45 AM Log: Using a patched version of pidl that decorates all parameters with _U_ and updates to the conformance file, regenerate the eventlog dissector to remove a lot of compiler warnings Directory: /trunk/epan/dissectors/ ChangesPathAction +261 -261 packet-dcerpc-eventlog.cModified +5 -5 packet-dcerpc-eventlog.hModified Directory: /trunk/epan/dissectors/pidl/ ChangesPathAction +3 -3 eventlog.cnfModified ___ 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
Re: [Wireshark-dev] [Wireshark-commits] rev 21212: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-megaco.c
There was a missing constant preventing it from compiling. I just added it to gcp.h Please review that the constant is the correct one. On 3/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21212 User: lego Date: 2007/03/26 09:10 PM Log: add context tracing and tap to packet-megaco.c (have to fix the matching of wildcarded terminations as it doesn't work as it should) Directory: /trunk/epan/dissectors/ ChangesPath Action +214 -6packet-megaco.cModified ___ 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] A very pragmatic approach to fix remaining MSVC warnings ...
Hi List! As I've got no response to my previous approach to fix the warnings of the generated source files in epan/dissectors I had to look for a more pragmatic approach. There are already changes rushing in, that are adding new warnings, so I've thought it was time to fix this hole by setting the warnings as errors plug in epan/dissectors.. My way was adding #pragma warning(disable:xy) to the corresponding places. I know that's not the best approach, but I was trying to avoid what was happening the last time I tried reducing warnings, namely that more warnings were rushing in than core developers are willing to fix. Having the (Win32) buildbot turning red for a single warning *might* be a motivation to keep the code warning free. As I would like to remove any warning I introduced, I just didn't noticed the gcc warning I've caused - having the buildbot turned red for the gcc side, would motivated me to fix my warnings ... Regards, ULFL P.S. As a drawback, checking in the generated files (recently changed) will probably make the buildbot turn red, we'll need to find a solution for this ... ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Diameter AVP decoding : Same AVP codes withdifferent names
Hi, This is most probably a bug. Please file a bug report, preferably with a sample trace. Best regards Anders Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Xavier Ameziane Skickat: den 26 mars 2007 12:29 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Diameter AVP decoding : Same AVP codes withdifferent names Hello I have a question about the way Wireshark decodes Diameter AVP. Is the ApplicationID taken into account when Wireshark decodes an AVP ? Example : - in 3GPP CX/DX Application(ID=16777216, 3GPP TS 29.228 and 29.229), the AVP code 1 is Visited-Network-Identifier. The vendor-Id for this AVP is TGPP (10415) - in 3GPP Gmb Application (ID=16777223, 3GPP TS 29.061), the AVP code 1 is 3GPP-IMSI. The vendor-Id for this AVP is also TGPP (10415) I created my own dictionnary for 3GPP Gmb Application and, normally, Wireshark should display the right name according to the ApplicationID but I don't think it is the case... Wireshark always displays me the value in 3GPP Gmb dictionnary. If I erase the AVP code 1 from my 3GPP Gmb dictionnary, it displays the AVP name contained in the 3GPP CD/DX dictionnary...as if it doesn't take into account the ApplicationID... Is it normal ? Do I make a mistake somewhere in my understanding ? Thanks by advance Xavier Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] FYI: Status of gcc warnings in epan/dissectors
FYI: Update on warnings in epan/dissectors under gcc 4.0 Below is a list of the number of warnings remaining in epan/dissectors when using gcc 4.0. There are 3,915 warnings in this directory across 163 files. Excluding files that show warnings as being in the .cnf filename (such as asn generated) files, there are only 795 warnings. This includes some pidl generated dissectors, whose warnings will be fixed by Ronnie once the Samba team commits his change to add _U_ to everything. Almost all of the warnings I've fixed so far are sign mismatches between guint8* and (g)char* :(. 552 of the 795 remaining warnings outside of the .cnf files are this problem. As Ulf said, the hole needs to be plugged to keep new warnings from creeping in. Unfortunately, I don't think it is as straightforward to do with automake as it is under MSVC (adding a line to each file with warnings), especially with this many warnings remaining. I can't add -Werror to epan/dissectors yet. I do encourage everyone on Unix to compile with the configure option --with-warnings-as-errors to keep warnings from creeping into the directories where -Werror has been applied. #Warn File 1 ess.cnf 1 h225.cnf 1 h245.cnf 1 logotype-cert-extn.cnf 1 packet-MAP_DialoguePDU-fn.c 1 packet-ansi_map-template.c 1 packet-bacapp.c 1 packet-cmip-fn.c 1 packet-dap-fn.c 1 packet-dccp.c 1 packet-dcerpc-nt.c 1 packet-dcerpc-rs_misc.c 1 packet-dcerpc-spoolss.c 1 packet-dcerpc-wkssvc.c 1 packet-disp-fn.c 1 packet-dsi.c 1 packet-edonkey.c 1 packet-frame.c 1 packet-fw1.c 1 packet-gsm_map-template.c 1 packet-gssapi.c 1 packet-hsrp.c 1 packet-icep.c 1 packet-igap.c 1 packet-image-gif.c 1 packet-ipdc.c 1 packet-isup_thin.c 1 packet-k12.c 1 packet-m2ua.c 1 packet-ospf.c 1 packet-pana.c 1 packet-pkix1implicit-fn.c 1 packet-pkixtsp-fn.c 1 packet-pktc.c 1 packet-quake2.c 1 packet-s5066.c 1 packet-scsi.c 1 packet-skinny.c 1 packet-smb2.c 1 packet-smrse-fn.c 1 packet-sna.c 1 packet-umts_rrc-fn.c 1 packet-umts_rrc-template.c 1 packet-ymsg.c 1 pkcs12.cnf 1 rrlp.cnf 2 cms.cnf 2 packet-acp133-fn.c 2 packet-cmp-fn.c 2 packet-dcerpc-efs.c 2 packet-dcerpc-rpriv.c 2 packet-dcerpc-rs_acct.c 2 packet-dcerpc-rs_pgo.c 2 packet-dhcp-failover.c 2 packet-dhcpv6.c 2 packet-ftp.c 2 packet-gsm_ss-fn.c 2 packet-gtp.c 2 packet-megaco.c 2 packet-nbns.c 2 packet-ndps.c 2 packet-pagp.c 2 packet-pgm.c 2 packet-pop.c 2 packet-rmi.c 2 packet-smb-browse.c 2 packet-wsp.c 3 cmip.cnf 3 packet-dcerpc-afs4int.c 3 packet-dcerpc-dfs.c 3 packet-dcerpc-drsuapi.c 3 packet-dcerpc-winreg.c 3 packet-dcom.c 3 packet-diameter.c 3 packet-ess-fn.c 3 packet-fcdns.c 3 packet-fix.c 3 packet-gnm-template.c 3 packet-iax2.c 3 packet-image-jfif.c 3 packet-inap-template.c 3 packet-iscsi.c 3 packet-kerberos.c 3 packet-q931.c 3 packet-rtp.c 3 packet-sdp.c 3 packet-slowprotocols.c 3 packet-umts_rrc_ies-template.c 3 packet-umts_rrc_pdu_def-template.c 3 packet-x509if-fn.c 4 acse.cnf 4 disp.cnf 4 gsmmap.cnf 4 h248.cnf 4 packet-afp.c 4 packet-ansi_map-template.c 4 packet-cops.c 4 packet-dcerpc-initshutdown.c 4 packet-extreme.c 4 packet-fcswils.c 4 packet-h450-template.c 4 packet-icap.c 4 packet-kismet.c 4 packet-quakeworld.c 4 packet-smb-common.c 4 packet-smtp.c 4 tcap.cnf 5 h235.cnf 5 packet-dcerpc.c 5 packet-distcc.c 5 packet-ipp.c 5 packet-mmse.c 5 packet-ncp.inc 5 packet-osi.c 5 packet-rpc.c 5 packet-umts_rrc_pdu_def-fn.c 6 ansi_map.cnf 6 ftam.cnf 6 packet-dcerpc-eventlog.c 6 packet-dcm.c 6 packet-dop-fn.c 6 packet-ldap-template.c 6 packet-mount.c 6 packet-msrp.c 6 packet-rsync.c 6 packet-slsk.c 6 s4406.cnf 7 packet-bittorrent.c 7 packet-gnm-fn.c 7 packet-isup.c 7 packet-multipart.c 7 x509if.cnf 8 packet-dcerpc-srvsvc.c 8 packet-gsm_sms.c 8 packet-inap-fn.c 9 ldap.cnf 9 packet-mms-fn.c 10 packet-nfs.c 10 packet-smb-pipe.c 11 packet-snmp-template.c 12 camel.cnf 12 packet-jxta.c 13 packet-sip.c 15 ansi_map.cnf 15 packet-dcerpc-fldb.c 16 packet-x509sat-fn.c 18 packet-dcerpc-wzcsvc.c 18 packet-pgsql.c 18 packet-quake3.c 20 packet-dns.c 22 packet-srvloc.c 26 packet-rtsp.c 27 gnm.cnf 36 packet-umts_rrc_ies-fn.c 46 packet-h450-fn.c 46 packet-http.c 57 packet-giop.c 58 inap.cnf 58 packet-smb.c 67 x411.cnf 308 ranap.cnf 1228 rnsap.cnf 1335 nbap.cnf Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
