Re: [Wireshark-dev] AMQP dissector patch
You could use _U_ in the template for all those arguments that might not be used, regardless of whether they're actually used or not. If _U_ is not necessary there's no problem if it is present. L On 6/1/07, Martin Sustrik [EMAIL PROTECTED] wrote: Steve, The problem is that the code is generated from the protocol specification. If I was to find out which parameters actually need _U_ and which do note, the code generation would get considerably more complex (two passes instead of single one). Martin From: Stephen Fisher [EMAIL PROTECTED] Date: Mon, 21 May 2007 14:02:33 -0700 On Mon, May 21, 2007 at 02:30:59PM +0200, Martin Sustrik wrote: Here's the patch for following issues: - If there are several AMQP frames in single TCP packet, all of them are shown in the 'info' column - AMQP heartbeat is dissected correctly, it doesn't assert any more Can you please apply the patch to the SVN? I have one question before applying the patch. Both in your patch and in the existing code, many functions have _U_ for every paramter in functions, even when those variables are used within the function. Any idea why that is? Steve ___ 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] Implementation of Morphing Display filters on the fly ....
http://wiki.wireshark.org/Mate/Examples#head-024177fe669649345cc7c67b8eb227243d94c764 On 5/31/07, Purandhar Krishnamurthy [EMAIL PROTECTED] wrote: Hello, I would like to create a conditional display filter. When a filter criteria is hit on one protocol I would like to change the display filter so that it includes an OR'd reference to another protocol. How can I update the wireshark code to modify a display filter on the fly ? Problem Summary === We are analysing packes for UMTS. First we are filtering based on IMSI/Subscriber identity. For example Filter String - radius._IMSI == 9998001 While we analyse/dissect packets, we update the filter string with ip.addr (Framed IP address, which we are getting in the Layer1 of Protocol as an Attribute Value Pair) Updated filter string on the fly is : radius._IMSI == 9998001 || ip.addr == 10.166.104.151 Then we get list of packets, send and received by that subscriber. Then we apply another filter to get information for a particular PDP context. Filter String - radius._IMSI == 9998001 || ip.addr == 10.166.104.151 But we are not getting filtered list of packets. We are again getting other packets for which IP Address doesn't matches also. Can anybody assist us, Thanks in advance, Purandhar/Bhowmick ___ 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] File:Import?
On 5/30/07, Stephen Fisher [EMAIL PROTECTED] wrote: On Tue, May 29, 2007 at 12:26:19PM -0400, Maynard, Chris wrote: Today someone sent me a text file of a Wireshark packet capture session that was created using Wireshark's File:Export facility. Unfortunately, he did not keep the original capture file. I know there's currently no File:Import capability in Wireshark, but I was wondering if anyone has considered adding it. Try using the text2pcap utility that comes with Wireshark. It may be able to convert your exported text file back into a pcap file that Wireshark/tshark can read. I realize that if File:Import is to work that the exported file would have to include all packet bytes, but assuming that's the case, I would think that it would be possible to Import it, at least for some of the supported Export types, if not all of them? Is this feature worthy of the Wish List? Would anyone object if I add it? Or has someone already added it and I just need to wait for 0.99.6? :-) An experimental tool to easily implement this kind of parsers is on its way... The issue here is guessing the encapsulation. BTW, hacking wiretap/k12text.l to have reading File Export... or tshark output should be an easy job (encapsulation apart). It does sound like a good idea to implement a File-Import feature, even if it just calls text2pcap. Sorry, it's not already in 0.99.6 developer versions. Go ahead and open a bug report and mark it as an enhancement request at http://bugs.wireshark.org (I don't know about others, but I look at the bug reports more often than the wish list). I do not remember the last time I checked the wishlist... A while ago. But I remember it was a collection of proposals either off the scope of a protocol analyzer, utopia or with a very narrow user base. Enhancements in the bug list are better IMHO... -- 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] packet-v5ua.c
On 5/29/07, Stephen Fisher [EMAIL PROTECTED] wrote: On Tue, May 29, 2007 at 07:59:59AM +0200, Michael Tuexen wrote: is there any reason why the V5UA plugin does not use the IANA registered port 5675, but 10001? The code just says: I'm not sure. /* In RFC specification the SCTP registered User Port Number Assignment for V5UA is 5675 */ /* #define SCTP_PORT_V5UA 5675 */ #define SCTP_PORT_V5UA 10001 If there is no objection, I would change this to the IANA assigned port number. How about using both? Or, better yet, adding a preference option to use the 10001 port instead of 5675 if someone needs to? Or better again adding an integer preference for an extra port. Steve ___ 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] [Patch] additional lua dissector preference types
On 5/2/07, Balint Reczey (IJ/ETH) [EMAIL PROTECTED] wrote: Hi, Is there anything i could do to help this patch's inclusion in the svn repo? I'll take care of it, just need the time to test it. Luis Regards, Balint 2007. 04. 27, péntek keltezéssel 13.28-kor Balint Reczey (IJ/ETH) ezt írta: Hi, The attached patch adds ability of of creating radio button, drop-down list and range type preference entries to the Lua plugin. It also fixes a lua compile warning/error in wslua_gui.c. The patch is written by Tamas Regos, he asked me to send it to the list. Could someone commit it to the svn repo? Cheers, Balint ___ 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] [Patch] additional lua dissector preference types
checked in in rev 21655. There's just one issue regarding Pref.range(), by now it is just a constrained string. The right-way should be to have range_t to become a type on its own so that stuff like this can be done: do proto.prefs.rng = Pref.range(...); -- ... for i in proto.prefs.rng() do print(i) end -- ... if proto.prefs.rng:is_in(35) then print(got 35!) end end Range should have range:__call() returns a RangeIterator range:__tostring() range:is_in(n) A RangeIterator should have just a __call methamethod that returns the next value in the Range (and nil once reached the end) Luis On 5/2/07, Balint Reczey (IJ/ETH) [EMAIL PROTECTED] wrote: Hi, Is there anything i could do to help this patch's inclusion in the svn repo? Regards, Balint 2007. 04. 27, péntek keltezéssel 13.28-kor Balint Reczey (IJ/ETH) ezt írta: Hi, The attached patch adds ability of of creating radio button, drop-down list and range type preference entries to the Lua plugin. It also fixes a lua compile warning/error in wslua_gui.c. The patch is written by Tamas Regos, he asked me to send it to the list. Could someone commit it to the svn repo? Cheers, Balint ___ 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] [Wireshark-commits] rev 21556: /trunk/epan/ /trunk/epan/: proto.c proto.h
There's a function in packet-iuup.c (by the same name) which has (what i believe to be) a more consistent signature with the rest of proto_tree_add_* functions should that be used instead? Other than that the one for iuup allows for bit strings not aligned to the octet boundary. On 4/24/07, Joerg Mayer [EMAIL PROTECTED] wrote: On Tue, Apr 24, 2007 at 07:24:15PM +, [EMAIL PROTECTED] wrote: Add a new proto function proto_tree_add_bits() which adds bits to the tree starting at the bit offset given for the number of bits indicated which wll also return the value of the bits. Experimental and for review, documentation to be updated. OK, I didn't really understand the log message, but when I looked at proto.c patch, things got clearer. And here's the feedback: - what's your motivation behind that patch? (just curious) - In your patch you mixed to things: tvb_get_bits and a proto_tree_add_bits. Pease don't do that. It makes this function behave differently from all other proto_tree_add_ functions. Also, the tvb_get_ function is missing. If you *really* think that mixing these two functions makes sense, then all existing functions (and their uses) should be modified to behave similarly, just to stay consistent. 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 -- 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] [Wireshark-commits] rev 21452: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-ieee80211.c
svn up svn up -r 12345 file
On 4/18/07, Martin Mathieson [EMAIL PROTECTED] wrote:
It does look like the same problem.
Their report says that a problem of this kind was fixed in
gcc-3.4.4-2{,.fc3}, so either its the same problem not fixed in
vanilla gcc-3.4.6 or another problem with similar symptoms...
For now I'm going to peg packet-ieee80211.c at this old revision (I'm
trying to work out if subversion can help by not updating this file
when I do 'svn update' from the top...).
Thanks,
Martin
On 4/18/07, Jeff Morriss [EMAIL PROTECTED] wrote:
Martin Mathieson wrote:
Hi,
My build is failing to link from this revision onwards. The error
output is the following:
[...]
epan/.libs/libwireshark.so: undefined reference to `.LC1698'
epan/.libs/libwireshark.so: undefined reference to `.LC1695'
epan/.libs/libwireshark.so: undefined reference to `.LC1694'
epan/.libs/libwireshark.so: undefined reference to `.LC1692'
epan/.libs/libwireshark.so: undefined reference to `.LC1697'
epan/.libs/libwireshark.so: undefined reference to `.LC1696'
epan/.libs/libwireshark.so: undefined reference to `.LC1693'
collect2: ld returned 1 exit status
I recently updated my version of gcc from 3.4.3 - 3.4.6. Here is the
version info from Help | About Wireshark :
That looks suspiciously similar to bug 156:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=156
which turned out to be a bug in GCC:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157308
Otherwise I'm not sure how something _we_ are doing wrong can cause an
undefined reference to something named .LC*.
___
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
[Wireshark-dev] Problems with Exception Handling on Windows.
I been fighting for quite a while, TRYing to figure out a way to have
both exception handling mechanisms that are used in windows.
First and mostly we use our macros based on kazlib's exception code
(which build arround ANSI's setjmp and longjmp).
Then for catching exceptional exceptions (actual bugs in the code)
we use window's own __try {} __finally {} and __except {} mechanism.
One problem is that longjmp forces the execution of the __finally
block. so when THROW is called execyution jumps to the ENDTRY and not
necessarily to the CATCH
Removing these __finaly blocks I added to the TRY ENDTRY macros on the
other hand would cause ENDTRY's code not to be evaluated when a
windows exception is thrown and thus leaving kazlib's stack in an
inconsistent state possibly causing errors when handling THROW()
triggered exceptions.
In any case I'll back up the changes to the exception mechanism I made
that are actually causing more problems than those they solved.
But then, at this point we have various choices:
a) Rewrite the TRY THROW CATCH and ENDTRY macros on windows so that we
only use win32's SEH and not kazlib to avoid the unpredictable effects
of mixing both exception mechanisms. We need to add another macro at
the end of the try block and other than the above listed macros
there's CLEANUP_PUSH userers that need being refactored to use
ep_allocs instead.
b) Dump the exceptional exception mechanism used in windows to catch
bugs in the code as they were exceptions (i.e. crash instead of trying
to go ahead when such a problem happens)
c) Live with the problems caused when an exceptional exception
leaves the kazlib's stack in an inconsistent state. (It still handles
most would be crashes without misbehaving.)
Ideas or suggestions.
Notes:
Users of TRY ... ENDTRY
[id-est:~/src/ws/trunk] lego% grep ENDTRY `find . -name '*.c'` | wc
64 1422504
Users of CLEANUP_PUSH
[id-est:~/src/ws/trunk] lego% grep CLEANUP_PUSH `find . -name '*.c'`
./asn1/h245/packet-h245-template.c:
CLEANUP_PUSH(reset_h245_pi, NULL);
./epan/dissectors/packet-dcerpc-spoolss.c: CLEANUP_PUSH(g_free, key_name);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, tmpbuf);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, objkey);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, operation);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, operation);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, repobuf);
./epan/dissectors/packet-h245.c:
CLEANUP_PUSH(reset_h245_pi, NULL);
./epan/dissectors/packet-multipart.c: /*
CLEANUP_PUSH(cleanup_multipart_info, m_info); */
./epan/dissectors/packet-radius.c:CLEANUP_PUSH(g_free, eap_buffer);
./epan/dissectors/packet-socks.c:
CLEANUP_PUSH(clear_in_socks_dissector_flag, NULL);
--
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] redback dissector update
Can you gzip the patches, some MUAs (e.g. google mail) mangle the text
attachments in a way that patches become unusable.
Luis.
On 4/13/07, Florian Lohoff [EMAIL PROTECTED] wrote:
Hi,
i took the time to polish the redback dissector a little and decode some
more protocols:
Index: epan/dissectors/packet-redback.c
===
--- epan/dissectors/packet-redback.c(revision 21405)
+++ epan/dissectors/packet-redback.c(working copy)
@@ -6,7 +6,7 @@
* By Gerald Combs [EMAIL PROTECTED]
*
* Start of RedBack SE400/800 tcpdump trace disassembly
- * Copyright 2005,2006 Florian Lohoff [EMAIL PROTECTED]
+ * Copyright 2005-2007 Florian Lohoff [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -41,6 +41,7 @@
static dissector_handle_t eth_handle;
static dissector_handle_t clnp_handle;
static dissector_handle_t arp_handle;
+static dissector_handle_t ppp_handle;
/* wrapper for passing the PIC type to the generic ATM dissector */
static void
@@ -81,47 +82,58 @@
Layer3 Offset: %u, l3off);
tisub = proto_tree_add_text (subtree, tvb, 22, 2,
Data Offset: %u, dataoff);
- next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
/* Mark the gap as Data for now */
if (dataoff l3off) {
proto_tree_add_text (subtree, tvb, 24, l3off-24, Data (%d bytes),
l3off-24);
}
- /*
- * Just a guess - In case we see a difference in dataoff vs l3off
- * we assume there is an ethernet header. Traces from an OC12 didnt
- * show any header in here
- */
- if (dataoff l3off) {
-call_dissector(eth_handle, next_tvb, pinfo, tree);
- } else {
-switch(proto) {
- case 0x01:
+ switch(proto) {
+case 0x01:
/*
* IP - We assume IPv6 has a different protocol although
* i might be wrong - Havent seen any traces
*/
-call_dissector(ipv4_handle, next_tvb, pinfo, tree);
-break;
- case 0x02:
+ next_tvb = tvb_new_subset(tvb, dataoff, -1, -1);
+ call_dissector(ipv4_handle, next_tvb, pinfo, tree);
+ break;
+case 0x02:
/*
* It is CLNP although it seem the Packet Asic fills
* some data in the packet so we have a broken packet in
* the trace
*/
-call_dissector(clnp_handle, next_tvb, pinfo, tree);
-break;
- case 0x03: /* Unicast Ethernet tx - Seen with PPPoE PADO */
- case 0x04: /* Unicast Ethernet rx - Seen with ARP */
- case 0x08: /* Broadcast Ethernet rx - Seen with PPPoE PADI */
-call_dissector(eth_handle, next_tvb, pinfo, tree);
-break;
- default:
- tisub = proto_tree_add_text (subtree, tvb, 24, length-24,
+ next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
+ call_dissector(clnp_handle, next_tvb, pinfo, tree);
+ break;
+case 0x06:
+
+ /* HACK This is a guess - i dont know what this flag means
+ * but my best guess is that it means incoming e.g.
+ * the direction of the packet. In case of incoming PPP
+ * packets there seems to be some padding which does
+ * not get reflected in the l3off/dataoff
+ */
+
+ if (flags 0x0040) {
+next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
+ } else {
+ proto_tree_add_text (subtree, tvb, l3off, 4, Unknown Data (%d
bytes), 4);
+next_tvb = tvb_new_subset(tvb, l3off+4, -1, -1);
+ }
+
+ call_dissector(ppp_handle, next_tvb, pinfo, tree);
+ break;
+case 0x03: /* Unicast Ethernet tx - Seen with PPPoE PADO */
+case 0x04: /* Unicast Ethernet rx - Seen with ARP */
+case 0x08: /* Broadcast Ethernet rx - Seen with PPPoE PADI */
+ next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
+ call_dissector(eth_handle, next_tvb, pinfo, tree);
+ break;
+default:
+ tisub = proto_tree_add_text (subtree, tvb, 24, length-24,
Unknown Protocol Data %u, proto);
-break;
-}
+ break;
}
return;
}
@@ -147,6 +159,7 @@
eth_handle = find_dissector(eth_withoutfcs);
clnp_handle = find_dissector(clnp);
arp_handle = find_dissector(arp);
+ ppp_handle = find_dissector(ppp);
redback_handle = create_dissector_handle(dissect_redback, proto_redback);
dissector_add(wtap_encap, WTAP_ENCAP_REDBACK, redback_handle);
Flo
--
Florian Lohoff [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGH3aaUaz2rXW+gJcRAlqnAKDYNRmZ9Ncml3hfDFnLnqf7BSib+ACgzteO
9mJeGSiuxwmpiDbeurSM8e0=
=i3yd
-END PGP
Re: [Wireshark-dev] [PATCH] Added lower case treatment for Megaco messages
Thanks, However equivalent changes were already made (among others) in revision 21337. Other than that, the file was moved into epan/dissectors in r21191 . http://anonsvn.wireshark.org/viewvc/viewvc.py/trunk/epan/dissectors/packet-megaco.c?r1=21337r2=21336pathrev=21337 On 4/13/07, Maurizio Moroni (mmoroni) [EMAIL PROTECTED] wrote: This patch solves the problem of having the 'AuditValue', 'Modify' and 'ServiceChange' message in short form specified in mixed lower-upper case, such as (i.e.): mf=RTP/2828 and MF=RTP/2828 AV=TDM/1/1/23 and av=TDM/1/1/23 In the current implementation, if the commands are specified in different cases, the output for an AV is incorrectly shown as an ADD message. Regards Maurizio *Maurizio Moroni* *Software/QA Engineer* *CRBU MGX SW Test * [EMAIL PROTECTED] Phone :*+39 0396295610* Mobile :*+39 3488910866* ** Via Torri Bianche 7 Palazzo Faggio 20059 VIMERCATE (MI) Italy www.cisco.com/ This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. ___ Wireshark-dev mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Next release?
Other than these I think http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1531 should be addressed as well, Although its consequences aren't fatal It looks very ugly. On 4/12/07, Anders Broman [EMAIL PROTECTED] wrote: Hi, As Luis noted: Everyone that has touched the dfilter engine after the forking of 0.99.5 (20465) must take a look at http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1521 because a nasty crash has being introduced since then. My Windows build crashes as soon as I try to enter a filter L Someone that can actually understand the code in dissect_ber_choice() must take a look at the attachments of: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1342 and http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1516 which I derived from it. I tried to find out what's going on. In the bug report there is a ASN1 workaround but it would be nice to have a better solution Last (in my list) there's Coverity's 216 http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1326 that might be the root cause of http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1429 that's not that critical as an issue but having it working back would be nice. Must be solved first… Best regards Anders Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Kukosa, Tomas Skickat: den 12 april 2007 07:49 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] Next release? Is there any timeframe for the next release? T. ___ Wireshark-dev mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] native little endian ipv4 decoding function for the lua plugin
Committed revision 21397. On 4/12/07, Balint Reczey (IJ/ETH) [EMAIL PROTECTED] wrote: Hi Luis, Thanks, it works perfectly. I would like to handle the rare situation of Little Endian encoded IP addresses, so i added a function which reads the address with tvb_get_ipv4(), then swaps the bytes before SET_ADDRESS(). Could you commit it, too? Regards, Balint From: Luis Ontanon [EMAIL PROTECTED] Date: Wed, 11 Apr 2007 21:27:48 +0200 Well I replaced tvb_get_ntohs() with tvb_get_ipv4(). Balint: Can you test the changes to tvbrange:get_ipv4() in your code and verify that this works for you as well. The revision is: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21385 ___ Wireshark-dev mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Track Context in H248
H.248.1 p. 8.3 (Messages) states: An H.248.1 entity (MG/MGC) must consistently use the same MID in all messages it originates for the duration of control association with the peer (MGC/MG). But using the MID only might not suffice as we'll know only the message sender, there's no simple way to know who's the recipient (we are a protocol analyzer not an MGC or MGw we cannot assume to only receive messages for a specific MGC/MGw). We could create a mapping based on the assumption that if there's a mId for a trxReq the mId of the mess containing the trxReply with the same trxId would be the peer, but that would make even more complex code that is already twisted. BTW. I have used it with packets coming from logs of a MGw, no address whatsoever, just GCP. It worked because all the packets regarded a single MGw that won't duplicate context Ids and trxIds just happened to be unique so the NONE-NONE address pair was OK to create unique keys. Luis On 4/11/07, Roger Mahler [EMAIL PROTECTED] wrote: Hi Luis and the other H248 experts let me ask differently: Would it be possible to trace a context entirely by looking just at the H248 layer? The mId identifies the originator of a message: (i.e. the MGC in case of (most of) the Request messages and the MGW in case of (most of) the Reply messages): Will I be able to extract exactly my TWO mIds (including transactionId and contextId) and use these as correlation keys OR (and this is my actual question) can these mIds change in the course of a call? /Roger Depends, once the context is set up lower, higher addresses and context-id. if the contextid is choose it uses another table with the transactionid instead to bind the first transaction. in current svn the code used to track the context is in epan/gcp.[ch] it was in packet-h248.c till the last release. On 4/6/07, Roger Mahler [EMAIL PROTECTED] wrote: Hello what's Wireshark using as key to track contexts in H248? Cheers, Roger ___ 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] [Patch] native little endian ipv4 decoding function for the lua plugin
On 4/11/07, Guy Harris [EMAIL PROTECTED] wrote: Balint Reczey (IJ/ETH) wrote: The attached patch adds ability of reading Little Endian encoded IPv4 addresses to the Lua plugin. What exactly are the semantics of TvbRange_get_ipv4() and TvbRange_get_le_ipv4() supposed to be? The current tvbrange:get_ipv4() fetches the IPv4 address using tvb_get_ntohl() I guess (I haven't seen the patch yet) that tvbrange:get_le_ipv4() would fetch a Little endian IPv4 using tvb_get_letohl() Note, for example, that the value passed to SET_ADDRESS() should be the *raw* bytes of the IPv4 address, *NOT* the value as processed by, for example, tvb_get_ntohl() or g_ntohl(). The same applies to the value passed to proto_tree_add_ipv4(). Any code that uses tvb_get_ntohl() to get an IPv4 address will fail on a little-endian machine - and will often be fixed by the developer by changing the call to tvb_get_letohl(), which will fail on a big-endian machine (such as the machine on which I'm typing this). I suspect that TvbRange_get_ipv4() should use tvb_get_ipv4() to fetch the IPv4 address, at least fro the value passed to SET_ADDRESS(). No, it uses tvb_get_ntohl(). If the purpose of TvbRange_get_le_ipv4() is to fix problems seen with Lua scripts on little-endian machines, the right fix might be to fix TvbRange_get_ipv4(). If the purpose is to handle packets where an IPv4 address is not stored in network byte order - that's *very* rare, but it's not unheard of - then, if TvbRange_get_ipv4() needs to use tvb_get_ipv4(), TvbRange_get_le_ipv4() should use tvb_get_ipv4() and then byte-swap the value. As I have never tested this code on a LE machine (I have one now so I'll take a look at it later) as this might be the case. Please verify this assumption: I should not do any processing on the bytes of an IPv4 address because regardless of endianity it is always interpreted as a guint8[4] where [0] contains the first byte. so that 10.11.12.13 would always be stored regardless of the endianity as 0a:0b:0c:0d. Is that correct? -- 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] [Patch] native little endian ipv4 decoding function for the lua plugin
Well I replaced tvb_get_ntohs() with tvb_get_ipv4(). Balint: Can you test the changes to tvbrange:get_ipv4() in your code and verify that this works for you as well. The revision is: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21385 On 4/11/07, Guy Harris [EMAIL PROTECTED] wrote: Luis Ontanon wrote: Please verify this assumption: I should not do any processing on the bytes of an IPv4 address because regardless of endianity it is always interpreted as a guint8[4] where [0] contains the first byte. so that 10.11.12.13 would always be stored regardless of the endianity as 0a:0b:0c:0d. Is that correct? At least for IPv4 addresses handed to SET_ADDRESS() or proto_tree_add_ipv4(), yes, the IPv4 address should be a sequence of 4 bytes in network byte order, so that the first byte (byte[0]) is the topmost byte of the address. ip_to_str()/ip_to_str_buf(), etc. also expect the address to be in that format. At least as I read the inet_nto* man pages, so do inet_ntoa, inet_ntop, etc.. ___ 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] BCD ?
That applies to ISUP as well, I've always wondered about the reason
behind this oddity.
On 4/10/07, Michael Lum [EMAIL PROTECTED] wrote:
It's probably even worse than that!
In both GSM and CDMA protocols packed BCD can be represented as:
digit2 digit1
digit4 digit3
such that two octets:
0x01 0x23
would be:
1032
An example is the Called Party BCD Number element.
--
Michael Lum Principal Software Engineer
4600 Jacombs Road +1.604.276.0055
Richmond, B.C.
Canada V6V 3B1
UTStarcom Canada, Inc.
CDMA Division
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lars Worsaae
Sent: April 7, 2007 12:31 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] BCD ?
Yes
And we might even need two different variants of PACKED BCD
The problem is how to handle odd number of digits in an
integer number of bytes
I have two variants
leading 0: 0x01 0x23 = 123
and
trailing F: 0x12 0x3F = 123
/Lars
On 4/7/07, Jaap Keuter [EMAIL PROTECTED] wrote:
Hi,
I've been interested in BCD presentation as well. For that I've
whipped together some proto_tree_add_bcd() code, but
couldn't really
get my head around creating a generic FT_BCD.
For that matter you're talking about PACKED BCD, which is different
from BCD.
PACKED BCD: 0x46 0x10 - 4610
BCD:0x04 0x06 0x01 0x00 - 4610
So if we make FT_BCD we also need to make FT_PACKED_BCD.
Anyone a decent manual for adding FTs?
Thanx,
Jaap
On Fri, 6 Apr 2007, Lars Worsaae wrote:
Desr sirs
Are their a smart(er) way to dissect data which are BCD encoded?
I cant find i tvb_get_* reading BCD.
I had roled my own, but am i and my experimental first time
dissector realy the first and only dissection BCD encoded data?
Rgds Lars
BTW My get'er looks like:
static guint32
tvb_get_bcd(tvbuff_t *tvb, int offset, int length) {
int i;
guint32 val=0;
for(i=0;ilength;i++){
guint8 b = tvb_get_guint8(tvb, offset+i);
val = 100*val + ((b4)*10 + (b0xf));
}
return val;
}
___
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
--
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] Track Context in H248
Depends, once the context is set up lower, higher addresses and context-id. if the contextid is choose it uses another table with the transactionid instead to bind the first transaction. in current svn the code used to track the context is in epan/gcp.[ch] it was in packet-h248.c till the last release. On 4/6/07, Roger Mahler [EMAIL PROTECTED] wrote: Hello what's Wireshark using as key to track contexts in H248? Cheers, Roger ___ 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] The war against warnings - mission accomplished!
I do not think other lex than flex would actually work with all our lexers.
As far as the generated dissectors are delivered in the src tarballs
there's no problem, as the source will compile anyway on any POSIX
system. Windows builds require flex and a make clean.
On the other side if I remember well, if yyunput is not generated
other warnings come up.
You can try... and see what happens.
Worst case scenario: you'll just have to revert a commit.
Luis
On 4/3/07, Richard van der Hoff [EMAIL PROTECTED] wrote:
Richard van der Hoff wrote:
I'll see what I can do to squash a few.
I'm just wondering what to do about this one:
scanner.c:1571: warning: `yyunput' defined but not used
(for epan/dfilter/scanner.{c,l}, flex 2.5.33, gcc 3.3.6)
Ideally we'd add --nounput to the flex cmdline or %option nounput to
scanner.l, but they are both flex-only, so that's a bit hard.
The best I can come up with otherwise is
static void yyunput (int, char*) _U_;
in the declarations. Thoughts?
Cheers,
Rich
___
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] The war against warnings - mission accomplished!
On 4/3/07, Luis Ontanon [EMAIL PROTECTED] wrote:
I do not think other lex than flex would actually work with all our lexers.
Few minutes later, Luis Ontanon [EMAIL PROTECTED] writes:
Now I'm sure they won't:
from http://www.gnu.org/software/flex/manual/html_chapter/flex_20.html
The following flex features are not included in lex or the POSIX specification:
C++ scanners
%option === THIS
start condition scopes
start condition stacks THIS
interactive/non-interactive scanners
yy_scan_string() and friends THIS
yyterminate() THIS
yy_set_interactive()
yy_set_bol()
YY_AT_BOL()
EOF THIS
*
YY_DECL
YY_START
YY_USER_ACTION
YY_USER_INIT
#line directives
%{}'s around actions
multiple actions on a line
--
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] [Wireshark-commits] rev 21325: /trunk/epan/ /trunk/epan/: uat.c
oops! compiling on windows! On 4/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21325 User: richardv Date: 2007/04/03 07:53 PM Log: fix an 'unused parameter' warning Directory: /trunk/epan/ ChangesPath Action +1 -1 uat.c Modified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- 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] 1 packet triggers 4 bugs, is it a record?
If you take a look to the attachment http://bugs.wireshark.org/bugzilla/attachment.cgi?id=605 of bug http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1342 You'll have a perfect example of an evil packet (not malicious but certainly evil) that causes 4(3?) bugs to be triggered. This malformed packet causes a recursion loop in AccessResult via dissect_ber_choice() because the choice's data is a sequence of 00s. Other than the bug in the code that generated the packet (which is not our business). We got one or two bugs here: - dissect_ber_choice() must stop looping without advancing. - and MMS's AccessResult/success1 might be IMPLICIT (I tried to make it implicit and it stopped the loop marking these packets as malformed). That causes a stack overflow which hides more bugs: One of the bugs I just fixed it, where a windows exception thrown up in the stack will skip all the ENDTRY groups causing a crash later in except_pop() when called by the ENDTRY of dissect_packet() Once fixed the file is read ok with tshark (even with -V but there you can see the effect of the loop). On WS (on Windows), on the other hand, the packet list is made OK but if you click on the evil packet (21) WS just shuts down (no dump to the debugger, no signs of why!). I believe this to be a out of memory error when generating the tree after dissection but honestly I do not know how to deal with this. I'll investigate the last issue (the shut down) but someone that knows how dissect_ber_choice() works should take a look at it. Luis -- 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] [Wireshark-commits] rev 21303: /trunk/wiretap/ /trunk/wiretap/: k12.c
On 4/3/07, Guy Harris [EMAIL PROTECTED] wrote: On Apr 2, 2007, at 3:17 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21303 User: lego Date: 2007/04/02 10:17 PM Log: There are odd packet records in k15 generated files where the interface record does not match any given one. I noticed that these records have the first byte changed so When a lookup fails mask the byte and lookup again. Are there any cases where the upper byte of the ID in question is significant? It is significant for most files I have. That's why I lookup twice instead of just using the masked id as key. (I.e., might that be a 24-bit ID plus a separate 8-bit field?) I thought that myself i thus I coded it... then the regression test showed me that it wasn't that. -- 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] [Patch] pragma warning
On 3/28/07, ronnie sahlberg [EMAIL PROTECTED] wrote: On 3/28/07, Ulf Lamping [EMAIL PROTECTED] wrote: ronnie sahlberg wrote: I dont think it is really realistic to have all autogenerated files always compile without any warnings. Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. Sounds like a reasonable solution. It would also have the advantage that we get a list of generated dissectors, which we currently don't have. But: Is there a makefile magic, so you can have different CFLAGS settings for the different lists? Remember that we are using implicit rules here. Having three lists shouldn't be difficult to add, but I don't know how to get the compile logic for it - however, I'm really not an expert on this. If there's a solution for this makefile problem, I think it's the way to go ... When it comes to the ANS2WRS dissectors are concerned I think that ANS2WRS is so mature now that maybe what we should do for those dissectors would instead be to remove them completely from epan/dissectors and make asn part of the build process. All these dissectors have their own makefile down in asn/* where one can set additional or different compiler flags compared to those used by the normal epan/dissectors. Full Ack, These asn dissectors could even be linked to a separate dll : libwireshark-asn.dll Wouldn't be better to move trunk/asn1 into trunk/epan/dissectors like the pidl ones? As far as i remember, the manual process of make copy_files and not having the asn compilation part of the build process was really just to wait doing so until we were sure asn2wrs was mature enough. -- 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] [Patch] pragma warning
On 3/28/07, Sebastien Tandel [EMAIL PROTECTED] wrote: I dont think it is really realistic to have all autogenerated files always compile without any warnings. Maybe we should instead split Makefile.common up into three parts : First part : normal dissectors Second part : ANS2WRS generated dissectors which take extra compile time flags and definitions to suppress artefacts from the compiler. Third part : PIDL generated dissectors that once again take extra compile parameters and definitions. Sounds like a reasonable solution. It would also have the advantage that we get a list of generated dissectors, which we currently don't have. But: Is there a makefile magic, so you can have different CFLAGS settings for the different lists? Remember that we are using implicit rules here. Having three lists shouldn't be difficult to add, but I don't know how to get the compile logic for it - however, I'm really not an expert on this. If there's a solution for this makefile problem, I think it's the way to go ... When it comes to the ANS2WRS dissectors are concerned I think that ANS2WRS is so mature now that maybe what we should do for those dissectors would instead be to remove them completely from epan/dissectors and make asn part of the build process. All these dissectors have their own makefile down in asn/* where one can set additional or different compiler flags compared to those used by the normal epan/dissectors. These asn dissectors could even be linked to a separate dll : libwireshark-asn.dll Wouldn't be the register_all_protocols() function problematic? We could create a plugin directory with all its paraphernalia and have the asn1 dissectors be loaded like a plugin. But still the best thing would be to have the asn1 generated dissectors inepan/dissectors and have them built from the Makefile. For the warnings we could have asn2wrs.py prepend the #pragma for unused static function right bellow the signature to the generated code (that's an ugly fix but I do not find a feasible way to have asn2wrs not creating the unused functions). The rest is monkey business: just to add the generated targets to the Makefile[s] like this: packet-h248.c: ../../asn1/h248/packet-h248-template.c \ ../../asn1/h248/packet-h248-template.h \ ../../asn1/h248/h248.cnf \ ../../asn1/h248/h248v3.asn [TAB](cd ../../asn1/h248 make copy_files ) packet-h248.h: packet-h248.c Luis Regards, Sebastien Tandel ___ 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] use Global Title as address in SCCP/SUA?
After a deeper analysis of some captures I have I've got to the conclusion that it is not a good idea. The GT is something different that what i believed it to be. I was considering a way to group together TCAP transactions taking into account that for some of those I've seen responses coming from a different opc than the dpc of the begin, now after a detailed analysis of those traces I noticed that this was due to a (unavoidable) misbehavior of the Flow Graph where the same SCTP packet carried more M3UA packets destined to different PCs and being pinfo-src set to the opc of the second M3UA packet the flow graph have the arrow coming from the wrong OPC. (That's a problem caused by the 1:1 relation between frame and packet wireshark assumes) Other than that I found MAP requests with two GT (from mobile's IMSI to HLR's) whose response to has different GTs (HLR's to VLR's), thus invalidating any assumption I made about the GT being determinant in establishing to which TCAP transaction does the packet belong that was the issue that had me coming with the (demential) idea. Luis On 3/28/07, Abhik Sarkar [EMAIL PROTECTED] wrote: Hmmm... OK, I have yet had to use the M3UA dissector, didn't know that. Anyway, in SUA/SCCP too, it is possible for the CgPA and CdPA to be only PC-SSN. So, if SCCP/SUA does set the transport address as GT, it should also set it to point code if only point code is available. Perhaps the others have something to say about this too. I am curious though, how do you think it will help? On 3/28/07, Luis Ontanon [EMAIL PROTECTED] wrote: There still be the IP addresses in net_src/net_dst. It would be much like M3UA does that replaces ip src and ip dst by the opc and dpc (which I do not doubt it is ok). What I wonder about is whether the GT is an address or should it be just taken as a port on a certain address. On 3/28/07, Abhik Sarkar [EMAIL PROTECTED] wrote: In case of SUA, wouldn't this mean pinfo-src and pinfo-dst would no longer have the IP end-points of the SCTP association? Is yes, is that desirable? On 3/28/07, Luis Ontanon [EMAIL PROTECTED] wrote: Would it be correct to add an AT_SS7_GT to the address types and have sccp/sua setting the GTs as pinfo-src pinfo-dst ??? Isn't the global title an actual (transport) address? Luis -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- 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
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
Re: [Wireshark-dev] [Wireshark-commits] rev 21185: /trunk/wiretap/ /trunk/wiretap/: mpeg.c
This should put an end to the buildbot lamenting about files that are not being considered as mpeg files. However I'm certain I was way too conservative when choosing what's a MPEG file (I had just MP3s), please add more types if you are aware of them. On 3/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21185 User: lego Date: 2007/03/25 07:01 PM Log: make the mpeg_open() more conservative checking whether there's ssome magic bytes at the beginning of the file. I added just one type of mpeg magic (ID3) there's probably more, please add. Directory: /trunk/wiretap/ ChangesPath Action +28 -1 mpeg.cModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- 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] [Wireshark-commits] rev 21191: /trunk/ /trunk/epan/dissectors/: Makefile.common packet-megaco.c /trunk/asn1/h248/: Makefile /trunk/plugins/megaco/: packet-megaco.c /trunk/plugins/:
Some changes slipped through without me noticing: Good thing: changes to asn1/ranap, that were commited already with packet-ranap.[ch] Neutral thing: changes to makefiles of asn1/snmp and asn1/h248 to add a target to test compilation. No bad things Luis On 3/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21191 User: lego Date: 2007/03/25 09:59 PM Log: migrate packet-megaco.c from plugins/megaco to epan/dissectors Directory: /trunk/epan/dissectors/ ChangesPath Action +1 -0 Makefile.commonModified +3335 -0 packet-megaco.cAdded Directory: /trunk/asn1/h248/ ChangesPath Action +4 -0 Makefile Modified Directory: /trunk/plugins/megaco/ ChangesPath Action +0 -3335 packet-megaco.cRemoved Directory: /trunk/plugins/ ChangesPath Action +0 -1 Makefile.am Modified +0 -1 Makefile.nmakeModified Directory: /trunk/asn1/ranap/ ChangesPath Action +5 -3 packet-ranap-template.cModified +15 -0 ranap.cnf Modified Directory: /trunk/asn1/snmp/ ChangesPath Action +6 -0 Makefile Modified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- 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] Looking for a definition document matching a dissector/plugin.
Simple dissector: packet-udp.[ch] implements RFC 768 Somewhat complex dissector: packet-sctp.[ch] implements RFC 2960 and others Very complex dissector: packet-xml.[ch] impelements (parts of) http://www.w3.org/XML/ as a rule of thumb most dissectors can be found in epan/dissectors and should have a pointer to the specs they implement. On 3/22/07, John [EMAIL PROTECTED] wrote: Hello, I have read much of the wireshark documents on how to program a dissector/plugin for a new packet protocol. Does anyone have a suggested packet type, that has a public protocol document, for an already defined dissector/plugin? This would help me to comprehend the remaining arcanum in writing a dissector plugin for a new packet protocol type. Any suggestions would be greatly appreciated. Cheers, John ___ 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] Addition of basic SRTP/SRTCP support
On 3/22/07, Neil Piercy [EMAIL PROTECTED] wrote: Attached are patches which provide a basic dissection of Secure RTP/RTCP profile: - display of the fields used in the SRTP SRTCP payloads - deliberate prevention of the normal dissection of the encrypted payloads - addition of a callable interface to add SRTP (rather than RTP) streams from signalling protocols. There are no signalling protocols using this yet - I have a currently private protocol which uses it, but I think SRTP/SRTCP support is of wider relevance. It has passed testing with our usage of these functions, but we certainly don't exercise all paths, so all comment and testing welcome. Ideally I (or somebody else) will go on to add decryption - some hooks are already in the header files for this - and subsequent dissection of the payload. I'd also welcome any views on how to handle RTP profiles in general in Wireshark, especially for non-signalled RTP captures: having lots of user preferences sounds to me like it will get out of hand, but without that I'm not sure how to deal with RTP payloads - de we need another layer of Decode As... for RTP payloads ? What about heuristics? is there some sort of magic we can use to determine if it is SRTP? is there a checksum or similar info we can check? Regards, Neil ___ 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] Display column additions for SCCP
I got it in my tree, it will be checked in with other changes I have that I haven't commited yet. I'll make it optional as the BSSAP, RANAP, TCAP, etc strings are appended and the column will have the payload's strings out of the screen. I'll remove the commas and the parenthesis as well. 789 2.8337373:1997 3:11356 BSSAP DATA CR(SLR=5685626,(BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request ) Luis On 3/22/07, Neil Piercy [EMAIL PROTECTED] wrote: Attached is a patch which adds display of DLR, SLR and Cause values to Column info for SCCP messages which our engineers have found useful. I think it might be worth adding to the code base unless anyone objects. There are also a couple of trivial robustness changes to better handle the case when the user has selected the wrong SCCP variant (ITU vs ANSI etc.). Regards, Neil ___ 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] Addition of basic SRTP/SRTCP support
Taking a quick look I discovered that there is http://www.minisip.org/index.html that uses MIKEY (an SDP extension?) and SRTP. MICKEY was recently added to wireshark (post 0.99.5) and it should carry all the information necessary to setup an SRTP conversation. It should be fasable to modify both srtp and mickey to have mickey setup srtp conversations much like sdp does with plain rtp. L. On 3/22/07, Neil Piercy [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luis Ontanon What about heuristics? is there some sort of magic we can use to determine if it is SRTP? is there a checksum or similar info we can check? The trouble with SRTP is basically a worse case than the trouble with all RTP profiles: they assume out-of-band signalling to have occurred to allow the receiver to decode them. In the case of SRTP there is a default SRTP profile which has a standard encryption and authentication algorithm, standard authentication tag size and standard (zero) MKI size, but there is no way to know whether any application has overridden the defaults by heuristics short of brute force trying of different tag sizes and algorithms. There are already 2 defined encryption algorithms, and the non-default one is in common usage too. Really it needs almost per stream preferences - maybe as well as the right-click Decode As... we should have a Configure this protocol with..., and a dialogue to allow e.g. the user to enter a decryption key, tag sizes etc which are saved in the conversatin data for the protocol and used to redissect it. Is this perhaps a general problem for other protocols too (e.g. SSL keys) ? I suspect some of the other preferences should really be per stream but we get away with them because captures commonly show many streams with the same prerences (e.g. SCCP is ITU or ANSI - rarely seen together!). Regards, Neil ___ 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] Display column additions for SCCP
Commited with the aforementioned changes in rev 21126 (with a whole lot of other stuff). On 3/22/07, Luis Ontanon [EMAIL PROTECTED] wrote: I got it in my tree, it will be checked in with other changes I have that I haven't commited yet. I'll make it optional as the BSSAP, RANAP, TCAP, etc strings are appended and the column will have the payload's strings out of the screen. I'll remove the commas and the parenthesis as well. 789 2.8337373:1997 3:11356 BSSAP DATA CR(SLR=5685626,(BSSMAP) Complete Layer 3 Information (DTAP) (MM) CM Service Request ) Luis On 3/22/07, Neil Piercy [EMAIL PROTECTED] wrote: Attached is a patch which adds display of DLR, SLR and Cause values to Column info for SCCP messages which our engineers have found useful. I think it might be worth adding to the code base unless anyone objects. There are also a couple of trivial robustness changes to better handle the case when the user has selected the wrong SCCP variant (ITU vs ANSI etc.). Regards, Neil ___ 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 -- 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] [Wireshark-commits] rev 21130: /trunk/epan/dfilter/ /trunk/epan/dfilter/: Makefile.am
Which warning? is it unique to grammar.c or it appears in other lemon generated parsers? On 3/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21130 User: sfisher Date: 2007/03/22 11:28 PM Log: Remove -Werror under gcc temporarily until a warning can be fixed in grammar.c Directory: /trunk/epan/dfilter/ ChangesPath Action +0 -4 Makefile.amModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- 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] [Wireshark-commits] rev 21131: /trunk/gtk/ /trunk/gtk/: voip_calls.c
Sorry about that one... On 3/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21131 User: ulfl Date: 2007/03/22 11:29 PM Log: fix new warnings Directory: /trunk/gtk/ ChangesPathAction +3 -3 voip_calls.cModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- 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] [Wireshark-commits] rev 21130: /trunk/epan/dfilter/ /trunk/epan/dfilter/: Makefile.am
gone with rev 21134 On 3/23/07, Luis Ontanon [EMAIL PROTECTED] wrote: Which warning? is it unique to grammar.c or it appears in other lemon generated parsers? On 3/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21130 User: sfisher Date: 2007/03/22 11:28 PM Log: Remove -Werror under gcc temporarily until a warning can be fixed in grammar.c Directory: /trunk/epan/dfilter/ ChangesPath Action +0 -4 Makefile.amModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan -- 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] [Wireshark-commits] rev 21130: /trunk/epan/dfilter/ /trunk/epan/dfilter/: Makefile.am
These were not : I'm working on them. grammar.c(1157) : warning C4761: integral size mismatch in argument; conversion supplied grammar.c(1206) : warning C4761: integral size mismatch in argument; conversion supplied grammar.c(1217) : warning C4761: integral size mismatch in argument; conversion supplied grammar.c(981) : warning C4761: integral size mismatch in argument; conversion supplied On 3/23/07, Luis Ontanon [EMAIL PROTECTED] wrote: gone with rev 21134 On 3/23/07, Luis Ontanon [EMAIL PROTECTED] wrote: Which warning? is it unique to grammar.c or it appears in other lemon generated parsers? On 3/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21130 User: sfisher Date: 2007/03/22 11:28 PM Log: Remove -Werror under gcc temporarily until a warning can be fixed in grammar.c Directory: /trunk/epan/dfilter/ ChangesPath Action +0 -4 Makefile.amModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan -- 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] [Wireshark-commits] rev 21077: /trunk/gtk/ /trunk/gtk/: voip_calls.c voip_calls.h voip_calls_dlg.c
That's odd because I checked in changes to packet-sccp.h before those to voip_calls*.[ch] see http://anonsvn.wireshark.org/viewvc/viewvc.py/trunk/epan/dissectors/packet-sccp.h?r1=21076r2=21075pathrev=21076diff_format=l In fact the buildbot seems happy with it. On 3/21/07, Ulf Lamping [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21077 User: lego Date: 2007/03/21 12:59 AM Log: Add the sccp tap to the VoIP Calls Tap (which by now should be renamed to just Calls) but that's for later. Now it does H323, SIP, MGCP, ISUP/BICC, RANAP, BSSAP, H.248 and others... Directory: /trunk/gtk/ ChangesPathAction +174 -26 voip_calls.cModified +8 -1 voip_calls.hModified +3 -0 voip_calls_dlg.cModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits Get some errors now: voip_calls.c voip_calls.c(2883) : error C2039: 'assoc' : is not a member of '_sccp_msg_info_t' C:\Wireshark\subversion\epan/dissectors/packet-sccp.h(40) : see declaration of '_sccp_msg_in fo_t' voip_calls.c(2901) : error C2039: 'calling_party' : is not a member of '_sccp_assoc_info_t' C:\Wireshark\subversion\epan/dissectors/packet-sccp.h(48) : see declaration of '_sccp_assoc_ info_t' ... Did you missed to check in all files or something like that? Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Are tap-listeners called for malformed packets?
It depends on when it goes malformed and whether or not the call to tap_queue_packet() was made or not. On 3/21/07, Lars Ruoff [EMAIL PROTECTED] wrote: Hi, if i have a tap listener registered for protocol X, will it be called also for a malformed packet of protocol X ? (I.e. a packet which was passed to dissector X, but there was an exception thrown during dissection) br, Lars Ruoff ___ 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] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Inline comments... On 3/20/07, Martin Mathieson [EMAIL PROTECTED] wrote: Currently, you don't tend to even notice new warnings that you introduce on your own platform, as they get lost in the general compilation noise. Part of the problem (when working from the command-line at least) is how much output is generated, and how far you'd need to scroll back to see the compilation of the file you've just changed. For speed, I spend much of the time only compiling the one file, e.g. I'll run 'make epan/dissectors/packet-whatever.lo' until my changes compile. This makes my affect on the number of warnings pretty obvious. Which I believe is what we should all do. I been following a policy myself is that for every file I modify I remove all the warnings I get (well I leave there those for static functions not used and some about signedness of strings). If at least the committers take an approach of squelching warnings one file at a time, while we work on that file, little by little we can get rid of most (if not all) of them... I do not think we should deeply involve ourselves on a project of fixing warnings as a task on its own... I think our time is better used by either adding new features or fixing factual bugs, and while at it remove the warnings from the files we edit/patch. Incidentally, if anyone knows the right knob to stop gcc accepting variable declarations in the middle of a block of code, it really needs turning on. I manage to mess this up almost every time I submit a patch... I think -Wdeclaration-after-statement is what you need. I think that's what I need as well! -- 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] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On 3/21/07, Guy Harris [EMAIL PROTECTED] wrote: On Mar 20, 2007, at 5:21 PM, ronnie sahlberg wrote: How do you mean? Emacs is the only true editor! No, it's not: http://www.gnu.org/fun/jokes/ed.msg.html There *must* be an ed mode for emacs. so the point is that... After some years using emacs I understood it was emacs to be using me. In fact, by then, most of my editing time was spent in info mode learning how to use things I would have never ever needed. -- 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] crypt-sha1
If they are in the hmac code that's probably my fault when I put it back in the repo. I don't think it will be causing any problems, as we do not run in any 16 bit platform guint is either equal to guint32 or larger (64) and the way the code is written is protected from both endianity and word lenght (as far as it is at least 32 bits). However, go ahead and change it. On 3/16/07, Sebastien Tandel [EMAIL PROTECTED] wrote: Hi, just for curiosity purposes : I'm looking at crypt-sha1.c, and seeing variables defined as guint and not as guint32. On the other hand, we can also read in the header file that Anders changed uint to uint32_t in 2004. Are there some conflicts? Are there some reasons to keep the guint instead of guint32? Regards, Sebastien Tandel ___ 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] TFO Package problem
I added several packages (and Tandem Free Operation was one of those) after 0.99.5 was released. If you try the latest development versions you'll find it decoded. you can download a build of the latest development version from http://www.wireshark.org/download/automated/ . On 3/16/07, melike pinar ata [EMAIL PROTECTED] wrote: H248 can identify the 3G TFO Package (3gpp 29.232, section 15.2.2) , but cannot decode the parameters defined in this package. Below is an example: . localControlDescriptor streamMode: inactive (3) propertyParms: 3 items Item propertyName: 00310001 3G TFO Control (0031) Package: 3G TFO Control (0x0031) Parameter ID: 0x0001 value: 1 item Unknown Parameter: 0A0101 Item propertyName: 00310002 3G TFO Control (0031) Package: 3G TFO Control (0x0031) Parameter ID: 0x0002 value: 1 item Unknown Parameter: 04020202 .. Regards, _ Yagmura yakalanmamak için sadece semsiyenize degil, MSN hava durumuna güvenin! http://www.msn.com.tr/havadurumu/ ___ 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] crypt-sha1
This I can change by hand... but as a rule of thumb you should
compress patches you send to the list, that's because some MUAs mangle
text files (e.g. mine does).
Luis
On 3/16/07, Sebastien Tandel [EMAIL PROTECTED] wrote:
Thanks for the answer.
And here is the patch to change guint - guint32 in the hmac function.
Regards,
Sebastien Tandel
Luis Ontanon wrote:
If they are in the hmac code that's probably my fault when I put it
back in the repo.
I don't think it will be causing any problems, as we do not run in any
16 bit platform guint is either equal to guint32 or larger (64) and
the way the code is written is protected from both endianity and word
lenght (as far as it is at least 32 bits).
However, go ahead and change it.
On 3/16/07, Sebastien Tandel [EMAIL PROTECTED] wrote:
Hi,
just for curiosity purposes :
I'm looking at crypt-sha1.c, and seeing variables defined as guint and
not as guint32. On the other hand, we can also read in the header file
that Anders changed uint to uint32_t in 2004.
Are there some conflicts? Are there some reasons to keep the guint
instead of guint32?
Regards,
Sebastien Tandel
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Index: epan/crypt/crypt-sha1.c
===
--- epan/crypt/crypt-sha1.c (révision 20799)
+++ epan/crypt/crypt-sha1.c (copie de travail)
@@ -293,10 +293,10 @@
/*
* Output HMAC-SHA-1(key,buf)
*/
-void sha1_hmac( const guint8 *key, guint keylen, const guint8 *buf, guint
buflen,
+void sha1_hmac( const guint8 *key, guint32 keylen, const guint8 *buf,
guint32 buflen,
guint8 digest[20] )
{
-guint i;
+guint32 i;
sha1_context ctx;
guint8 k_ipad[64];
guint8 k_opad[64];
Index: epan/crypt/crypt-sha1.h
===
--- epan/crypt/crypt-sha1.h (révision 20799)
+++ epan/crypt/crypt-sha1.h (copie de travail)
@@ -39,7 +39,7 @@
void sha1_starts( sha1_context *ctx );
void sha1_update( sha1_context *ctx, const guint8 *input, guint32 length );
void sha1_finish( sha1_context *ctx, guint8 digest[20] );
-void sha1_hmac( const guint8 *key, guint keylen, const guint8 *buf, guint
buflen,
+void sha1_hmac( const guint8 *key, guint32 keylen, const guint8 *buf,
guint32 buflen,
guint8 digest[20] );
#endif /* crypt-sha1.h */
___
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] problem :)
Try http://www.wireshark.org/download/automated/win32/wireshark-setup-0.99.6-SVN-21025.exe and see if the problem has been fixed. and, Please try to explain the problem. On 3/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi I am working for a company and we used your source MEGACO/ H248 but there is a problem about TFO controls.Can we solve it??Wher should I start?? www.turkcell.com.tr Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedir. TURKCELL bu mesajin icerdigi bilgilerin dogrulugu veya eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve TURKCELLin goruslerini yansitmayabilir Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. TURKCELL makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the information transmission, reception, storage or use of such in any way whatsoever. The opinions expressed in this message belong to sender alone and may not necessarily reflect the opinions of TURKCELL. This e-mail has been scanned for all known computer viruses. ___ 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] [PATCH][UPDATE] ptvcursor : one step further?
On 3/11/07, Sebastien Tandel [EMAIL PROTECTED] wrote: Hi Jeff, Thanx for reviewing it ... I had forgot about this one :) I will write the README section soon. About the memory leak with g_renew, you're right of course. Unfortunately there is no ep_realloc ... is there any reasons to /not/ implement one ? I've no idea of the complexity to implement one either ... There's no need, just ep_alloc another block, and memcpy over it. It's going to be freed before the next packet anyway. Regards, Sebastien Tandel Jeff Morriss wrote: Sebastien Tandel wrote: Hi, I've updated the patch for ptvcursor taking into account the ideas of Guy. Features supported by ptvcursor : - multiple levels (256 max.), allocation per 8 levels. - Two new functions creating an item in the tree and pushing a subtree at the same time. These two functions accept an undefined length (SUBTREE_UNDEFINED_LENGTH). The length of the item is set once the subtree is pop'ed. 1) ptvcursor_add_with_subtree 2) ptvcursor_add_text_with_subtree If it sounds good I'll do a section for the README.developer. Well, it looks OK to my (simple) eyes. One thing looks wrong to me, though: using g_renew() to malloc memory but there are also DISSECTOR_ASSERT()s in the code. If the assertion is taken dissection of that packet will stop and the memory will be leaked. Shouldn't that be changed to ep_ malloc'd memory? Unless anyone else has comments, could you write that README.developer patch, too? ___ 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] private development and syncing process ...
Hi, If you want to discuss about how to write a dissector, how to fix a bug, about adding a new feature or similar development issues this is the right forum. If you ever want your patch applied to the trunk so it is made available to everyone with the rest of wireshark this is the right place to post it. But this is the wrong forum to discuss about distributing free software exclusively for use within a company. Software Licensing is a Legal Issue, the kind of issues you discuss with a lawyer not with a group of developers. PS. The folks at http://www.opensource.org have a mailing list that looks closer to be the right place to ask this kind of questions. On 3/9/07, Ravi Kondamuru [EMAIL PROTECTED] wrote: Hi, I am looking for a model on how wireshark dissector/wiretap addons are developed exclusively for use within a company. I understand GPL allows that. I just want to know how it is developed, synced with wireshark open source base etc? Currently this is what I intend to do: 1. Get source of a released version of wireshark 2. Apply my patch and provide that installer internally. 3. Do (1) and (2) everytime a release happens to stay current. Any other ideas? thanks, Ravi. ___ 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] [SPAM] - Re: WireShark + LUA - Email found in subject
Well, there's little confidential information in H.248 as far as no
BICC/SIP/H323 traffic is seen there's no way to trace back a call to a
specific user just from Megaco. I been a troubleshooter on split
telephony systems for quite few years already and one of the hardest
things you have to deal while troubleshooting MGws is that there's no
way to know which call belongs to which user without interrogating the
MGC.
You could filter h248 away from the capture and see if that crashes.
However you can do few things:
You can give me a backtrace of the stack at the moment it crashes. (To
know where it crashes can *really* help).
try to get tshark to crash, isolate the one packet on which the crash
occurred and see if it crashes by itself.
On 3/5/07, Verriere Joseph [EMAIL PROTECTED] wrote:
Hi,
I installed the last version: build 20973 and it crashes the same way.
Trying to debug, the part of my code which crashes is the one I gave you:
local numFrames = Field.new (h248.ctx.cmd)
local extract_com = Listener.new()
function extract_com.packet(pinfo, Tvb)
local frames = { numFrames() }
end
I'm sorry but I can't send you the capture file because of confidentiality.
I'm working for a society whichs works with phone companies and this capture
comes from one of them.
I hope you can still help me.
Joseph Verrière
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] la part de Luis Ontanon
Envoyé : dimanche 4 mars 2007 17:03
À : Developer support list for Wireshark
Objet : [SPAM] - Re: [Wireshark-dev] WireShark + LUA - Email found in
subject
Before sending in a huge file can you try a buidbot build = 20972
from http://www.wireshark.org/download/automated/
I checked in a fix that might solve your issue.
Luis
On 3/4/07, Luis Ontanon [EMAIL PROTECTED] wrote:
As I'm the one that wrote both the Lua interface and a good part of
the h248 dissector I think I can help you...
There are probably two bugs that cause this crash: one I know already
regarding the way rethrown exceptions are mis-handled in windows which
is the cause of the actual crash. I'm still deciding how to approach
this: either I remove the code that rethrows exceptions or modify the
way exceptions are handled. This is not going to be fixed soon.
And there's probably another one triggered by your code. For that I
need two things from you the lua code and the capture file that
triggered the crash.
BR
Luis
On 2/27/07, Verriere Joseph [EMAIL PROTECTED] wrote:
Hello,
I'm trying to use LUA but I get a bug on Tshark when I launch my program.
I do this:
local numFrames = Field.new (h248.ctx.cmd)
local extract_com = Listener.new()
function extract_com.packet(pinfo, Tvb)
local frames = { numFrames() }
end
There, without doing anything with frames, I get an error but not at the
beginning but after a while (about 1000 frames from a capture file which
has more than 175000 of them). I get an error in a window which tells me
that TShark has encountered a problem and must shut down. If I launch the
debug program, I get in Visual C++ and I get the message: unhandled
exception.
Can someone help me?
Thanks
Ce message et tout document joint sont confidentiels et à l'intention
exclusive des destinataires. S'ils vous ont été adressés par erreur,
merci d'en informer immédiatement l'expéditeur et de les détruire. Toute
copie, diffusion ou utilisation non autorisée est interdite. Tout message
électronique est susceptible d'altération : Astellia décline toute
responsabilité si le message ou les documents joints ont subi une
quelconque modification.
This message and any attachment are confidential and intended solely to
its addressees. If you are not the intended recipient please cancel it
and inform immediately the sender. Any unauthorised copy or dissemination
is prohibited. Electronic messages may be altered: Astellia shall not be
liable for those circumstances.
___
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
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http
Re: [Wireshark-dev] Ronnie's SVN 20251 looks quite strange to me - is there a reason?
On 3/5/07, ronnie sahlberg [EMAIL PROTECTED] wrote: Feel free to reverse that change. It was part of an effort to start refactoring the code so that it would eventually become possible to multithread wireshark, but the work required to implement everything required is just too massive to be realistic. Instead of just starting to code we should make a list of what's needed I created http://wiki.wireshark.org/Development/mutithreading listing the two main tasks I have identified. Luis On 3/5/07, Ulf Lamping [EMAIL PROTECTED] wrote: Hi! In an attempt to fix bug 1419 I've stumbled over a strange change that Ronnie Sahlberg made in SVN 20251 and I'm asking if there's a reason for it that I just don't see. The comment to 20251: break out dfcode from the capture file structure and declare it locally where it is needed. allocate and release the dfcode program as needed instead of having it hang around in the capture file structure. this will ensure that dfcode will not have longer than se scope lifetime in case we need that property of it later The problem with this change: It's calling the line: dfilter_compile(cf-dfilter, dfcode); each time cf_continue_tail() get's called, which takes place when new packets are added to the packet list while CAPTURING (this update takes place SEVERAL times a second for an Update list in real time capture). So we're computing the whole display filter (which might be very long) over and over and over again while capturing, to avoid some minor memory consumption / allocation problems?!? That makes packet drops more likely without a good reason!!! In addition, I don't see a good reason for this re-compiling at all! The common sequence for an Update list in real time capture will look like: cf_start_tail cf_continue_tail cf_continue_tail cf_continue_tail ... cf_continue_tail cf_finish_tail So why not simply dfilter_compile() at cf_start_tail() and dfilter_free() at cf_finish_tail() ?!? Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev -- 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] Plugin?
I think that unless you explain a little better what you are trying to do no one will be able to help you. On 3/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, i have start an plugin for wireshark 0.99.5 so i need a bit support to complete the plugin my packet-foo.c is based at the void example in the devolper guide i do it now static - Example =Foo, Version=9.0.1.0, Culture=neutral, (is in the dump) - with proto_tree_add_item(foo_tree, hf_foo_version, tvb, 39, 7, FALSE); - get i Version: 9.0.1.0 (is my output at this moment) now i search for an dynamic version the will search the second = and get it to the next , can anyone help me please Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken http://www.klarmobil.de/index.html?pid=73025 ___ 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] WireShark + LUA
Before sending in a huge file can you try a buidbot build = 20972
from http://www.wireshark.org/download/automated/
I checked in a fix that might solve your issue.
Luis
On 3/4/07, Luis Ontanon [EMAIL PROTECTED] wrote:
As I'm the one that wrote both the Lua interface and a good part of
the h248 dissector I think I can help you...
There are probably two bugs that cause this crash: one I know already
regarding the way rethrown exceptions are mis-handled in windows which
is the cause of the actual crash. I'm still deciding how to approach
this: either I remove the code that rethrows exceptions or modify the
way exceptions are handled. This is not going to be fixed soon.
And there's probably another one triggered by your code. For that I
need two things from you the lua code and the capture file that
triggered the crash.
BR
Luis
On 2/27/07, Verriere Joseph [EMAIL PROTECTED] wrote:
Hello,
I'm trying to use LUA but I get a bug on Tshark when I launch my program.
I do this:
local numFrames = Field.new (h248.ctx.cmd)
local extract_com = Listener.new()
function extract_com.packet(pinfo, Tvb)
local frames = { numFrames() }
end
There, without doing anything with frames, I get an error but not at the
beginning but after a while (about 1000 frames from a capture file which
has more than 175000 of them). I get an error in a window which tells me
that TShark has encountered a problem and must shut down. If I launch the
debug program, I get in Visual C++ and I get the message: unhandled
exception.
Can someone help me?
Thanks
Ce message et tout document joint sont confidentiels et à l'intention
exclusive des destinataires. S'ils vous ont été adressés par erreur, merci
d'en informer immédiatement l'expéditeur et de les détruire. Toute copie,
diffusion ou utilisation non autorisée est interdite. Tout message
électronique est susceptible d'altération : Astellia décline toute
responsabilité si le message ou les documents joints ont subi une
quelconque modification.
This message and any attachment are confidential and intended solely to its
addressees. If you are not the intended recipient please cancel it and
inform immediately the sender. Any unauthorised copy or dissemination is
prohibited. Electronic messages may be altered: Astellia shall not be
liable for those circumstances.
___
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
--
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] WireShark + LUA
As I'm the one that wrote both the Lua interface and a good part of
the h248 dissector I think I can help you...
There are probably two bugs that cause this crash: one I know already
regarding the way rethrown exceptions are mis-handled in windows which
is the cause of the actual crash. I'm still deciding how to approach
this: either I remove the code that rethrows exceptions or modify the
way exceptions are handled. This is not going to be fixed soon.
And there's probably another one triggered by your code. For that I
need two things from you the lua code and the capture file that
triggered the crash.
BR
Luis
On 2/27/07, Verriere Joseph [EMAIL PROTECTED] wrote:
Hello,
I'm trying to use LUA but I get a bug on Tshark when I launch my program.
I do this:
local numFrames = Field.new (h248.ctx.cmd)
local extract_com = Listener.new()
function extract_com.packet(pinfo, Tvb)
local frames = { numFrames() }
end
There, without doing anything with frames, I get an error but not at the
beginning but after a while (about 1000 frames from a capture file which has
more than 175000 of them). I get an error in a window which tells me that
TShark has encountered a problem and must shut down. If I launch the debug
program, I get in Visual C++ and I get the message: unhandled exception.
Can someone help me?
Thanks
Ce message et tout document joint sont confidentiels et à l'intention
exclusive des destinataires. S'ils vous ont été adressés par erreur, merci
d'en informer immédiatement l'expéditeur et de les détruire. Toute copie,
diffusion ou utilisation non autorisée est interdite. Tout message
électronique est susceptible d'altération : Astellia décline toute
responsabilité si le message ou les documents joints ont subi une quelconque
modification.
This message and any attachment are confidential and intended solely to its
addressees. If you are not the intended recipient please cancel it and inform
immediately the sender. Any unauthorised copy or dissemination is prohibited.
Electronic messages may be altered: Astellia shall not be liable for those
circumstances.
___
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] [Wireshark-commits] rev 20947: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-sctp.c
On 2/28/07, Michael Tuexen [EMAIL PROTECTED] wrote: On Feb 28, 2007, at 2:09 PM, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20947 User: lego Date: 2007/02/28 02:09 PM Log: SCTP TSN analysis part 1. Up and running. As it is analysis will stop at TSN rollover (0x-0x). Is it possible to get rid of that limitation? Yes, I'm still evaluating the best way to do it. BTW. I discovered I have to fix Gap Blocks before that. And It will start to misbehave when a TSN is seen again in the same half association (that's a case where an out-of-memory error will probably had happened before). That seems to be acceptable. It still needs testing. Directory: /trunk/epan/dissectors/ ChangesPath Action +238 -325 packet-sctp.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 -- 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] [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
Re: [Wireshark-dev] [Wireshark-commits] rev 20925: /trunk/ /trunk/: nio-ie5.c
Couldn't this be made to be an If-Modified-Since request instead? Luis On 2/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20925 User: ulfl Date: 2007/02/25 03:44 PM Log: don't cache the downloaded file, so changes in the update file will have an effect while experimenting Directory: /trunk/ ChangesPath Action +3 -2 nio-ie5.c Modified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- 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] [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
Yes you are right I have to re-design the matching (and grouping!) of paths in an association. I did not understand from the RFC the fact that vtags were relative just to a direction of a path and not to all the paths of one direction in an association. As soon as I started to analyze captures with a high volume of traffic I noticed that I would be getting SACKs coming back from a different path for the same association. Now my problem is in cases like one capture I have (I can't make it public) I have 2 endpoints for each node of an association and 2 paths in each direction of an association each with its own vtag. (A1-B1, A2-B2 and B1-A1, B2-A2) In fact Analyze-SCTP-Show All Associations sees it as 4 associations. As SACKs to an upstream TSN might come from whichever of the 2 downstream paths I cannot just use the vtag. Using IP addresses doesn't help either as there's no way to relate them. So, per my understanding I have to implement helper tables to match the various paths of an association. The table will have the following fileds: srcport, dstport, src_address_list, dst_address_list Luis. P.S. I bought my first lottery ticket ever. On 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
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
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) and plvt_table indexed by port_label and verification_tag of one direction which I assume to be unique. 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. 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! 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. 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). 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 +36 -30packet-h248-template.cModified +20 -14packet-h248-template.hModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan -- 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] Cross-compile wireshark, without using gnutls
--without-gnutls ? On 2/22/07, David Wuertele [EMAIL PROTECTED] wrote: The configure script for wireshark decides that my host has libgnutls, but since I am cross-compiling to a target that does not, I want to disable it. I have tried --disable-libgnutls, LIBGNUTLS_CONFIG=no, and a number of other hacks, but there is no convincing wireshark. It finds my hosts installation and decides to use it no matter what I say. Can anyone tell me how to force wireshark's configure to disable libgnutls? Thanks, Dave ___ 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] Cross-compile wireshark, without using gnutls
fixing automake scripts that takes a long long time... what you can try is renaming gnutls/gnutls.h in your system to something else before calling ./configure and rename it back after configure has run. That way the configure script will fail finding an usable gnutls and will refuse it. On 2/22/07, David Wuertele [EMAIL PROTECTED] wrote: Luis Ontanon [EMAIL PROTECTED] writes: --without-gnutls ? That was one of the first things I tried. Unfortunately, my host has gnutls installed, and the configure script finds it despite my admonitions not to. I tried the following configure arguments: --without-gnutls --with-gnutls=no --with-libgnutls-prefix=/nowhere --disable-gnutls --enable-gnutls=no and the following environment variables: LIBGNUTLS_CONFIG=no LIBGNUTLS_CFLAGS= LIBGNUTLS_LIBS= no_libgnutls=yes All to no avail. Dave ___ 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] Problem LUA+H248
Well, this is an odd one... the way ASN1 elements are added to the tree is somewhat twisted... I'll be investigating how these are made... What you want is h248.id that is a byte-string containing the termination id you are looking for terminationId is something else in the syntax. as a rule of thumb test if a filter works... B.T.W. have you tried H.248's Keep Persistent Context Information Preference... it adds a tree that does context analysis. Luis On 2/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I have a problem using LUA with h248. I wrote a script trying to take only one communication out of a capture file. The problem is when I want to have the terminationID, it doesn't work. He doesn't find it. Here are the code lines: terminationId = Field.new(h248.terminationID) extract_com = Listener.new() function extract_com.packet(pinfo) print (terminationId()) end I only get a blank line. It works with command or others but there are some which doesn't work as terminationID, contextID, mesID... Is it me who isn't using it correctly or a bug? Thanks for your help. Joseph ___ 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] [PATCH] New menu items to copy packet data
That sounds familiar... Just today I noticed that if I enable Lua on windows the Tools menu (that is hidden unless Lua uses it) ends up as a submenu of User Tables. As in your case this infact does not happen on my mac. The reason of the different behaviour is still unknown to me. As I think it probably has to do with the changes I made to menu.c to add the User Tables menu I planned to investigate it on the next weekend. BTW I trying to understand an odd crash I see on windows after an exception (due to a very corrupt packet) is thrown that does not happen against my mac. Luis On 2/20/07, Stephen Fisher [EMAIL PROTECTED] wrote: On Mon, Feb 19, 2007 at 03:50:57PM -0800, Stephen Fisher wrote: However, The statistics menu is messed up in my Windows build environment (MSVC 2005 EE). Everything is one off from the group it should be in. The HTTP option is still buried within the content list menu. Anyone else seeing this? I'm still trying to figure out why this is happening but if anyone has an idea let me know. I should note that it looks fine in Unix. Steve ___ 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] help_dlg.c(49) : fatal error C1083: Cannot open include file: 'htmlhelp.h': No such file or directory
I got stuck at this point while compiling on windows (MSVC6), what am I missing? Thanks, Luis -- 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] Patch for crash in uat_gui.c
Committed revision 20813. Thanks! On 2/14/07, Peter Johansson [EMAIL PROTECTED] wrote: Hi! I have provided a patch for a crash that occurs in uat_gui.c if from the Edit preferences... button when you choose Protocols - DLT_USER - the Edit... button - the New button - the Cancel button. The crash happens because dd gets freed prior to traversing its internal structure, hence I moved the call to g_free for dd beneath the traversal of the dd internals. Regards, Peter Index: C:/wireshark-win32-libs/gtk/uat_gui.c === --- C:/wireshark-win32-libs/gtk/uat_gui.c (revision 20793) +++ C:/wireshark-win32-libs/gtk/uat_gui.c (working copy) @@ -371,10 +371,11 @@ if (dd-is_new) g_free(dd-rec); g_ptr_array_free(dd-entries,TRUE); window_destroy(GTK_WIDGET(dd-win)); - g_free(dd); while (dd-tobe_freed-len) g_free( g_ptr_array_remove_index_fast(dd-tobe_freed, dd-tobe_freed-len - 1 ) ); + g_free(dd); + return TRUE; } ___ 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] SCTP retransmissions an RTT
I need to implement the identification of retransmitted packets and calculation of RTT to the sctp dissector. - Is someone already working on this? - other than RFC 2960 (sec. 6.3) what other rfcs I must read in order to implement these? - are there any caveats I must be aware before starting this venture? Thanks, Luis -- 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] User Accessible Tables, please review
On 2/11/07, Stephen Fisher [EMAIL PROTECTED] wrote: On Mon, Jan 29, 2007 at 04:19:46AM +0100, Luis Ontanon wrote: I plan to write a gui for these tables and the table (or a button to open an editor window) will appear in preference module. I noticed that the UAT editor doesn't have a close or cancel button. It also has a save button, whereas we have gotten rid of them by default on all dialogs. Thanks for the comment, I'll have it mimic the preferences dialog. Having three buttons for: Apply: reloads the current file, Cancel: reverts in memory to what's being last saved (no need to reload), OK: that saves to file and reloads. -- 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] Dissecting XML payload
There's not full DTD support (some features are not implemented, some DTDs need to be massaged) but there's enough to obtain fileds against which to filter from a DTD file. To have your DTD file loaded you can copy it in the dtds/ directory that you can find in the data directory (the one with wireshark.exe on windows or $PREFIX/share/wireshark on *nix). You can find some working DTDs in there too. Luis On 2/6/07, Jim L Hartwig [EMAIL PROTECTED] wrote: Want to dissect XML payload in a TCP packet. I have the dissector working (dissecting the header), but now I need to dissect the XML payload. http://wiki.wireshark.org/XML mentions it can be done if you have the Document Type Definition (DTD) file. Has anyone done this or have an example they could point me to ? Assume I have a (DTD) file. Regards, Jim Hartwig Texas Engineering Center Voice:972. 952. 3307 Raynet: 427. 3307 ___ 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] Dissector works with .pcap file but does not work with .pkt file
The way things work *.pkt can be in any format, wiretap recognizes file types by its contents. Can you be more specific about the file format? If you use capinfos, what it says about it? BTW, In order to have it fixed we need two files that show this behaviour. You could write a bug report on this and attach a pcap and a pkt (small) files showing this behaviour to it. Luis On 2/6/07, Jim L Hartwig [EMAIL PROTECTED] wrote: Has anyone encountered this problem ? Regards, Jim Hartwig Texas Engineering Center Voice:972. 952. 3307 Raynet: 427. 3307 ___ 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] Add checksum validation option for MTP2
On 2/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello Jeff, Thank you for your comments, I will follow your advices and request a new DLT for MTP2 with FCS. But before, I will, first, ask for the agreement of the board manufacturer. I hope they will not disagree.. In the same time, if someone has samples of use for the MTP2 DLT, it could be very helpfull. Maybe, the right way will be to have : - DLT_MTP2_noFCS for K12 files, k12 files use a single WTAP_ENCAP_K12 and the actual protocol is choosen by name by the user associating it with the .stk file declared for a given port. As far as the dissecctor handle called by the name mtp2 does not change its behaviour there's no problem. - DLT_MTP2_FCS, for this board. - and to keep the current DLT_MTP2 for compatibility. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Add checksum validation option for MTP2
IMO you could do like packet-eth.c does, it registers two dissectors (eth_withfcs, eth_withoutfcs) anyway and has a common dissector that will determine one or the other (based on a preference maybe). You could register one to handle ENCAP_WITH_FCS and ENCAP_WITHOUT_FCS or use heuristics instead. However you decide to go, I believe that having two registered dissectors instead of an alternative one is a good idea anyway. Luis On 2/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi luis, Right, it seems the problem with the FCS is not only a problem of Datalink. Up to now, if you read a K12 file, and if the record/file for the stack is pointing to mtp2, the MTP2 dissector is called. With the current MTP2 dissector, there is no problem with .rf5 record, because the FCS are ignored. But, if you are reading a MTP2 frame from an other capture device, the FCS are present(at least for the board I am using). And in the ITU Q703 norma, the FCS are mentionned too, so they should be present. So, the problem is how to find a solution to have a MTP2 dissector compatible with both format (without FCS, and with FCS). My first patch was with an option to have a checksum validation. But, if the option is enabled, the rf5 record are detected as malformed, because of these 2 bytes missing, (and because the SCCP dissector has not be modified to accept such frame). Now, if I change the datalink to indicate the presence of Checksum, do I will have to call a specific MTP2_FCS dissector ? Or is it possible to read the datalink on the pinfo structure in the current MTP2 dissector, to call a specific code for the FCS validation ? In this case, it could work with K12 files too, as the datalink is set to WTAP_ENCAP_K12. Am I rigth, or do I missed something ? Best regards Florent Luis Ontanon [EMAIL PROTECTED] To: Developer support list for Wireshark Sent by: wireshark-dev@wireshark.org [EMAIL PROTECTED] cc: reshark.org Subject: Re: [Wireshark-dev] Add checksum validation option for MTP2 05/02/2007 15:41 Please respond to Developer support list for Wireshark On 2/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello Jeff, Thank you for your comments, I will follow your advices and request a new DLT for MTP2 with FCS. But before, I will, first, ask for the agreement of the board manufacturer. I hope they will not disagree.. In the same time, if someone has samples of use for the MTP2 DLT, it could be very helpfull. Maybe, the right way will be to have : - DLT_MTP2_noFCS for K12 files, k12 files use a single WTAP_ENCAP_K12 and the actual protocol is choosen by name by the user associating it with the .stk file declared for a given port. As far as the dissecctor handle called by the name mtp2 does not change its behaviour there's no problem. - DLT_MTP2_FCS, for this board. - and to keep the current DLT_MTP2 for compatibility. ___ 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] Option to allow processing of unrecognised Data-link level PCAP file
If the DLT is to be a stadard one why not register it? If it is a private one why not use DLTS USER0..USER15. There's the DLT User A-D dissector in preferences that allow you to specify any given dissector to be used against pcap files with those encapsulations (I often do). Luis On 2/5/07, Douglas Pratley [EMAIL PROTECTED] wrote: Hi guys At the moment, if Wireshark comes across an unexpected data-link level type in the global header when reading a PCAP file, it completely rejects the file. This doesn't allow the user to apply any intelligence, e.g. by manipulating the wtap_encap dissector table using Lua. A quick hack prototype suggests that it is possible to read unknown or mis-labelled data; the frame dissector just hands it off to the data dissector. a) Would adding an option allowing unrecognised data to be read in from a PCAP file cause any side-effects that I haven't spotted? The only changes other than setting up the option would be in libpcap.c:libpcap_open, so that it would continue processing an unrecognised type. b) What would the best way be of adding this option? My first thought was to make it a preference, but the wiretap library has no dependencies on the epan module where the preferences are. It looks like it would take some careful wiring to add in the option without introducing a dependency (which I think would break some of the apps). Setting up a new (non-protocol) preference might also have to be duplicated across tshark and wireshark, which is ugly. 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 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 -- 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] Using Lua to parse TCP encapsulated IP protocol
Well the Lua API should intercept those conditions that would cause a crash and notify an error to the user, a crash is a bug regardless of how you get to it. I'll take a look at that data to see if that triggersa creash if calling the IP dissector directly. Luis 1/29/07, Scott Robinson [EMAIL PROTECTED] wrote: Hi Luis, I tried 0.99.5pre1 (WinXP - still crashes) and even started building the Linux client to test, that's when I noticed the capture file seemed to partially load before crashing. I switched to tshark and was able to verify a specific packet was always causing the crash. When I investigated further, I found my capture file had traffic that included messages that were not encapsulated IP. The crash occurred when a non IP payload was feed to the IP dissector. I've added some defensive code in my Lua program to check for a valid IP header before passing the tvb off to the IP dissector. Everything works great now. So I'm not sure there's any to do in the wireshark code base. Ideally a dissector shouldn't crash on bad data, but the only way this got there was my lua code that didn't do enough sanity checking on the payload. Here's the payload that was passed to the ip dissector that caused the crash. 0a 64 64 14 00 00 00 00 00 00 00 00 versus the expected: 45 00 ... I'm guessing the 0a - indicated 40 bytes of ip header length was causing the dissector to go off the end of the packet buffer and cause the crash. Thanks also for the tip on the sub range creation. I thought that might work, but when the program was crashing, I was a bit leery about going beyond the example code I found. Thanks again for the help. -Scott Date: Tue, 23 Jan 2007 21:42:32 +0100 From: Luis Ontanon [EMAIL PROTECTED] Subject: Re: [Wireshark-dev] Using Lua to parse TCP encapsulated IP protocol To: Developer support list for Wireshark wireshark-dev@wireshark.org Hi, * Can you test it against 0.99.5pre1? I cannot make it crash (works OK for me), could you send the capture file that does crash? Could you eventually send in also the output of wireshark -v Thanks Luis BTW sub_buf = buffer( 4, buffer:len() - 4 ):tvb() is the same as sub_buf = buffer(4):tvb() On 1/22/07, Scott Robinson [EMAIL PROTECTED] wrote: Hi, I've been using Lua to create a dissector for a protocol that has IP encapsulated inside TCP with an additional header. Everything works fine until I try to create a new tvb off from a tvbsubrange. When I do this, Wireshark crashes. The new tvb appeared correct when I added debug statements (pointing at the correct data, and length are correct). The Lua and Wireshark docs refered to the Tvb.new_subset function to create a new sub tvb for an encapsulated protocol. I couldn't get that to work and used something like buffer(4,n):tvb(). I've only been looking at the Wireshark and Lua code for a short time now, so I'm hoping I'm just coding something up wrong. Any pointers would be greatly appreciated. Here's a sample of the code that was crashing. If I comment out the line that tries to pass the new sub tvb to the ip dissector, or just pass the original buffer to the ip dissector, wireshark doesn't crash (although it doesn't decode like I need it too) Thanks. -Scott -- Define our protocol my_proto = Proto(myproto, MINE, My Protocol) -- Create a function to dissect my_proto function my_proto.dissector( buffer, pinfo, tree ) local subtree = tree:add( my_proto, buffer, My Proto Header ) subtree:add( buffer(0,1), Version: .. buffer(0,1):uint() ) subtree:add( buffer(1,1), Type: .. buffer(1,1):uint() ) subtree:add( buffer(2,2), Sequence: .. buffer(2,2):uint() ) ip_dissector = Dissector.get(ip) -- skip over the header in front of the encapsulated ip packet sub_buf = buffer( 4, buffer:len() - 4 ):tvb() ip_dissector:call( sub_buf, pinfo, tree ) end -- load the tcp port table tcp_table = DissectorTable.get(tcp.port) -- register our protocol tcp_table:add(7000, my_proto) ___ 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] Using Lua to parse TCP encapsulated IP protocol
No luck, I cannot get it to crash by using that data by itself. could you send me in a capture file with the one packet that caused the crash so I can study that crash? Thanks, Luis On 1/29/07, Luis Ontanon [EMAIL PROTECTED] wrote: Well the Lua API should intercept those conditions that would cause a crash and notify an error to the user, a crash is a bug regardless of how you get to it. I'll take a look at that data to see if that triggersa creash if calling the IP dissector directly. Luis 1/29/07, Scott Robinson [EMAIL PROTECTED] wrote: Hi Luis, I tried 0.99.5pre1 (WinXP - still crashes) and even started building the Linux client to test, that's when I noticed the capture file seemed to partially load before crashing. I switched to tshark and was able to verify a specific packet was always causing the crash. When I investigated further, I found my capture file had traffic that included messages that were not encapsulated IP. The crash occurred when a non IP payload was feed to the IP dissector. I've added some defensive code in my Lua program to check for a valid IP header before passing the tvb off to the IP dissector. Everything works great now. So I'm not sure there's any to do in the wireshark code base. Ideally a dissector shouldn't crash on bad data, but the only way this got there was my lua code that didn't do enough sanity checking on the payload. Here's the payload that was passed to the ip dissector that caused the crash. 0a 64 64 14 00 00 00 00 00 00 00 00 versus the expected: 45 00 ... I'm guessing the 0a - indicated 40 bytes of ip header length was causing the dissector to go off the end of the packet buffer and cause the crash. Thanks also for the tip on the sub range creation. I thought that might work, but when the program was crashing, I was a bit leery about going beyond the example code I found. Thanks again for the help. -Scott Date: Tue, 23 Jan 2007 21:42:32 +0100 From: Luis Ontanon [EMAIL PROTECTED] Subject: Re: [Wireshark-dev] Using Lua to parse TCP encapsulated IP protocol To: Developer support list for Wireshark wireshark-dev@wireshark.org Hi, * Can you test it against 0.99.5pre1? I cannot make it crash (works OK for me), could you send the capture file that does crash? Could you eventually send in also the output of wireshark -v Thanks Luis BTW sub_buf = buffer( 4, buffer:len() - 4 ):tvb() is the same as sub_buf = buffer(4):tvb() On 1/22/07, Scott Robinson [EMAIL PROTECTED] wrote: Hi, I've been using Lua to create a dissector for a protocol that has IP encapsulated inside TCP with an additional header. Everything works fine until I try to create a new tvb off from a tvbsubrange. When I do this, Wireshark crashes. The new tvb appeared correct when I added debug statements (pointing at the correct data, and length are correct). The Lua and Wireshark docs refered to the Tvb.new_subset function to create a new sub tvb for an encapsulated protocol. I couldn't get that to work and used something like buffer(4,n):tvb(). I've only been looking at the Wireshark and Lua code for a short time now, so I'm hoping I'm just coding something up wrong. Any pointers would be greatly appreciated. Here's a sample of the code that was crashing. If I comment out the line that tries to pass the new sub tvb to the ip dissector, or just pass the original buffer to the ip dissector, wireshark doesn't crash (although it doesn't decode like I need it too) Thanks. -Scott -- Define our protocol my_proto = Proto(myproto, MINE, My Protocol) -- Create a function to dissect my_proto function my_proto.dissector( buffer, pinfo, tree ) local subtree = tree:add( my_proto, buffer, My Proto Header ) subtree:add( buffer(0,1), Version: .. buffer(0,1):uint() ) subtree:add( buffer(1,1), Type: .. buffer(1,1):uint() ) subtree:add( buffer(2,2), Sequence: .. buffer(2,2):uint() ) ip_dissector = Dissector.get(ip) -- skip over the header in front of the encapsulated ip packet sub_buf = buffer( 4, buffer:len() - 4 ):tvb() ip_dissector:call( sub_buf, pinfo, tree ) end -- load the tcp port table tcp_table = DissectorTable.get(tcp.port) -- register our protocol tcp_table:add(7000, my_proto) ___ 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 -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan
[Wireshark-dev] wslua refereance manual
It's been few days that I got wslua's reference manual into the docbook directory, it's built OK (at least it loos so from here). What's to be done to add it to the distribution? -- 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] User Accessible Tables, please review
from uat.h * uat mantains a dynamically allocated table accessible to the user * via a file and/or gui tables. * * the file is located either in userdir(when first read or when writen) or * in datadir for defaults (read only , it will be always written to userdir). * * the behaviour of the table is controlled by a series of callbacks * the caller must provide. the design goal is to have a flexible enough interface to manage tables of data needed by various dissectors/features. * mantains a dynamically allocated table that is loaded from file * records are user-definable (struct _xxx) * allows arbitrary characters in strings ( even \0's ) * it can dump the contents to a file * records can be edited by the user either by editing the file or by a gui window (upcoming). Please, take a look at uat.h and tell me what should be changed. Thanks, Luis On 1/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20586 -- 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] User Accessible Tables, please review
On 1/28/07, Ulf Lamping [EMAIL PROTECTED] wrote: [snip] Well, first of all, what problem do you try to solve here? the lack of an uniform way to deal with tables, they are dealt differently when they could be dealt in a single uniform way. I have four diferent examples I wrote myself: four user encap protocols, the k12 config file, the snmpv3 users file and lastly the df_macros table but there's more candidates in there, not written by me: ssl uses a single splitted line of text for the various decryption keys, it works but a table will do better. ipsec has 4 (always 4 and only 4) replicate preference sets for associations. and if I dive in the code I bet I'll find many more. What I want is a single uniform way (although not a very straightforward one I admit) to deal with tables of settings accessible to the user. -- 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] dissector registration
does the foo protocol registers a protocol table (foo.port) in its registration function? (see packet.h:258) On 1/28/07, Vladimir Zherdenovsky [EMAIL PROTECTED] wrote: Hi, I want to write a dissector to a foo protocol inside UDP that includes another goo protocol inside. How can I register the low level (goo) dissector? Example proto_reg_handoff_foo: dissector_add(udp.port, foo_udp_port, foo_handle); Example proto_reg_handoff_goo: the second dissector should work when foo.port = 200. dissector_add(foo.port, 200, goo_handle); But low level dissector doesn't work. Thanks, Vladimir ___ 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] [PATCH] Support ALCAP, NBAP over SSCOP in K12xx
Few thoughts on this see inline On 1/28/07, Martin Mathieson [EMAIL PROTECTED] wrote: On 1/27/07, Kriang Lerdsuwanakij [EMAIL PROTECTED] wrote: With above 3 changes together, dissecting Iub traces are correct for control and signaling planes. I am still investigating user plane frames because writing UMTS RLC/MAC protocol dissector is required. . Hi Kriang, This is very interesting to me. I wrote the FP dissector to work with Catapult DCT2000 log files, which for me are often user-plane only tests without NBAP or ALCAP traffic. The dissector relies upon per-frame information being available (see struct _fp_info from packet-umts_fp.h). For DCT2000, this information is stored separately for each frame, and attached to the packet before the FP dissector will be called. If the same information is not available with K12xx, it could also be made to alternatively look up some global tables or conversation data created by the NBAP or ALCAP dissectors. ALCAP would be the right one (afaik neither nbap nor ranap should bear that information), but the problem here is that there's no relation between the path-id and its vp/vc pair, in order to correlate the aal2cpss with the alcap call there has to be a user provided table that maps alcap's path-id to the vp/vc used for the path itself. I tried to make the info in the struct as general as possible - I plan to replace 'dct2000_variant' with a sub-version number (e.g. 7 for release 6.7.0), and also to add an 'interface' field to specify IuB or IuR. I have not considered trying to dissect the MAC and RLC headers within the FP TBs. This would be hard because you would need to know all of their configuration details and effectively to simulate those layers and the primitives exchanged between them. For me, just having Wireshark's filtering and graphing available for the FP layer has already been *very* useful. Good luck, Martin -- 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] [PATCH] Read K12xx .rf file with extra_len == 0
Committed revision 20579. On 1/27/07, Kriang Lerdsuwanakij [EMAIL PROTECTED] wrote: Hello I found out the reason Wireshark refuses to read some .rf file I have. Those files have zero extra_len in SRCDEST header structure. See the attached file for example. It was created by selecting some frames from a larger .rf5 file (within Tektronix's own reader) and save as a separate file. The patch that fixes this issue is also included in the attachment. Best regards Kriang Lerdsuwanakij ___ 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] [PATCH] Support ALCAP, NBAP over SSCOP in K12xx
Committed revision 20580. On 1/27/07, Kriang Lerdsuwanakij [EMAIL PROTECTED] wrote: Hello This patch add some capability for reading K12xx .rf5 files. Currently Wireshark has trouble dissecting .rf5 captured from UMTS ATM-based Iub interface. According to example configuration file at: http://wiki.wireshark.org/K12?highlight=%28K12%29 If one try to dissect protocol C:\k1297\stacks\umts_iub\umts_iub_aal2l3.stk using ALCAP, it will have error due to the trailing SSCOP fields. If SSCOP is used instead, then the ALCAP commands is not shown. This patch implements the following: 1 Add ALCAP and NBAP as subdissectors of SSCOP. Previously it only knows about SSCF-NNI and data. (Changes in packet-sscop.c, packet-sscop.h) 2 Add capability for lower layer to force SSCOP to choose a particular dissector. It is passed as subdissector field of SSCOP protocol data. This is required because different payload protocol is distinguished by different VPI/VCI. There is no protocol field inside SSCOP frame. (Changes in packet-sscop.c, packet-sscop.h) 3 Make K12xx configuration file supporting the following syntax: C:\k1297\stacks\umts_iub\umts_iub_aal2l3.stk sscop:alcap This says dissect with SSCOP first and then pass to ALCAP. The change is made general, so it supports arbitrary number of protocol, like proto1:proto2:proto3. Using : as separator allow us to expand the syntax further to support parameters like proto1 param1:proto2 param2 param3. (Changes in packet-k12.c) With above 3 changes together, dissecting Iub traces are correct for control and signaling planes. I am still investigating user plane frames because writing UMTS RLC/MAC protocol dissector is required. The patch and sample .rf file (same as my previous patch) is in the attachment. I will go to expand the wiki about this usage when the patch is committed. I have already added some more information about ALCAP, NBAP protocols in the wiki. Best regards Kriang Lerdsuwanakij ___ 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] Need help about subprotocol
On 1/27/07, Bingyao Du [EMAIL PROTECTED] wrote: Hi Amit My problem is there are too many fields in only one protocol. So, I want to split the packet into two independent dissectors. I attached it:) Trust me they are not that many... take a look at packet-alcap.c (just one example and see it yourself) Steve, I do it as you said. But the problem is there are too many fields. I think it's better split it into two protocols. Attached the C file. The problem troubles me for many days. Wow... Best regards -Bingyao 2007/1/27, Stephen Fisher [EMAIL PROTECTED]: On Sat, Jan 27, 2007 at 01:06:19AM +0800, Bingyao Du wrote: The protocol I'm dissecting has a header portion, that contains a type field, and then a payload with different format for each type. The Header protion contains several fields. I thinks it's better to display the packet with two dissectors, just looks like IP dissector and TCP dissector. What should I do? Or could you send me an example or demo? Thanks very much. The best/easiest way to do it is within the same dissector. A dissector you can use as an example is packet-wlccp.c. The only difference is that the version (akin to your type) field is at the beginning of the packet, but that doesn't make a difference in how it's implemented. Line 205 gets the version (type in your case) and line 208 checks if the type is 0x0 and displays fields based on that version. Line 231 checks if the version is instead 0xC1 and displays fields based on that version. Steve ___ 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] Warning about radius directory
The radius dictionary gets loaded way before preferences are
evaluated. Giving no warning and then having the packets undecoded
isn't elegant.
Your patch suppresses the error altoghether which is not a nice solution.
What you can do is just add a dummy radius dir and a dummy dictionary:
$ cd $WIRESHARK_DATA
$ mkdir radius
$ touch radius/dictionary
3 commands and the Warning is gone.
On 1/27/07, Andrej Mikus [EMAIL PROTECTED] wrote:
Team,
I notice that wireshark emits unconditionally warning mentioning that it
Could not find the radius directory.
I do not think that radius dictionary is needed for operation in all
environments, is is possible to move this output to some kind of
diagnostics mode?
Based on my search, it appears there for some time:
http://www.wireshark.org/lists/wireshark-bugs/200610/msg00501.html
I applied following patch:
Index: epan/dissectors/packet-radius.c
===
--- epan/dissectors/packet-radius.c (revision 20564)
+++ epan/dissectors/packet-radius.c (working copy)
@@ -1469,7 +1469,6 @@
dict = radius_load_dictionary(dir,dictionary,dict_err_str);
} else {
dict = NULL;
- dict_err_str = g_strdup(Could not find the radius
directory);
}
g_free(dir);
Thanks
Andrej
___
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] Warning about radius directory
On 1/27/07, Andrej Mikus [EMAIL PROTECTED] wrote:
Thanks for comments.
Of course, I removed the message to stop coming out after I realized
that it is coming before preferences.
Creating file in my system does not address this problem for others.
Yep but Others usually install either with make install or from a
package that has the dictionary.
If you are tailoring a custom ws and do not need radius why do you
compile it to begin with you may save much more space removing 550
protocols that you don't need than removing the radius dictionary.
Elegant solution would be perhaps to postpone reading the directory until
it is really needed.
the hfarray is generated from the radius dictionary, it needs to be
registered at protocol registartion, at most at protocol handoff,
that's when its needed.
To filter on radius.UserName may be unelegant. Why a network
administrator would ever need that?
Alternatively, put the error message to tree output of relevant packets.
This way the user would realize very fast why his packets are not
decoded, while others do not see irrelevant warning.
That could be an Idea...
I am still wondering whether radius is the only dissector that uses
external file. If not, how do the others handle this kind of issue?
XML uses DTDs in the dtds directory but if it does not find any dtds
it does not register any extra protocols. For XML each DTD registers a
different protocol, the catch-all XML protocol gets registered anyway
but does not allow you to filter on a.b == bbb when there's
a\ba
Diameter does what you said before it tries to load the diictionary at
the first diameter packet, but diameter does not allow YET to filter
on contents of AVPS (i.e diameter.UserName does not exist, that's
sad).
AFAIK I'm the only one that has written such user configurable
dissectors so far...
I also failed to understand why tshark does not give this warning message.
maybe g_warning is handled differently (?)
Regards
Andrej
On Sat, 27.Jan.07 01:55:35 +0100, Luis Ontanon wrote:
The radius dictionary gets loaded way before preferences are
evaluated. Giving no warning and then having the packets undecoded
isn't elegant.
Your patch suppresses the error altoghether which is not a nice solution.
What you can do is just add a dummy radius dir and a dummy dictionary:
$ cd $WIRESHARK_DATA
$ mkdir radius
$ touch radius/dictionary
3 commands and the Warning is gone.
On 1/27/07, Andrej Mikus [EMAIL PROTECTED] wrote:
Team,
I notice that wireshark emits unconditionally warning mentioning that it
Could not find the radius directory.
I do not think that radius dictionary is needed for operation in all
environments, is is possible to move this output to some kind of
diagnostics mode?
Based on my search, it appears there for some time:
http://www.wireshark.org/lists/wireshark-bugs/200610/msg00501.html
I applied following patch:
Index: epan/dissectors/packet-radius.c
===
--- epan/dissectors/packet-radius.c (revision 20564)
+++ epan/dissectors/packet-radius.c (working copy)
@@ -1469,7 +1469,6 @@
dict =
radius_load_dictionary(dir,dictionary,dict_err_str);
} else {
dict = NULL;
- dict_err_str = g_strdup(Could not find the radius
directory);
}
g_free(dir);
Thanks
Andrej
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
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] Using Lua to parse TCP encapsulated IP protocol
Hi, * Can you test it against 0.99.5pre1? I cannot make it crash (works OK for me), could you send the capture file that does crash? Could you eventually send in also the output of wireshark -v Thanks Luis BTW sub_buf = buffer( 4, buffer:len() - 4 ):tvb() is the same as sub_buf = buffer(4):tvb() On 1/22/07, Scott Robinson [EMAIL PROTECTED] wrote: Hi, I've been using Lua to create a dissector for a protocol that has IP encapsulated inside TCP with an additional header. Everything works fine until I try to create a new tvb off from a tvbsubrange. When I do this, Wireshark crashes. The new tvb appeared correct when I added debug statements (pointing at the correct data, and length are correct). The Lua and Wireshark docs refered to the Tvb.new_subset function to create a new sub tvb for an encapsulated protocol. I couldn't get that to work and used something like buffer(4,n):tvb(). I've only been looking at the Wireshark and Lua code for a short time now, so I'm hoping I'm just coding something up wrong. Any pointers would be greatly appreciated. Here's a sample of the code that was crashing. If I comment out the line that tries to pass the new sub tvb to the ip dissector, or just pass the original buffer to the ip dissector, wireshark doesn't crash (although it doesn't decode like I need it too) Thanks. -Scott -- Define our protocol my_proto = Proto(myproto, MINE, My Protocol) -- Create a function to dissect my_proto function my_proto.dissector( buffer, pinfo, tree ) local subtree = tree:add( my_proto, buffer, My Proto Header ) subtree:add( buffer(0,1), Version: .. buffer(0,1):uint() ) subtree:add( buffer(1,1), Type: .. buffer(1,1):uint() ) subtree:add( buffer(2,2), Sequence: .. buffer(2,2):uint() ) ip_dissector = Dissector.get(ip) -- skip over the header in front of the encapsulated ip packet sub_buf = buffer( 4, buffer:len() - 4 ):tvb() ip_dissector:call( sub_buf, pinfo, tree ) end -- load the tcp port table tcp_table = DissectorTable.get(tcp.port) -- register our protocol tcp_table:add(7000, my_proto) ___ 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] [Wireshark-commits] rev 20514: /trunk/epan/wslua/ /trunk/epan/wslua/: wslua_gui.c
this should go into 0.99.5 On 1/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20514 User: lego Date: 2007/01/21 05:05 PM Log: fix bug 1320 Directory: /trunk/epan/wslua/ ChangesPath Action +1 -1 wslua_gui.cModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- 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] [Wireshark-commits] rev 20515: /trunk/epan/wslua/ /trunk/epan/wslua/: template-init.lua
Gerald, this should go in 0.99.5 On 1/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20515 User: lego Date: 2007/01/21 05:06 PM Log: fix bug 1321 Directory: /trunk/epan/wslua/ ChangesPath Action +3 -1 template-init.luaModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- 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] alias problem
However to assign many addresses I used to assing entire classes of addresses to a loopback interface (usually lo1) and have routed (rip) announcing routes to them through the wired interfaces that had just one address, If your OS supports it (at least BSDs do) that's cleaner. Luis On 1/18/07, Jaap Keuter [EMAIL PROTECTED] wrote: Hi, Your correct, see http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1151 Thanx, Jaap On Thu, 18 Jan 2007, Miha Jemec wrote: Hi! If I have more alias IP addresses on one ethernet interface, the wireshark application gets into problem. I have latest official wireshark version 0.99.4 running on a high end server (Intel Core2 Duo with 12 GB of memory). I have 1016 alias addresses configured on one interface. When I press Capture-Start button it takes 55s to open next window and additional 20s to start capturing. And the Capture Dialog window doesn't display the IP addresses correctly. The window gets very wide and the addresses are overlapped (look the attachment). I think even if 1000+ alias IP addresses are not the most common configuration, this is still a bug? Regards, Miha ___ 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] Where is dfilter_macro_expand.l
in the past... I re-wrote the function in C instead of using the lex scanner, What I realy forgot was to remove it from Makefile.nmake. Sorry Luis On 1/18/07, Jaap Keuter [EMAIL PROTECTED] wrote: Hi, Where is dfilter_macro_expand.l The Win32 buildbot needs it. cd .. cd dfilter NMAKE / -f Makefile.nmake Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'dfilter_macro_expand.l' Stop. NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~2\VC98\BIN\NMAKE.EXE' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~2\VC98\BIN\NMAKE.EXE' : return code '0x2' Stop. program finished with exit code 2 Thanx, Jaap ___ 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] Win32: The best way to solve dependencies for user-guide.chm / HHC_DIR?
However for unix the real issue is to have the html files been built. I thought about parameterized Makefile.am and a catalog.xml.in that overwrite both files from the repo (used by cygwin) if --with-fop=xxx --with-docbook=yyy options are passed to ./configure. What the --with-fop option should look for is fop, xlstproc and xmllint, the other one locates the dtds. On 1/18/07, Ulf Lamping [EMAIL PROTECTED] wrote: Nope, you may imagine distribute .html files with a release but not putting them in the svn sources. Would it be a real problem? The problem is to generate the .html files, as this can be a bit tricky ;-) Add an option to the configure (--enable-chm?) which enables the compilation of .chm files. This option will be disabled by default. If you do not enable this option, you'll get an html version of the help (with its cons). If you really want .chm files, then you'll have to install all the dependencies. Of course in the release you'll have the .chm files. Missunderstanding. KDE and/or GNOME uses similar (namely HTML based) mechanisms to show help. But they don't use .chm files - the .chm file format is Win32 only AFAIK - so having .chm files is pretty useless on UNIX. In fact I don't know the details what KDE/GNOME would need to show help in their native help mechanisms. I'll leave it as an excercise for the interested reader ;-) Regards, ULFL _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 ___ 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] [Wireshark-commits] rev 20491: /trunk/docbook/ /trunk/docbook/: Makefile
maybe not, but the following perl command line does the work.
# this nativizes eols
${PERL} -ae 'chomp; print $_\n;'
# this DOSifies eols
${PERL} -ae 'chomp; print $_\012\015;'
# this Unixizes eols
${PERL} -ae 'chomp; print $_\015;'
# this OldMacIzes eols
${PERL} -ae 'chomp; print $_\012;'
On 1/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20491
User: ulfl
Date: 2007/01/18 11:57 PM
Log:
the docbook generation also suffers from the cygwin bash CR/LF problem :-(
I've added a call to dos2unix to convert check_svn_version.sh that way
Is it safe to assume that dos2unix is available on a common UNIX developer
machine?!?
Directory: /trunk/docbook/
ChangesPath Action
+1 -0 Makefile Modified
___
Wireshark-commits mailing list
Wireshark-commits@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-commits
--
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] [Wireshark-commits] rev 20491: /trunk/docbook/ /trunk/docbook/: Makefile
oops that would be
$(PERL) -ae 'chomp; print $_\015;' infile outfile
On 1/19/07, Luis Ontanon [EMAIL PROTECTED] wrote:
maybe not, but the following perl command line does the work.
# this nativizes eols
${PERL} -ae 'chomp; print $_\n;'
# this DOSifies eols
${PERL} -ae 'chomp; print $_\012\015;'
# this Unixizes eols
${PERL} -ae 'chomp; print $_\015;'
# this OldMacIzes eols
${PERL} -ae 'chomp; print $_\012;'
On 1/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20491
User: ulfl
Date: 2007/01/18 11:57 PM
Log:
the docbook generation also suffers from the cygwin bash CR/LF problem :-(
I've added a call to dos2unix to convert check_svn_version.sh that way
Is it safe to assume that dos2unix is available on a common UNIX developer
machine?!?
Directory: /trunk/docbook/
ChangesPath Action
+1 -0 Makefile Modified
___
Wireshark-commits mailing list
Wireshark-commits@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-commits
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
--
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] [Wireshark-commits] rev 20467: /trunk/ /trunk/epan/dfilter/: Makefile.am Makefile.nmake dfilter-macro.c dfilter-macro.h dfilter.c dfilter_macro_load.l /trunk/gtk/: macros_dlg.c mac
FYC
I added macros to the display filter engine.
At startup the df_macros in either userdir or (if not found) datadir
will be loaded (if there is one).
The GUI dialog is just a dummy allows you to see.
the format of the file is as follows, I believe they are self explanatory:
-- example df_macros file
Macro_N4me: ip.addr == 1.2.3.4
tcp_ses: ((ip.addr == $1 ip.addr == $2) (tcp.port == $3
tcp.port == $4))
server: 10.0.0.3
net10: 10.0.0.0/8
quoted: $1
quoted_in_quotes: \\$1\\
nested: (${Macro_N4me} ($1))
broken1: ${complete:second;
broken2: ;last}
complete: first;$1 $2 $3
--
the results are like these:
filter str: ${tcp_ses:${server\};${net10\};80;12345}
resolved: ((ip.addr == 10.0.0.3 ip.addr == 10.0.0.0/8) (tcp.port
== 80 tcp.port == 12345))
filter_str: text contains ${quoted:# #}
resolved: text contains # #
filter_str: ${nested:udp.port==161}
resolved: (ip.addr == 1.2.3.4 (udp.port==161))
filter_str: ${broken1};third${broken2}
not too resolved: ${complete:second;third;last}
--
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] [Wireshark-commits] rev 20442: /trunk/tools/lemon/ /trunk/tools/lemon/: lemon.c
They commited what we got in rev 20447. As this does not happen to me (I'm running with MallocBadFreeAbort) I would need a a backtrace where the yyminor value passed to DtdParse() shows up. can you -DDEBUG_DTD_PARSER and send in the trace for the parser. Thanks. Luis On 1/16/07, Douglas Pratley [EMAIL PROTECTED] wrote: I get a similar crash under Windows. I'm having trouble reverting back to a good baseline without losing today's work, so it would be great if this could be fixed... I'm afraid I can't work out quite what the dependencies are here. Cheers Doug -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaap Keuter Sent: 16 January 2007 12:27 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 20442: /trunk/tools/lemon/ /trunk/tools/lemon/: lemon.c Hi, Maybe not, since it seems to have broken the program completely. (gdb) run Starting program: /home/me/src/wireshark/trunk/.libs/lt-tshark Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1233094432 (LWP 25812)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1233094432 (LWP 25812)] 0xb69c75ad in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb69c75ad in free () from /lib/tls/i686/cmov/libc.so.6 #1 0xb6b3ab31 in g_free () from /usr/lib/libglib-2.0.so.0 #2 0xb6fafa13 in yy_destructor (yymajor=value optimized out, yypminor=0x0) at ./dtd_grammar.lemon:63 #3 0xb6fb0685 in DtdParse (yyp=0x8371f40, yymajor=6, yyminor=0x8376f00, bd=0x837) at ./dtd_grammar.lemon:1 #4 0xb6fb163b in Dtd_Parse_lex () at ./dtd_parse.l:275 #5 0xb6fb221c in dtd_parse (s=0x8378f20) at ./dtd_parse.l:335 #6 0xb76620f5 in proto_register_xml () at packet-xml.c:1145 #7 0xb766b3b5 in register_all_protocols () at register.c:691 #8 0xb6fcd66f in proto_init (register_all_protocols=0x804e31c [EMAIL PROTECTED], register_all_protocol_handoffs=0x804e75c [EMAIL PROTECTED]) at proto.c:320 #9 0xb6fb60d7 in epan_init (register_all_protocols=0x804e31c [EMAIL PROTECTED], register_all_handoffs=0x804e75c [EMAIL PROTECTED], report_failure=0x8060dc0 failure_message, report_open_failure=0x80610a0 open_failure_message, report_read_failure=0x8061150 read_failure_message) at epan.c:97 #10 0x08062fc1 in main (argc=1, argv=0xbf80a4d4) at tshark.c:781 Thanx, Jaap On Tue, 16 Jan 2007, Joerg Mayer wrote: On Mon, Jan 15, 2007 at 07:48:06PM +, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20442 User: lego Date: 2007/01/15 07:48 PM Log: Fix a major leakage of token minors in lemon generated parsers due to the fact that lemon was not genmerating destructor code for elements in the RHS of rules without C-code. Can you please provide feedback to the lemon author? thanks Joerg ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev 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 -- 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] [Wireshark-commits] rev 20442: /trunk/tools/lemon/ /trunk/tools/lemon/: lemon.c
in order to avoid this one you just have to rename the dtds directory, no dtds directory no dtds get parsed. On 1/16/07, Douglas Pratley [EMAIL PROTECTED] wrote: I get a similar crash under Windows. I'm having trouble reverting back to a good baseline without losing today's work, so it would be great if this could be fixed... I'm afraid I can't work out quite what the dependencies are here. Cheers Doug -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaap Keuter Sent: 16 January 2007 12:27 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 20442: /trunk/tools/lemon/ /trunk/tools/lemon/: lemon.c Hi, Maybe not, since it seems to have broken the program completely. (gdb) run Starting program: /home/me/src/wireshark/trunk/.libs/lt-tshark Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1233094432 (LWP 25812)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1233094432 (LWP 25812)] 0xb69c75ad in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb69c75ad in free () from /lib/tls/i686/cmov/libc.so.6 #1 0xb6b3ab31 in g_free () from /usr/lib/libglib-2.0.so.0 #2 0xb6fafa13 in yy_destructor (yymajor=value optimized out, yypminor=0x0) at ./dtd_grammar.lemon:63 #3 0xb6fb0685 in DtdParse (yyp=0x8371f40, yymajor=6, yyminor=0x8376f00, bd=0x837) at ./dtd_grammar.lemon:1 #4 0xb6fb163b in Dtd_Parse_lex () at ./dtd_parse.l:275 #5 0xb6fb221c in dtd_parse (s=0x8378f20) at ./dtd_parse.l:335 #6 0xb76620f5 in proto_register_xml () at packet-xml.c:1145 #7 0xb766b3b5 in register_all_protocols () at register.c:691 #8 0xb6fcd66f in proto_init (register_all_protocols=0x804e31c [EMAIL PROTECTED], register_all_protocol_handoffs=0x804e75c [EMAIL PROTECTED]) at proto.c:320 #9 0xb6fb60d7 in epan_init (register_all_protocols=0x804e31c [EMAIL PROTECTED], register_all_handoffs=0x804e75c [EMAIL PROTECTED], report_failure=0x8060dc0 failure_message, report_open_failure=0x80610a0 open_failure_message, report_read_failure=0x8061150 read_failure_message) at epan.c:97 #10 0x08062fc1 in main (argc=1, argv=0xbf80a4d4) at tshark.c:781 Thanx, Jaap On Tue, 16 Jan 2007, Joerg Mayer wrote: On Mon, Jan 15, 2007 at 07:48:06PM +, [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20442 User: lego Date: 2007/01/15 07:48 PM Log: Fix a major leakage of token minors in lemon generated parsers due to the fact that lemon was not genmerating destructor code for elements in the RHS of rules without C-code. Can you please provide feedback to the lemon author? thanks Joerg ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev 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 -- 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] [Wireshark-commits] rev 20442: /trunk/tools/lemon/ /trunk/tools/lemon/: lemon.c
Guys,
I checked in r20452 that reverses the changes they did to my original
fix (and I checked in later). This fix is not quite perfect (neither
was theirs) as it haves meany #line directives ponting at the wrong
place in the generated code, but it does have yy_destructor() to be
called just once for every unused element in RHS.
I'm curious so I'll keep investigating this issue...
Luis
On 1/16/07, Martin Mathieson [EMAIL PROTECTED] wrote:
Is this useful?
Martin
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i586-suse-linux...Using host libthread_db
library /lib/tls/libthread_db.so.1.
(gdb) run
Starting program: /users/martinm/wireshark/.libs/lt-wireshark
[Thread debugging using libthread_db enabled]
[New Thread 1103262656 (LWP 23272)]
Detaching after fork from child process 23283.
Detaching after fork from child process 23284.
*** glibc detected *** double free or corruption: 0x085761d0 ***
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1103262656 (LWP 23272)]
0x41957ec9 in free () from /lib/tls/libc.so.6
(gdb) bt
#0 0x41957ec9 in free () from /lib/tls/libc.so.6
#1 0x417b89d2 in g_free () from /opt/gnome/lib/libglib-2.0.so.0
#2 0x4037f192 in yy_destructor (yymajor=107 'k', yypminor=0x8587430)
at dtd_grammar.lemon:63
#3 0x4037f993 in DtdParse (yyp=0x85873b0, yymajor=16,
yyminor=0x6c696d6b, bd=0x6c696d6b) at dtd_grammar.lemon:216
#4 0x40380986 in Dtd_Parse_lex () at dtd_parse.l:274
#5 0x4038143c in dtd_parse (s=0x6c696d6b) at dtd_parse.l:334
#6 0x40a30056 in proto_register_xml () at packet-xml.c:1145
#7 0x40a3788e in register_all_protocols () at register.c:691
#8 0x403993ff in proto_init (register_all_protocols=0x805fe8c
register_all_protocols, register_all_protocol_handoffs=0x8060e3c
register_all_protocol_handoffs)
at proto.c:320
#9 0x40384337 in epan_init (register_all_protocols=0x6c696d6b,
register_all_handoffs=0x6c696d6b, report_failure=0x6c696d6b,
report_open_failure=0x6c696d6b,
report_read_failure=0x6c696d6b) at epan.c:97
#10 0x080826db in main (argc=1, argv=0xbfffdad4) at main.c:2367
(gdb) fr 2
#2 0x4037f192 in yy_destructor (yymajor=107 'k', yypminor=0x8587430)
at dtd_grammar.lemon:63
63 if ($$-text) g_free($$-text);
(gdb) p *yyminor
No symbol yyminor in current context.
(gdb) p *yypminor
$1 = {yy0 = 0x8583d38, yy29 = 0x8583d38, yy44 = 0x8583d38
smil8=X\b:10, yy59 = 0x8583d38, yy81 = 14568}
(gdb)
On 1/16/07, Luis Ontanon [EMAIL PROTECTED] wrote:
They commited what we got in rev 20447.
As this does not happen to me (I'm running with MallocBadFreeAbort) I
would need a a backtrace where the yyminor value passed to DtdParse()
shows up.
can you -DDEBUG_DTD_PARSER and send in the trace for the parser.
Thanks.
Luis
On 1/16/07, Douglas Pratley [EMAIL PROTECTED] wrote:
I get a similar crash under Windows. I'm having trouble reverting back
to a good baseline without losing today's work, so it would be great
if this could be fixed... I'm afraid I can't work out quite what the
dependencies are here.
Cheers
Doug
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jaap Keuter
Sent: 16 January 2007 12:27
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 20442:
/trunk/tools/lemon/ /trunk/tools/lemon/: lemon.c
Hi,
Maybe not, since it seems to have broken the program completely.
(gdb) run
Starting program: /home/me/src/wireshark/trunk/.libs/lt-tshark
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1233094432 (LWP 25812)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1233094432 (LWP 25812)]
0xb69c75ad in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb69c75ad in free () from /lib/tls/i686/cmov/libc.so.6
#1 0xb6b3ab31 in g_free () from /usr/lib/libglib-2.0.so.0
#2 0xb6fafa13 in yy_destructor (yymajor=value optimized out,
yypminor=0x0) at ./dtd_grammar.lemon:63
#3 0xb6fb0685 in DtdParse (yyp=0x8371f40, yymajor=6, yyminor=0x8376f00,
bd=0x837) at ./dtd_grammar.lemon:1
#4 0xb6fb163b in Dtd_Parse_lex () at ./dtd_parse.l:275
#5 0xb6fb221c in dtd_parse (s=0x8378f20) at ./dtd_parse.l:335
#6 0xb76620f5 in proto_register_xml () at packet-xml.c:1145
#7 0xb766b3b5 in register_all_protocols () at register.c:691
#8 0xb6fcd66f in proto_init (register_all_protocols=0x804e31c
[EMAIL PROTECTED],
register_all_protocol_handoffs=0x804e75c
[EMAIL
Re: [Wireshark-dev] [Wireshark-commits] rev 20437: /trunk/ /trunk/epan/dissectors/: packet-ethertype.c packet-frame.c /trunk/epan/: emem.c exceptions.h packet.c /trunk/: file.c
that's glib2 only, what about select()? On 1/15/07, Stephen Fisher [EMAIL PROTECTED] wrote: On Mon, Jan 15, 2007 at 05:16:15AM +, [EMAIL PROTECTED] wrote: XXX - to prevent a busy wait, I need a portable way to wait for a short time period, like Sleep() for Windows How about g_usleep() from GLib? http://developer.gnome.org/doc/API/2.0/glib/glib-Date-and-Time-Functions.html#g-usleep Steve ___ 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] 120 filters compiled by ncp2222 dissector
While hacking on the dfilter machinery I noticed that final_registration_ncp() compiles 120 displays filters. What I can't find in the code is what these are used for as no part of the code uses them. Are these realy necessary? Luis -- 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] [Wireshark-commits] rev 20445: /trunk/gtk/ /trunk/gtk/: help_dlg.c
On 1/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=20445 User: ulfl Date: 2007/01/15 10:17 PM Log: Help: - Win32 only: try to load help page from local user-guide.chm (if HHC_DIR is set in config.nmake) and if that fails: - show corresponding help page directly from www.wireshark.org in the configured web browser. The internet way will be the only way for all UNIX based versions, as they cannot read .chm files. using file:///usr/local/share/wireshark/wsug/%s could be little less painful than the internet way. Specially if the box is not wired to the wild. Directory: /trunk/gtk/ ChangesPath Action +59 -50help_dlg.cModified ___ Wireshark-commits mailing list Wireshark-commits@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-commits -- 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] [Wireshark-commits] rev 20445: /trunk/gtk/ /trunk/gtk/: help_dlg.c
On 1/16/07, Ulf Lamping [EMAIL PROTECTED] wrote: Luis Ontanon wrote: using file:///usr/local/share/wireshark/wsug/%s could be little less painful than the internet way. Specially if the box is not wired to the wild. Yes, and I would appreciate it. It would have another advantage: Lower the actual traffic to the wireshark.org server. The disadvantage is that the binary distribution packages will become slightly larger - but there's always a price to pay. a pkg that probably comes from the same server, at least is gzed. Two task to add this: 1. the distributive script(s) must copy the user's guide to the right place, e.g.: file:///usr/local/share/wireshark/wsug/ or such To put the files in the datadir is relatively easy task. The problem is to build the wsdg: * does the buildbot that makes the tarball have all the tools needed to cook the docbook files? (fop, xsltproc, xmllint, and a set of working dtds) * we need a script to generate docbook/Makefile and docbook/catalog.xml (autoconf would be THE way, but to get my hands there this close to release makes me panic) 2. the help system must be enabled to look at this local file 1.) The task to do is to get the docs at the right place for various UNIX platforms with both the source and binary distribution ways. I don't have real knowledge how to do this ... we need to (conditionally, if autoconf knows we got fop etc.) * build the wsug in the docbook dir * copy the files down to /trunk/doc/wsug * add the files EXTRA_DIST macro in trunk/Makefile.am 2.) Looking for a local file first could be easily added to gtk/help.dlg.c function help_topic_html(), e.g. based on #ifdef _WIN32 - should be straightforward to understand what to do - I can help with this if any questions arise. In my case the browser.c functions work. (even from Lua) It could even be done for only a few platforms by simply adding a check if a local file (e.g. /usr/local/share/wireshark/wsug/html_chunked/index.html or alike) is actually existing. I guess the actual place in the filesystem to look for should be based on config settings - but the UNIX guys will know that much better than me ;-) So UNIX based systems could do it much like the current Win32 method: - first check if a local file exists in /usr/local/... and use it that way - as Frankie once said: I did it my way ;-))) - if that fails as no local help exists, do the internet way (as already implemented) So if anyone could have a look at this - it would be welcome ... I'll try to make it work, after the release has been branched. Autoconf is evil! Every time I mess with it it works for me but gets broken for someone else. -- 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
