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
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] [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] [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] [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=21337&r2=21336&pathrev=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] 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--
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=rev&revision=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] 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
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=rev&revision=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] [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] "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] 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;i > > > guint8 b = tvb_get_guint8(tvb, offset+i);
> > > > val = 100*val + ((b>>4)*10 + (b&0xf));
> > > > }
> > > > 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
[Wireshark-dev] Hard to fix bugs that MUST be solved before next release.
I have localized three bugs that we MUST fix before even thinking of a release. These are: 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. 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. 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. -- 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
[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 21332: /trunk/epan/ /trunk/epan/: exceptions.h
Oops it is Bug 1342 not 1334. On 4/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=21332 > > User: lego > Date: 2007/04/03 10:06 PM > > Log: > Make sure that when a windows exception is thrown ENDTRY gets evaluated. > > fix for one of the various issues that cause bug 1334 > > Directory: /trunk/epan/ > ChangesPathAction > +17 -4 exceptions.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 ___ 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=rev&revision=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
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()
<> < 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] 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] [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=rev&revision=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] How to specify Auth password in version wireshark-setup-0.99.6-SVN-21281.exe
To enter such a password you shoud enter il like: \xf0\x3d\x63\xde\x3f\x63\x76\xea\x34\xf9\x64\x5d\xe6\xc\x7c\x55\x19\x2f\x7e\x36 I'll add that to the help. On 3/30/07, nagendra dhulgond <[EMAIL PROTECTED]> wrote: > Hi Gerald, Luis Ontanon & All > > Thanks for your reply. > Luis really I am using wireshark-setup-0.99.6-SVN-21281.exe > version from the link which you sent to me. > really I found this version very good good & user friendly easy to update > Users table for SNMPv3. But whicle using this version I found that Users > table is taking strings for Auth password & Priv password. I am having Hex > key / password so can you please tell me how to give hex passowrd for > example like:- > 0xf03d63de3f6376ea34f9645de6c7c55192f7e36d > So can you please tell me how to specify this hex key in Users table for > Auth password. > > All > > Please someone send me information how to track replies sent for this > problem by sending mail to [EMAIL PROTECTED] as I am not able to get > replies directly. > > thanks in advance > > thanks > Nagendra > > > nag b <[EMAIL PROTECTED]> wrote: > > > -- Forwarded message -- > From: nag b <[EMAIL PROTECTED]> > Date: Mar 26, 2007 7:33 PM > Subject: Dissector bug, protocol SNMP: STATUS_INTEGER_DIVIDE_BY_ZERO: > dissector tried an integer division by zero > To: wireshark-bugs@wireshark.org, wireshark-dev@wireshark.org, > wireshark-users@wireshark.org > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > > Hi All > > I am using wire-shark latest windows version 0.99.5 . > I wants to decode SNMPV3 PDU captured as *.cap file, to decrypt this PDU I > am providing USMuserTable file from Edit -> preferences -> protocol -> SNMP. > Though I am providing correct keys to decrypt SNMPV3 PDU, I am seeing error > "Dissector bug, protocol SNMP: STATUS_INTEGER_DIVIDE_BY_ZERO: dissector > tried an integer division by zero" > when I clicks on SNMPV3 PDU. > > If anyone knows how to resolve this error, Please reply to this mail. > Thanks in advance. > > Nagendra > > > > > Don't get soaked. Take a quick peek at the forecast > with theYahoo! Search weather shortcut. > > > ___ > 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] use Global Title as address in SCCP/SUA?
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] use Global Title as address in SCCP/SUA?
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
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] [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] dissecting and decoding an 8 byte field
what about FT_BYTES, FT_UINT64, FT_STRING, FT_DOUBLE? these are either 8 octets long or any size. On 3/26/07, Bill Fassler <[EMAIL PROTECTED]> wrote: > Is there recommended way to decode 8 byte fields? I see I can use FT_NONE > with a size of 8 bytes and the appropriate bytes highlight in the bytes of > the packet, but the value does not display in the decoded details? > > Bill > > > > No need to miss a message. Get email on-the-go > with Yahoo! Mail for Mobile. Get started. > > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > -- 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=rev&revision=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] 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 (PD&E 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=rev&revision=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] [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=rev&revision=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] [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=rev&revision=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 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=rev&revision=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 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=rev&revision=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 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=rev&revision=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
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=rev&revision=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] 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] 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
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
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] 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] 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] [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=21076&r2=21075&pathrev=21076&diff_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=rev&revision=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] 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
[Wireshark-dev] Need BSSMAP/RANAP over GSMMAP capture
Hi, In order to test the addition of BSSMAP, RANAP and GSMMAP to "VoIP Calls" I need captures containing BSSMAP and RANAP over GSMMAP (i.e. signalling for a GSM and or UMTS call with an Inter-MSC Handover). Thanks. -- 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?
the point is what kind of warnings can be cleaned up: to fix "pointer arguments differ in signedness" for example would be a waste of time, as they are caused by guint8* used instaed of gchar* on those systems (most) that treat char as an unsigned. But in order to follow that policy you'll have to fill the code with "(void*)" casts (which is ugly) beacuse if you simply work on a system that treats char as unsigned you can guess what would happen. BTW a more tolerant policy of no *more* warnings (than those we already have) would be implementable by something like: cp warnings last_warnings make 2>&1 >warnings diff -u warnings last_warnings | grep '^+' || warn_and_blame_last_commiter On 3/20/07, Ulf Lamping <[EMAIL PROTECTED]> wrote: > Hi List! > > In my experience having a compiler warning free code is a good way to > prevent very subtle bugs and would also be a good addition to the > programs security - and BTW more pleasant to work with ;-) > > You will often hear the following excuse on this topic: "but you cannot > write code which won't produce warnings on all those compilers out > there". While there are cases where this is true (which has to be > handled individually), it's much more often a sign of lazy / ignorant / > unskilled developers IMHO. > > Unfortunately, we're currently having a clear trend to get more and more > compiler warnings instead of less. Years ago, I've taken the work to > remove warnings of the Win32 build to about 10, today we're having > hundreds again :-( > > While I would be willing to remove code warnings for Win32, I first > thought about how to prevent new warnings to rush in - otherwise any > work on this topic would be annoying by seeing new warnings rushing in > shortly. > > In my experience, preventing yourself to add new warnings to the WS is > currently difficult because of the multi platform support. Even if you > provide code that doesn't produce any warnings on "your" working > platform, you won't simply notice any new warnings on other platforms > (unless you take a look at the buildbot logs) - and compiling on > multiple platforms all by yourself is not on option for most of the > developers IMO. In the end this is what the buildbot is for. > > > So here comes the buildbot into the scene. If we would use a compiler > option like "stop on warnings" (or "treat warnings as errors" or alike), > it would become at least much more obvious if new warnings were added - > the buildbot will get "red". This will also make the time when a warning > is noticed much nearer to the time the code was added/changed - > currently fixing a warning once added is often done much later than it > was introduced (making the fix unnecessarily difficult). > > > Simply add such a compiler option to the current code state (with it's > hundreds of current warnings) would make the buildbot "red" on all > platforms for a very long time - which is probably not a good idea. > > An incremental way to introduce this could be: > > a) cleanup the warnings for a specific submodule (e.g. wiretap) and > platform (e.g. Win32) > b) set the compiler option for this submodule only to get a "barrier" > for new warnings to rush in > c) continue with a) for next submodule :-) > > As usual, this is my "Win32 point of view". I'm pretty sure the above is > possible to do for the Win32 platform. I'm not sure if it's possible > with the automake foo for the different unix/linux platform builds ... > > > In effect, the above is to introduce the new coding policy "write > warning free code" and a way to "enforce" this. > > So what's the opinion about this way to improve the Wireshark code base? > Are we willing to produce only warning free code and fixing warnings > that appear on the buildbot? > While I would take a look on the Win32 warnings, are the unix/linux > developers willing to spend some time to remove warnings that don't > appear on Win32 (or would this be a "Win32 only" show)? > > 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] TFO codec list problem
Can you send me a capture file with at least one packet containing the TFO codec list so I can implement it. Luis On 3/19/07, melike pinar ata <[EMAIL PROTECTED]> wrote: > Thank you for your help and your attention. I've installed the latest build > (wireshark-setup-0.99.6-SVN-21064.exe), some parameters still cannot to be > decoded (codecList). > > Regards, > ... > > streamMode: sendRecv (2) > > propertyParms: 3 items > > Item > > propertyName: 00310001 3G TFO Control (0031) > > Package: 3G TFO Control (0x0031) > > Parameter: enable (1) > > value: 1 item > > TFO Activity Control: On (1) > > Item > > propertyName: 00310002 3G TFO Control (0031) > > Package: 3G TFO Control (0x0031) > > Parameter: codeclist (2) > > value: 1 item > > TFO Codec List: > > ... > > _ > En etkili ve güvenilir PC Korumayi tercih edin, rahat edin! > http://www.msn.com.tr/security/ > > > ___ > 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] 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
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] 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] problem
There have being a lot of changes and bug fixes to h248 since 0.99.5 was released. can you try the latest development version for your plattform from http://www.wireshark.org/download/automated/ and see if it has solved your issues? If it doesn't fix it you should file a bug explaining what's not working at http://bugs.wireshark.org and, please, be more exhaustive in your explanation of what's wrong. Luis On 3/14/07, melike pinar ata <[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??They > are not working for media gateway controllers. > > _ > En etkili ve güvenilir PC Korumayi tercih edin, rahat edin! > http://www.msn.com.tr/security/ > > > ___ > 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] 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] 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] [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 s
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=rev&revision=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://an
Re: [Wireshark-dev] [PATCH] New menu items to copy packet data
I backed up the changes I made. And now it looks fine at least to me. BTW I'd love if someone with some knowledge of the way menus work could explain to me why I got that broken... and why adding the "Tools" menu did not. Luis On 2/20/07, Luis Ontanon <[EMAIL PROTECTED]> wrote: > 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 > -- 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
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=rev&revision=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
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=rev&revision=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
fixing automake scripts that takes a long long time... what you can try is renaming 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] 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] [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
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] Building RPM with Lua support
It did not found lua, so it was built without it. you should: - locate lua.h assuming it is in /usr/local/include you should then: $ ./configure --with-lua=/usr/local --whith-this --with-that check in the report at the end of configure whether lua was included or not. please report success or failure. If it fails you should send back the output of: $ find / -name 'lua.h' -or -name 'liblua.a' + the config.log (gzipped please) so I can find out what's wrong with the configure script. Thanks, Luis On 2/16/07, Douglas Pratley <[EMAIL PROTECTED]> wrote: > > > > Hi guys > > I'm having trouble building a Wireshark RPM with Lua support. > > I really a Windows (ugh) guy, so I may be missing something obvious. > > I set up a build environment on Fedora Core 6, installed the libraries for > Lua and for ADNS and then said: > > [my_ws_dir]$ ./autogen.sh > [my_ws_dir]$ ./configure --with-lua --with-adns > [my_ws_dir]$ make all > > And Wireshark waas built and supported both ADNS and Lua when running with > ./wireshark > > > So (after some digging around) I said: > > [my_ws_dir]$ ./make rpm-package > > And a _lot_ later, there was an RPM. > > I took the RPM and tried to install it on a different box, and got told it > needed ADNS. This was good, so I installed ADNS, and then it installed, and > ran > > - and utterly ignored Lua script > I installed Lua.i386, and it still ignored it. > > Anyone know what I might have done wrong? It's baffling me, and as the RPM > package build does a huge copy and clean build every time tweaking it has > eaten my day... > > Cheers > > Doug > > > 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] Saving settings as "Profiles"
On 2/15/07, Ulf Lamping <[EMAIL PROTECTED]> wrote: > Luis Ontanon wrote: > > Overall it looks like a feasable project not something *very* complex > > to implement. > > > You might miss the most work intensive point here: how to compare / > merge two different sets in a GUI way? I do not see why there's a need to compare/merge them... I'm thinking in something like HP's high-end printers print format dialogs, there you can save a certain group of settings, and if you modify some settings you might want to save the settings (all of them) with another name. So, for example, I have a "2x2" saved setting that prints two pages per side on both sides, I might want to modify that to zoom by 110% and save it again as "2x2-110". There there's no need whatsoever to compare two sets of settings. > > Luis > > > > PS. Don't count on me for implementing it I'm already over-threaded as > > it is right now. > > > Yes, you might finish some projects (including documentation) still > being marked experimental before starting new topics ;-) Ack, I being writing too much C and too little english (and Lua). BTW, you are aware just of what's already checked in... I got plenty of unfinished projects I've never checked in (abnf2eth, diameter dictionary parser with filterable fields, Lua's "Cursor" parser-generator (based on tvbparse), and other "semi-useless" experiments that probably will never see the light). Plus the one I'm on as for now that I *have* to fiinish (because I need them for work)... 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] Saving settings as "Profiles"
Well I thought of something similar to this solution as well for some
time. And yes it is somewhat complex but not *so much*.
Having variuos directories like today's user_dir (from now on a
prefset) in a meta-user_dir (from now on the prefsets_dir) and being
able to switch between them, by loading the prefset from these dirs at
any given time.
the functions to be implemented would be few:
- Duplicate the current prefset (easy),
- Save to disk the current prefset (easier),
- Load a prefset (switching... this is the complex one)
as per the use of this the interfaces would be two:
a -option prefset_name for the command line (ws and ts),
and a drop down menu in the top of the preferences dialog with a
"save as..." item and a listing the existing prefsets.
other than the prefsets in the prefset_dir there would be a file
containing a pointer to the "default" prefset.
Implementing the switching operation would be the most complex part of
this, most probably there are many caveats. But there's a simpler
solution for this
save the current state (file open, marked packets, cureently
selected packet, ...) to file.
fork(), exec() with the new prefset loading the saved state and exit()
Overall it looks like a feasable project not something *very* complex
to implement.
Luis
PS. Don't count on me for implementing it I'm already over-threaded as
it is right now.
On 2/15/07, Ulf Lamping <[EMAIL PROTECTED]> wrote:
> Joerg Mayer wrote:
> > On Thu, Feb 15, 2007 at 09:56:56AM -0800, Guy Harris wrote:
> >
> >> Douglas Pratley wrote:
> >>
> >>
> >>> Following on from recent comments about being able to save "user
> >>> decodes", has anyone been working on being able to save Wireshark
> >>> settings under different "profiles"? There's some discussion of this on
> >>> the Wiki, and it would obviously be a very useful feature if user
> >>> decodes are persisted. Or is there a feeling that this question is best
> >>> left until there is the next generation PCAP file format to play with,
> >>> as settings could be embedded in that?
> >>>
> >> Given that Wireshark can read files other than libpcap files, and will
> >> continue to be able to read them, and that this is probably considered a
> >> significant feature (as it means you can use Wireshark even on media on
> >> which it can't capture), whilst it might be useful to allow various
> >> Wireshark settings to be put into pcap-NG files, it wouldn't be
> >> *sufficient* to allow that.
> >>
> >> One feature that might be useful would be support for a "Wireshark
> >> settings file" that could be associated with a capture, so that if a
> >> file named foo.{pcap,cap,...} were opened, Wireshark could look for
> >> foo.wssettings, or something such as that, and, if it finds, load it.
> >>
> >
> > Hmm, maybe just adding some files to the config directory and taring
> > them would be an option (and of course accessing them from the tar file
> > instead of the normal file later on).
> >
> Sorry, that all sounds like a *very* complicated way ...
>
> I would like to hear more about the specific problem (what settings are
> actually affected and why) before thinking about a solution.
> Implementing a solution without really understanding the underlying
> problem is just a bad way to solve things ...
>
> Regards, ULFL
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] 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
Re: [Wireshark-dev] SCTP retransmissions an RTT
I have a further question: Can the PMTU of the smallest path of an association shrink between the transmission of a bundled packet and its retransmission forcing the sender to retransmit the various chunks of a message in more messages? i.e. : Can I just track the highest TSN in a packet and look for its ack, or should I track every data chunk of each packet separatelly? Thanks Again, Luis On 2/13/07, Michael Tuexen <[EMAIL PROTECTED]> wrote: > Hi Luis, > > see my comments in-line. > > Best regards > Michael > > On Feb 13, 2007, at 2:14 PM, Luis Ontanon wrote: > > > I need to implement the identification of retransmitted packets and > > calculation of RTT to the sctp dissector. > > > > - Is someone already working on this? > I recently committed code for SCTP reassembly. Please have a look at it. > It should be easy to add retransmission detection to it. Just look for > the TSN of the DATA chunks. The (half associations) are detected by > the port numbers and the V-tag. > > - other than RFC 2960 (sec. 6.3) what other rfcs I must read in order > > to implement these? > Should be OK. > > - are there any caveats I must be aware before starting this venture? > For RTT detection you have to "connect" both directions of the > association. > Since you can not really use the source/destination address you have to > use a heuristic to combine both half directions. > > Please let me know if you have further questions. > > > > 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 > > ___ > 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] gtk/Makefile.am patch
Committed revision 20796. On 2/12/07, Albert Chin <[EMAIL PROTECTED]> wrote: > Building 0.99.5 on RHEL 4/amd64 with a gnutls outside of /usr/lib, the > build fails with: > ../epan/dissectors/packet-ssl-utils.h:38:25: gnutls/x509.h: No such file or > directory > ../epan/dissectors/packet-ssl-utils.h:39:28: gnutls/openssl.h: No such file > or directory > ssl-dlg.c: In function `ssl_queue_packet_data': > ssl-dlg.c:154: warning: cast from pointer to integer of different size > ssl-dlg.c: At top level: > ../epan/dissectors/packet-ssl-utils.h:74: warning: > 'ssl_version_short_names' defined but not used > gmake[2]: *** [ssl-dlg.o] Error 1 > gmake[2]: Leaving directory `/opt/build/wireshark-0.99.5/gtk' > > Patch attached. > > -- > albert chin ([EMAIL PROTECTED]) > > ___ > 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] 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] [PATCH] Add FP support fo K12xx
Committed revision 20749. On 2/8/07, Kriang Lerdsuwanakij <[EMAIL PROTECTED]> wrote: > Hello > > In the attached patch, the K12 wiretap now saves the content of record > after > captured packet data. The K12 dissector then could extract them and provide > useful information to properly dissect FP frames (user plane of UTRAN Iub > interface). > > This patch only touches K12's part. There are a few parameters > for FP that the patch still does not provide together with my idea for > future > work: > - The UMTS release number - This will go into a preference setting. FP > dissector > should use a default release from preference when it is not given in > packet info. > - DCH CRC flag - By tweaking .rf5 file and feed to K12 reader, I found > that it > relies on how many bytes remain after the transport block. If there > are enough > bytes, it always treat the last 2 bytes as CRC. > - PCH paging indicators - This part I haven't figure out yet. A > preference setting > seems to be a good choice there. > > These will be addressed in future patch that modifies the FP dissector. > > Comments are welcome. > > --Kriang > > > > ___ > 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] epan_strcasestr() to epan/strutil.c
Committed revision 20734. On 2/7/07, Gisle Vanem <[EMAIL PROTECTED]> wrote: > The file epan/dissectors/packet-k12.c uses the function > strcasestr() which is not available on e.g. Windows. So I cooked > up a patch to epan/strutil.c to add epan_strcasestr() (is there a more > suited place for such a function?) > > Attached in diffs-3.txt > > --gv > > ___ > 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] 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] 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] 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:
>
> [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] 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] [PATCH] Read VPI/VCI/CID information from K12xx .rf5 with extra_len == 0
Committed revision 20705 On 2/1/07, Kriang Lerdsuwanakij <[EMAIL PROTECTED]> wrote: > Hello > > I discovered that Wireshark K12xx detects the type of input (E1 timeslot > or ATM) > based on the extra information. My previous patch to enable Wireshark to > open > K12xx files with no extra information (extra_len equals 0 in SRCDEST > record) > failed to give later dissectors the input type. > > Attached is the patch to correct this for ATM PVC. It adds VPI/VCI/CID > information > for display in the dissected tree (in k12_open function). k12_read and > k12_seek_read > are also made more robust. These are reverse engineered based on hexeditor > and constants found in tektronix configuration file. Please apply the patch. > > 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] bootstrapping SVN checkout
svn co ... && have you called ./autogen.sh before configure? sh ./autogen.sh On 1/30/07, Andreas Fink <[EMAIL PROTECTED]> wrote: > Hello, > > I've just done a SVN checkout of the sources into a new directory. > I have troubles to "bootstrap" this version as there is no "configure" file. > So I run automake (version 1.6.3 is installed) and I get: > > andreas10:~/development/ws/wireshark afink$ automake > configure.in:17: no proper implementation of AM_INIT_AUTOMAKE was found, > configure.in:17: probably because aclocal.m4 is missing... > configure.in:17: You should run aclocal to create this file, then > configure.in:17: run automake again. > configure.in: required file `./mkinstalldirs' not found > configure.in: required file `./missing' not found > configure.in:1348: required file `./config.h.in' not found > Makefile.am: required file `./depcomp' not found > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/depend2.am: AMDEP does not appear in > AM_CONDITIONAL > /usr/share/automake-1.6/am/lang-compile.am: AMDEP does not appear in > AM_CONDITIONAL > configure.in:1335: required file `./ltmain.sh' not found > ... > > and so forth > anyone have a hint to get started on the SVN? > > > > > > Andreas Fink > > Fink Consulting GmbH > Global Networks Schweiz AG > BebbiCell AG > > --- > Tel: +41-61-330 Fax: +41-61-331 Mobile: +41-79-2457333 > Address: Clarastrasse 3, 4058 Basel, Switzerland > E-Mail: [EMAIL PROTECTED] > www.finkconsulting.com www.global-networks.ch www.bebbicell.ch > --- > ICQ: 8239353 MSN: [EMAIL PROTECTED] AIM: smsrelay Skype: andreasfink > Yahoo: finkconsulting SMS: +41792457333 > > > > > > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > -- 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] 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
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" > > > > > > > > > > > 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 = P
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"
> >
>
> >
> > 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] User Accessible Tables, please review
On 1/28/07, Ulf Lamping <[EMAIL PROTECTED]> wrote: > Guy Harris wrote: > > Are these all preference settings? > > If so, should this be a preference type? It will be something tied to the pref module, in some cases. In some other cases it will be pointed by a menu item. > That's the same that comes to my mind. > > While I can see that this is a case for a new preference setting type, > adding a completely new mechanism really seems "over engineered" - > unless there's a real good reason to do so. How you manage a list of 0-N pairs (or triplets or quintuplets or...) of values? Now for snmp and k12 I used a string preference that points to a file (each in its own format) and users have to set the preference and then edit the file. Which another the point you make: > > Another drawback of your solution is to explain things to users - some > settings can be set through the GUI, some other can be set through a > file in, some can be ... - that doesn't sound very clean to me. 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. -- 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] 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
[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=rev&revision=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] 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
