Re: [Wireshark-dev] Bug 491 : time delta behaviour
Sake Blok wrote: On Mon, Mar 19, 2007 at 10:45:42AM +0800, Jeff Morriss wrote: I did however start to look into the code to see how I could implement the extra field. I realise that I need to start to understand how wireshark actually handles frames. Some fields are filled by the dissector and some fields are filled while looping through the packets it seems. It will take me some time to understand how this works and where the field must be generated. Any help on this is more than welcome. Look for where del_ts is set in file.c (Wireshark) and tshark.c (tshark). You'll need a new timestamp in the frame data structure. Then in packet-frame.c you'll need to put this new timestamp in a new frame header field, similar to the current field. Thanks Jeff, that gives me the proper starting points for writing the enhancement. I'm glad the bug is marked with Low priority and Minor severity, that give me the time to grasp all the mechanisms involved :) I assigned the bug to myself, I hope that is the proper way to use bugzilla (as this is my first time to write code to solve an already listed bug). I don't know if there is a proper way but I will mention that since the bug is now assigned to you, the rest of us (on the bugzilla mailing list) won't be notified of any changes to the bug (e.g., new comments, patches attached, etc.). IMO just setting the bug state to Assigned with a note saying you're looking at it (but not changing the Assignee field) is sufficient, at least for people who don't have SVN commit access. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Query on status of patches
Joerg Mayer wrote: On Wed, Mar 14, 2007 at 09:58:26AM +0100, Sake Blok wrote: I have not seen many patches being overlooked actually. There were the occasions where a review lasted a little longer, but most patches were commited within a couple of days. Maybe a patch-tracking system is a little overkill. The majority of patches seem to be easy to review and commit. Something that we have (sort of) promoted in the past was the following: Submit your patch to the ml. In case the patch isn't committed/nacked within 3-4 days then open a bug and attach the patch to the bug. This way the patch won't get lost and we don't have the management overhead of tracking all the patches in the bugtracking system. It would also be good to put [PATCH] or some such in the Synopsis of the bug. Otherwise when scanning the list of bugs it's not obvious that not only are you requesting feature X but you've already implemented it. [Of course if you click the box that says your attachment is a patch then we can search for patches based on that field but that doesn't work if you've compressed or otherwise made your patch not look like a patch to bugzilla.] ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Getting destination IP
Hi, [Please don't send Excel docs to the mailing list--especially if they contain a picture. Not everyone has high speed Internet connections and not everyone can read Excel docs.] sara vanan wrote: [...] /home/saravanan/ethereal-0.99.0/tethereal -c 10 port 53 Capturing on eth0 [...] it displays (www.google.co.in http://www.google.co.in) URL link IP. Instead of this I want to filter only DNS. 192.168.16.67 http://192.168.16.67/ and 192.168.16.106 http://192.168.16.106/. client IP)(DNS server IP) I had attached the sample excel file for your reference. for this what kind of filters should I use in my command. With a filter of just dns Wireshark will show you all the DNS queries it sees. If you want only DNS to/from the specific IP addresses listed, you could do: dns ip.addr == 192.168.16.67 ip.addr == 192.168.16.106 for example. If you want only DNS from a specific IP to a specific IP you could do: dns ip.src == 192.168.16.67 ip.dest == 192.168.16.106 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Getting destination IP
Ok, Here after I will not send any attachments to the wireshark developer list. Sorry for attaching the excel sheet. On 3/20/07, Jeff Morriss [EMAIL PROTECTED] wrote: Hi, [Please don't send Excel docs to the mailing list--especially if they contain a picture. Not everyone has high speed Internet connections and not everyone can read Excel docs.] sara vanan wrote: [...] /home/saravanan/ethereal-0.99.0/tethereal -c 10 port 53 Capturing on eth0 [...] it displays (www.google.co.in http://www.google.co.in) URL link IP. Instead of this I want to filter only DNS. 192.168.16.67 http://192.168.16.67/ and 192.168.16.106 http://192.168.16.106/. client IP)(DNS server IP) I had attached the sample excel file for your reference. for this what kind of filters should I use in my command. With a filter of just dns Wireshark will show you all the DNS queries it sees. If you want only DNS to/from the specific IP addresses listed, you could do: dns ip.addr == 192.168.16.67 ip.addr == 192.168.16.106 for example. If you want only DNS from a specific IP to a specific IP you could do: dns ip.src == 192.168.16.67 ip.dest == 192.168.16.106 ___ 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] Getting destination IP
Hi, I am doing a DNS proxy for IPV6. For this I have to get the destination IP(DNS Sever IP stored in the client PC. I am trying to use Wireshark source code for getting the desdtination IP. for example client IP - 192.168.16.67DNS ( destination IP) - 192.168.16.106 By using the Wireshark GUI I use DNS filter and it displays source IP destination IP 192.168.16.67192.168.16.106 Request http://192.168.16.106/ then 192.168.16.106 192.168.16.67 Responsehttp://192.168.16.67/ And in LINUX when I am executing with the command /home/saravanan/ethereal- 0.99.0/tethereal -c 10 port 53 [EMAIL PROTECTED] ethereal-0.99.0 ]# /home/saravanan/ethereal-0.99.0/tethereal -c 5 port 53 Capturing on eth0 0.00 192.168.16.67 - 192.168.16.106 DNS Standard query A www.samedi.org 0.004528 192.168.16.106 - 206.51.233.130 DNS Standard query A www.samedi.org 0.177348 206.51.233.130 - 192.168.16.106 DNS Standard query response A 206.51.233.130 0.178324 192.168.16.106 - 192.168.16.67 DNS Standard query response A 206.51.233.130 6.968992 192.168.16.67 - 192.168.16.106 DNS Standard query A statse.webtrendslive.com 6.970539 192.168.16.106 - 220.73.220.4 DNS Standard query A statse.webtrends.akadns.net 7.028039 220.73.220.4 - 192.168.16.106 DNS Standard query response A 63.236.111.50 it displays (www.google.co.in) URL link IP. Instead of this I want to filter only the source IP and destination IP. For this what kind of filters should I use. Kindly help me regarding this. Thanks Saravanan ___ 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?
Jeff Morriss wrote: In fact I meant it just as a stop-gap until someone (smarter--or at least with more than to dedicate to the purpose--than me) can fix Wireshark's unsigned-vs-signed char problem. As it is, I have to scroll through hundreds of (probably not fixable by me) warnings just to get to things I have a chance of fixing. There's so many that my eyes glaze over as I'm looking for warnings--which makes it hard to detect real (read: things I can do something about) warnings. When I've gone on warning-fixing kicks I've resorted to doing: % grep -i warn make.out | grep -iv signed | less to find the (real) warnings. :-( What you describe is one of the consequences with our current way of doing. Even people that are willing to fix their or other peoples warnings are having a hard time as there are so many of them :-( If you start to fix the warnings that you can fix, that'll be a lot better than doing nothing at all ;-) I just meant that in the long run just ignoring a long list of warnings is probably not a good idea ... However, disabling the signed warning, fix the rest and setting the stop on error barrier would still be a lot better than what we currently have ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Getting destination IP
Is your question somehow related to development of Wireshark? I am afraid you are not asking at the best place. Purpose of Wireshark is to analyze packets. The command mentioned below gives brief display of the data. If you do not need all that info, consider using other commands to process it further. Good candidate would be cut. I am not sure what you mean by DNS proxy. I would assume it is some kind of application that will be listening for requests on udp port 53. There should be system calls available to get the address info needed. Hope this helps Andrej On Tue, 20.Mar.07 20:34:09 +0900, sara vanan wrote: Hi, I am doing a DNS proxy for IPV6. For this I have to get the destination IP(DNS Sever IP stored in the client PC. I am trying to use Wireshark source code for getting the desdtination IP. for example client IP - 192.168.16.67DNS ( destination IP) - 192.168.16.106 By using the Wireshark GUI I use DNS filter and it displays source IP destination IP 192.168.16.67192.168.16.106 Request http://192.168.16.106/ then 192.168.16.106 192.168.16.67 Responsehttp://192.168.16.67/ And in LINUX when I am executing with the command /home/saravanan/ethereal- 0.99.0/tethereal -c 10 port 53 [EMAIL PROTECTED] ethereal-0.99.0 ]# /home/saravanan/ethereal-0.99.0/tethereal -c 5 port 53 Capturing on eth0 0.00 192.168.16.67 - 192.168.16.106 DNS Standard query A www.samedi.org 0.004528 192.168.16.106 - 206.51.233.130 DNS Standard query A www.samedi.org 0.177348 206.51.233.130 - 192.168.16.106 DNS Standard query response A 206.51.233.130 0.178324 192.168.16.106 - 192.168.16.67 DNS Standard query response A 206.51.233.130 6.968992 192.168.16.67 - 192.168.16.106 DNS Standard query A statse.webtrendslive.com 6.970539 192.168.16.106 - 220.73.220.4 DNS Standard query A statse.webtrends.akadns.net 7.028039 220.73.220.4 - 192.168.16.106 DNS Standard query response A 63.236.111.50 it displays (www.google.co.in) URL link IP. Instead of this I want to filter only the source IP and destination IP. For this what kind of filters should I use. Kindly help me regarding this. Thanks Saravanan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Ulf Lamping wrote: I just meant that in the long run just ignoring a long list of warnings is probably not a good idea ... However, disabling the signed warning, fix the rest and setting the stop on error barrier would still be a lot better than what we currently have ... I heartily agree with Ulf on this - anything that you can do to reduce the number of warnings is a good thing. 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. What needs to happen is a purge on as many warnings as possible, followed by turning on treat warnings as errors. This can be done platform-by-platform if need be. If you have to turn off the signed warning to make this viable, so be it - but it's there for a reason, and in general should be possible to fix properly rather than either just turning it off altogether, or casting away with a (void*). 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... ___ 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?
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. 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. Martin __ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Getting rid of warnings should not be confused with getting rid of the *reasons* for those warnings. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is intuitive he means the exact opposite. pgpomulJckxPF.pgp Description: PGP signature ___ 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
[Wireshark-dev] [PATCH] analyzing SHIM6 protocol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
The last two months I have been working on a SHIM6 enabled version of
Wireshark. The subject of my final thesis is about SHIM6 and I needed to
analyze the SHIM6 communication exchange. SHIM6 is an IPv6 based
solution for multihoming.(www.shim6.org)
SHIM6 is handled as an IPv6 extension header. So I have changed the
source and header files of packet-ipv6. I have added dissecting
functions for different the message formats of the SHIM6 protocol.
I also needed to change the ipproto files to add the new extension
header. The included patch is pretty clear about that.
The message formats are conform the latest draft specification of SHIM6:
http://tools.ietf.org/html/draft-ietf-shim6-proto-07
http://tools.ietf.org/html/draft-ietf-shim6-failure-detection-07
Regards,
Matthijs Mekking
[EMAIL PROTECTED]
NLNetLabs Amsterdam / Radboud University Nijmegen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF//D+NiaStnTWEtYRAmxUAJ4+s+KNTUkOJQY0vm+9Yr7f5KT3XgCeLrDA
Nb8iiJWcL4aZoQzgkTteSHc=
=HW21
-END PGP SIGNATURE-
diff -r -u -N --strip-trailing-cr
wireshark-0.99.5/epan/dissectors/packet-ipv6.c
wireshark-0.99.5-shim6/epan/dissectors/packet-ipv6.c
--- wireshark-0.99.5/epan/dissectors/packet-ipv6.c 2007-02-02
00:00:57.0 +0100
+++ wireshark-0.99.5-shim6/epan/dissectors/packet-ipv6.c2007-03-20
10:30:01.0 +0100
@@ -7,6 +7,8 @@
* By Gerald Combs [EMAIL PROTECTED]
* Copyright 1998 Gerald Combs
*
+ * SHIM6 support added by Matthijs Mekking [EMAIL PROTECTED]
+ *
* MobileIPv6 support added by Tomislav Borosa [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or
@@ -29,6 +31,7 @@
#endif
#include string.h
+#include math.h
#include stdio.h
#include glib.h
#include epan/packet.h
@@ -39,11 +42,13 @@
#include epan/prefs.h
#include epan/reassemble.h
#include epan/ipproto.h
+#include epan/ipv6-utils.h
#include epan/etypes.h
#include epan/ppptypes.h
#include epan/aftypes.h
#include epan/nlpid.h
#include epan/arcnet_pids.h
+#include epan/in_cksum.h
/*
* NOTE: ipv6.nxt is not very useful as we will have chained header.
@@ -77,6 +82,10 @@
static int hf_ipv6_mipv6_length = -1;
static int hf_ipv6_mipv6_home_address = -1;
+static int hf_ipv6_shim6 = -1;
+static int hf_ipv6_shim6_nxt = -1;
+static int hf_ipv6_shim6_len = -1;
+
static gint ett_ipv6 = -1;
static gint ett_ipv6_fragments = -1;
static gint ett_ipv6_fragment = -1;
@@ -168,6 +177,19 @@
}
offset += advance;
goto again;
+ case IP_PROTO_SHIM6:
+ if (!BYTES_ARE_IN_FRAME(offset, len, 2)) {
+ ld-other++;
+ return;
+ }
+ nxt = pd[offset];
+ advance = (pd[offset+1] + 1) 3;
+ if (!BYTES_ARE_IN_FRAME(offset, len, advance)) {
+ ld-other++;
+ return;
+ }
+ offset += advance;
+ goto again;
}
switch(nxt) {
@@ -557,16 +579,562 @@
return dissect_opts(tvb, offset, tree, Destination Option);
}
+/* START SHIM6 PART */
+static guint16 shim_checksum(const guint8 *ptr, int len)
+{
+ vec_t cksum_vec[1];
+
+ cksum_vec[0].ptr = ptr;
+ cksum_vec[0].len = len;
+ return in_cksum(cksum_vec[0], 1);
+}
+
+static int
+dissect_shim_ip_addr(tvbuff_t *tvb, int offset, proto_tree *tree, const char
*itemname, ...)
+{
+int count;
+struct e_in6_addr addr;
+
+for(count=0;count16;count++) {
+ addr.bytes[count] = tvb_get_guint8(tvb, offset+count);
+}
+
+proto_tree_add_text(tree, tvb, offset, 16, %s %s,
+ itemname, ip6_to_str(addr));
+
+return 16;
+}
+
+static int
+dissect_hex_val(tvbuff_t *tvb, int offset, int len, const char *itemname,
guint8 bitmask, proto_tree *tree)
+{
+proto_item *ti;
+int count;
+gint p;
+
+p = offset;
+
+ti = proto_tree_add_text(tree, tvb, offset, len, itemname);
+
+for (count=0; countlen; count++)
+{
+ if (count==0) {
+ proto_item_append_text(ti, 0x%02x, tvb_get_guint8(tvb, p+count)
bitmask);
+ }
+ else {
+ proto_item_append_text(ti, %02x, tvb_get_guint8(tvb, p+count));
+ }
+}
+
+return len;
+}
+
+static const value_string shimoptvals[] = {
+{ SHIM6_OPT_RESPVAL, Responder Validator },
+{ SHIM6_OPT_LOCLIST, Locator List },
+{ SHIM6_OPT_LOCPREF, Locator Preferences },
+{ SHIM6_OPT_CGAPDM, CGA Parameter Data Structure },
+{ SHIM6_OPT_CGASIG, CGA Signature },
+{ SHIM6_OPT_ULIDPAIR, ULID Pair },
+{ SHIM6_OPT_FII, Forked Instance Identifier },
+{ 0, NULL },
+};
+
+static const value_string shimverifmethods[] = {
+{ SHIM6_VERIF_HBA, HBA },
+{ SHIM6_VERIF_CGA, CGA },
+{ 0, NULL },
+};
+
+static const value_string shimflags[] = {
+{ SHIM6_FLAG_BROKEN, BROKEN },
+{ SHIM6_FLAG_TEMPORARY, TEMPORARY },
+{ 0, NULL },
+};
+
+static const value_string shimreapstates[] = {
Re: [Wireshark-dev] [PATCH] analyzing SHIM6 protocol
I think most the proto_tree_add_text could be replaced by proto_tree_add_item which could allow (i.e. at least Sébastien Barré ;)) to perform an easy search on specific items. ;) Regards, Sebastien Tandel Matthijs Mekking wrote: Hello, The last two months I have been working on a SHIM6 enabled version of Wireshark. The subject of my final thesis is about SHIM6 and I needed to analyze the SHIM6 communication exchange. SHIM6 is an IPv6 based solution for multihoming.(www.shim6.org) SHIM6 is handled as an IPv6 extension header. So I have changed the source and header files of packet-ipv6. I have added dissecting functions for different the message formats of the SHIM6 protocol. I also needed to change the ipproto files to add the new extension header. The included patch is pretty clear about that. The message formats are conform the latest draft specification of SHIM6: http://tools.ietf.org/html/draft-ietf-shim6-proto-07 http://tools.ietf.org/html/draft-ietf-shim6-failure-detection-07 Regards, Matthijs Mekking [EMAIL PROTECTED] NLNetLabs Amsterdam / Radboud University Nijmegen ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] idl2eth
Hi, Does anyone have idl2eth version for windows? I am stuck with linux version that is usable but only on linux. Does anyone have some other solution??? I need to create plugin for wireshark, to monitor my CORBA traffic... Thanks in advance, Kristijan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Compilation errors
Hi , I have written a dissector, compiled and tested it( no problems). But the same dissector when used by somebody else at a different location is giving compilation problems. They are using the same OS (RHEL 4) and the same compiler version as ours. It is giving the following error: make[3]: *** [packet-xxx.lo] Error 1 make[3]: Leaving directory `/opt/tools2/xxx_WiresharkDecoderPlugin_R1_Release-1/plugins/xxx' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/tools2/xxx_WiresharkDecoderPlugin_R1_Release-1/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/tools2/xxx_WiresharkDecoderPlugin_R1_Release-1' make: *** [all] Error 2 Your help is appreciated. //Tarani The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Tue, Mar 20, 2007 at 03:04:49AM +0100, Ulf Lamping wrote: 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 ;-) Indeed. 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). An incremental way to introduce this could be: Good ideas! 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 ... With automake, we just need to put AM_CFLAGS = -Werror in the Makefile.am file in each directory that we're working on. 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? Yes. 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)? I'm willing to work on the Unix warnings. Steve ___ 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 Tue, Mar 20, 2007 at 01:01:20PM -0700, Stephen Fisher wrote: 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 ... With automake, we just need to put AM_CFLAGS = -Werror in the Makefile.am file in each directory that we're working on. Of course, this assumes that all the C compilers we use accept -Werror. We may need to wrap this within compiler specific commands in the automake files. Steve ___ 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 Tue, Mar 20, 2007 at 12:44:06PM +, Martin Mathieson wrote: 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. Yup. I edit source files and compile in the Emacs GUI. It makes it easy to spot warnings errors during the compliation process (Control-X ` takes you to the next warning or error in the source code and in the compilation output). But you've got to have the right mindset to be able to stand using Emacs :). Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Bug 491 : time delta behaviour
On Tue, Mar 20, 2007 at 05:47:59PM +0800, Jeff Morriss wrote: Sake Blok wrote: I assigned the bug to myself, I hope that is the proper way to use bugzilla (as this is my first time to write code to solve an already listed bug). I don't know if there is a proper way but I will mention that since the bug is now assigned to you, the rest of us (on the bugzilla mailing list) won't be notified of any changes to the bug (e.g., new comments, patches attached, etc.). Oops, that is indeed not handy... I will reassign bug-491 to wireshark-bugs IMO just setting the bug state to Assigned with a note saying you're looking at it (but not changing the Assignee field) is sufficient, at least for people who don't have SVN commit access. Maybe someone can set up a page on the Wiki about how to use bugzilla. I looked for info on the website and on the wiki, but did not find any info on this. Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Bug 491 : time delta behaviour
On Wed, Mar 14, 2007 at 10:24:10AM +0100, Sake Blok wrote: OK, I think an extra field needs to be added to the frame-dissector so that both delta's are available, also for filtering, searching and coloring. It would also be nice to be able to have both fields available for the columns in the packet-list. The two options regarding field naming so far are: - use frame.time_delta_captured and frame.time_delta_displayed and drop support of frame.time_delta to emphasize this change - rename the current frame.time_delta field to frame.time_delta_displayed since this is what it currently means. Then use the field frame.time_delta for the delta in the capture as one would expect intuitively. I was able to build a patch for this bug over the last couple of days. I have chosen to use the second option. Also because frame.time_delta in tshark already provided the delta time between *captured* packets. Could someone review the patch (I attached it to bugzilla)? Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Fun with Cisco DLT-value usage
I believe the issue could be reported to Cisco TAC requesting correction, instead of hacking heuristics. At the other hand, did they announce somewhere that they are using libpcap format? I was googling a bit and found indications how to convert the file http://www.gossamer-threads.com/lists/engine?post=56109;list=cisco In one post is mentioned also that upcoming SW release is expected to create pcap files. Andrej On Thu, 15.Mar.07 20:30:01 -0700, Guy Harris wrote: On Mar 15, 2007, at 8:06 PM, Jeff Morriss wrote: I suppose you'll need heuristics like those described in the (long) comments in wiretap/libpcap.c. Or like the ones in epan/dissectors/packet-null.c. Now, if only the fine folks at Cisco had seen some other comments in that file, such as /* * Either LBL NRG wasn't an adequate central registry (e.g., because of * the slow rate of releases from them), or nobody bothered using them * as a central registry, as many different groups have patched libpcap * (and BPF, on the BSDs) to add new encapsulation types, and have ended * up using the same DLT_ values for different encapsulation types. * * For those numerical encapsulation type values that everybody uses for * the same encapsulation type (which inclues those that some platforms * specify different DLT_ names for but don't appear to use), we map * those values to the appropriate Wiretap values. * * For those numerical encapsulation type values that different libpcap * variants use for different encapsulation types, we check what * pcap.h defined to determine how to interpret them, so that we * interpret them the way the libpcap with which we're building * Wireshark/Wiretap interprets them (which, if it doesn't support * them at all, means we don't support them either - any capture files * using them are foreign, and we don't hazard a guess as to which * platform they came from; we could, I guess, choose the most likely * platform). * * Note: if you need a new encapsulation type for libpcap files, do * *N*O*T* use *ANY* of the values listed here! I.e., do *NOT* * add a new encapsulation type by changing an existing entry; * leave the existing entries alone. * * Instead, send mail to tcpdump-workers@tcpdump.org, asking for a new * DLT_ value, and specifying the purpose of the new value. When you * get the new DLT_ value, use that numerical value in the dlt_value * field of pcap_to_wtap_map[]. */ or /* * To repeat: * * If you need a new encapsulation type for libpcap files, do * *N*O*T* use *ANY* of the values listed here! I.e., do *NOT* * add a new encapsulation type by changing an existing entry; * leave the existing entries alone. * * Instead, send mail to tcpdump-workers@tcpdump.org, asking for * a new DLT_ value, and specifying the purpose of the new value. * When you get the new DLT_ value, use that numerical value in * the dlt_value field of pcap_to_wtap_map[]. */ or, in the bpf.h that comes with libpcap: /* * Data-link level type codes. * * Do *NOT* add new values to this list without asking * tcpdump-workers@tcpdump.org for a value. Otherwise, you run the * risk of using a value that's already being used for some other purpose, * and of having tools that read libpcap-format captures not being able * to handle captures with your new DLT_ value, with no hope that they * will ever be changed to do so (as that would destroy their ability * to read captures using that value for that other purpose). */ ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On 3/21/07, Stephen Fisher [EMAIL PROTECTED] wrote: On Tue, Mar 20, 2007 at 12:44:06PM +, Martin Mathieson wrote: Yup. I edit source files and compile in the Emacs GUI. It makes it easy to spot warnings errors during the compliation process (Control-X ` takes you to the next warning or error in the source code and in the compilation output). But you've got to have the right mindset to be able to stand using Emacs :). How do you mean? Emacs is the only true editor! How would you edit sourcecode if not using emacs? ( http://www.dina.kvl.dk/~abraham/religion/ ) !6 :-) ___ 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 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 ___ 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 Mar 20, 2007, at 1:08 PM, Stephen Fisher wrote: Of course, this assumes that all the C compilers we use accept - Werror. I doubt that they do (and they definitely don't, if by we you mean everybody who compiles Wireshark - it's been compiled with Sun C, HP's ANSI C compiler for HP-UX, and IBM's XLC compiler, among others). We may need to wrap this within compiler specific commands in the automake files. Or do it in the config file - look for -W in the top-level configure.in and the Wiretap configure.in. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Getting destination IP
Did you see my answer to your question in your previous email? (At the top of the email I said something about the Excel doc but I tried to answer your question below that.) sara vanan wrote: Hi, I am doing a DNS proxy for IPV6. For this I have to get the destination IP(DNS Sever IP stored in the client PC. I am trying to use Wireshark source code for getting the desdtination IP. for example client IP - 192.168.16.67 http://192.168.16.67/DNS ( destination IP) - 192.168.16.106 http://192.168.16.106/ By using the Wireshark GUI I use DNS filter and it displays source IP destination IP 192.168.16.67 http://192.168.16.67/ 192.168.16.106 Request http://192.168.16.106/ then 192.168.16.106 http://192.168.16.106/ 192.168.16.67Response http://192.168.16.67/ And in LINUX when I am executing with the command /home/saravanan/ethereal- 0.99.0/tethereal -c 10 port 53 [EMAIL PROTECTED] ethereal-0.99.0 ]# /home/saravanan/ethereal-0.99.0/tethereal -c 5 port 53 Capturing on eth0 0.00 192.168.16.67 http://192.168.16.67/ - 192.168.16.106 http://192.168.16.106/ DNS Standard query A www.samedi.org http://www.samedi.org/ 0.004528 192.168.16.106 http://192.168.16.106/ - 206.51.233.130 http://206.51.233.130/ DNS Standard query A www.samedi.org http://www.samedi.org/ 0.177348 206.51.233.130 http://206.51.233.130/ - 192.168.16.106 http://192.168.16.106/ DNS Standard query response A 206.51.233.130 http://206.51.233.130/ 0.178324 192.168.16.106 http://192.168.16.106/ - 192.168.16.67 http://192.168.16.67/ DNS Standard query response A 206.51.233.130 http://206.51.233.130/ 6.968992 192.168.16.67 http://192.168.16.67/ - 192.168.16.106 http://192.168.16.106/ DNS Standard query A statse.webtrendslive.com http://statse.webtrendslive.com/ 6.970539 192.168.16.106 http://192.168.16.106/ - 220.73.220.4 http://220.73.220.4/ DNS Standard query A statse.webtrends.akadns.net http://statse.webtrends.akadns.net/ 7.028039 220.73.220.4 http://220.73.220.4/ - 192.168.16.106 http://192.168.16.106/ DNS Standard query response A 63.236.111.50 http://63.236.111.50/ it displays ( www.google.co.in http://www.google.co.in/) URL link IP. Instead of this I want to filter only the source IP and destination IP. For this what kind of filters should I use. Kindly help me regarding this. Thanks Saravanan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On 3/21/07, Guy Harris [EMAIL PROTECTED] wrote: On Mar 20, 2007, at 5:21 PM, ronnie sahlberg wrote: How do you mean? Emacs is the only true editor! No, it's not: http://www.gnu.org/fun/jokes/ed.msg.html There *must* be an ed mode for emacs. so the point is that... After some years using emacs I understood it was emacs to be using me. In fact, by then, most of my editing time was spent in info mode learning how to use things I would have never ever needed. -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Joerg Mayer wrote: No, it won't work. I've spent many many hours in the past to get rid of compiler warnings and it just won't work. While we definitely should try to get rid of some warnings, fixing warnings on one platform may introduce warnings on other platforms (or even gcc versions). In particular, as I remember, there's at least one warning where, at least as I read the ANSI C standard, MSVC++ 6.0 is confused and incorrectly reports a const vs. non-const warning - and, if you change the code to get rid of that warning, GCC, at least, then warns (correctly) about the type clash. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
