Re: [Wireshark-dev] Possible bug with check_col?
I've written a bug up on this (bug #1132). I believe the culprit is a combination of the SSL dissector and the http dissector. -Brian Brian Vandenberg wrote: >> IIRC there's a call to col_set_writable(.., FALSE) >> somewhere in dissector-http.c >> >> > Thanks for the tip, I had figured out that it wasn't writable, but I > hadn't [yet] found where it was being set to not writable. I'm slowly > narrowing in on this, so hopefully I'll know what's causing this soon. > > -Brian > ___ > 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] Possible bug with check_col?
> > IIRC there's a call to col_set_writable(.., FALSE) > somewhere in dissector-http.c > > Thanks for the tip, I had figured out that it wasn't writable, but I hadn't [yet] found where it was being set to not writable. I'm slowly narrowing in on this, so hopefully I'll know what's causing this soon. -Brian ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [Patch] Change to preferences dialog title
Stephen Fisher wrote: > Attached is a patch for consideration that changes the title in the > preferences notebook to be the full description of the preference (but > leaves the short name in the preferences list on the left). > Checked in. Looking nice :-) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Warning: Current version of cygwin's bash doesn't work!
Hi List! After upgrading to the latest cygwin versions, the Wireshark "setup" target (and probably other parts as well) wasn't working any longer - with a very strange error message. Downgrading bash from 3.18 to 3.16 solved the problem (at least for me). You may better not upgrade cygwin for now ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] How do I open a file?
On Sep 29, 2006, at 7:36 AM, LEGO wrote: > --- > The Ethereal project is being continued at a new site. Please go to > http://www.wireshark.org and subscribe to [EMAIL PROTECTED] > Don't forget to unsubscribe from this list at > http://www.ethereal.com/mailman/listinfo/ethereal-dev > --- Oops. I assume you meant to send this to wireshark-dev. > I want to add open_file(filename) and start_capture(if) to the Lua > interface. > > is it feasable? > where in the codebase do I find the code that does that? Is that just "open" in the sense of, for example, fopen(), or does it mean opening a capture file for reading and writing? And what sort of handle are you expecting to get back from start_capture(if)? I.e., what sort of operations would you do on the result? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [Patch] Change to preferences dialog title
Attached is a patch for consideration that changes the title in the
preferences notebook to be the full description of the preference (but
leaves the short name in the preferences list on the left).
Current:
+- EXEC --
|
New:
+- Remote Process Execution
|
Thanks,
Steve
Index: gtk/prefs_dlg.c
===
--- gtk/prefs_dlg.c (revision 19364)
+++ gtk/prefs_dlg.c (working copy)
@@ -316,7 +316,7 @@
gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(main_sw),
GTK_POLICY_NEVER, GTK_POLICY_AUTOMATIC);
/* Frame */
-frame = gtk_frame_new(module->title);
+frame = gtk_frame_new(module->description);
gtk_container_set_border_width(GTK_CONTAINER(frame), 5);
gtk_scrolled_window_add_with_viewport(GTK_SCROLLED_WINDOW(main_sw), frame);
OBJECT_SET_DATA(main_sw, E_PAGESW_FRAME_KEY, frame);
Index: epan/prefs.c
===
--- epan/prefs.c(revision 19364)
+++ epan/prefs.c(working copy)
@@ -52,7 +52,7 @@
/* Internal functions */
static module_t *find_module(const char *name);
static module_t *prefs_register_module_or_subtree(module_t *parent,
-const char *name, const char *title, gboolean is_subtree,
+const char *name, const char *title, const char *description, gboolean
is_subtree,
void (*apply_cb)(void));
static struct preference *find_preference(module_t *, const char *);
static intset_pref(gchar*, gchar*);
@@ -139,10 +139,10 @@
*/
module_t *
prefs_register_module(module_t *parent, const char *name, const char *title,
-void (*apply_cb)(void))
+const char *description, void (*apply_cb)(void))
{
- return prefs_register_module_or_subtree(parent, name, title, FALSE,
- apply_cb);
+ return prefs_register_module_or_subtree(parent, name, title,
description,
+ FALSE, apply_cb);
}
/*
@@ -152,15 +152,15 @@
* dialog box.
*/
module_t *
-prefs_register_subtree(module_t *parent, const char *title)
+prefs_register_subtree(module_t *parent, const char *title, const char
*description)
{
- return prefs_register_module_or_subtree(parent, NULL, title, TRUE,
+ return prefs_register_module_or_subtree(parent, NULL, title,
description, TRUE,
NULL);
}
static module_t *
prefs_register_module_or_subtree(module_t *parent, const char *name,
-const char *title, gboolean is_subtree, void (*apply_cb)(void))
+const char *title, const char *description, gboolean is_subtree, void
(*apply_cb)(void))
{
module_t *module;
const char *p;
@@ -169,6 +169,7 @@
module = g_malloc(sizeof (module_t));
module->name = name;
module->title = title;
+ module->description = description;
module->is_subtree = is_subtree;
module->apply_cb = apply_cb;
module->prefs = NULL; /* no preferences, to start */
@@ -261,12 +262,13 @@
/*
* No. Do so.
*/
- protocols_module = prefs_register_subtree(NULL, "Protocols");
+ protocols_module = prefs_register_subtree(NULL, "Protocols",
NULL);
}
protocol = find_protocol_by_id(id);
return prefs_register_module(protocols_module,
proto_get_protocol_filter_name(id),
- proto_get_protocol_short_name(protocol), apply_cb);
+ proto_get_protocol_short_name(protocol),
+ proto_get_protocol_name(id), apply_cb);
}
/*
@@ -286,12 +288,13 @@
/*
* No. Do so.
*/
- protocols_module = prefs_register_subtree(NULL, "Protocols");
+ protocols_module = prefs_register_subtree(NULL, "Protocols",
NULL);
}
protocol = find_protocol_by_id(id);
module = prefs_register_module(protocols_module,
proto_get_protocol_filter_name(id),
- proto_get_protocol_short_name(protocol), NULL);
+ proto_get_protocol_short_name(protocol),
+ proto_get_protocol_name(id), NULL);
module->obsolete = TRUE;
return module;
}
Index: epan/prefs.h
===
--- epan/prefs.h(revision 19364)
+++ epan/prefs.h(working copy)
@@ -176,7 +176,7 @@
* call so that the "Protocol Properties..." menu item works.
*/
extern module_t *prefs_register_module(module_t *parent, const char *name,
-const char *title, void (*apply_cb)(void));
+const char *title, const char *description, void (*apply_cb)(void));
/*
* Register a subtree that will have modules under it.
@@ -184,7 +184,8 @@
* at the top level and the title used in the tab for it in a preferences
* dialog box.
*/
-extern module_t *prefs_register_subtree(module_t *parent, const char *title);
+extern module_t *prefs_register_subtree(module_t *parent, const char *title,
+
Re: [Wireshark-dev] packet-ssl bug(s)?
I submitted this about a month ago. Did it slip through the cracks? http://www.wireshark.org/lists/wireshark-dev/200608/msg00763.html Regards, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maynard, Chris Sent: Wednesday, August 30, 2006 1:19 AM To: Developer support list for Wireshark Subject: [Wireshark-dev] packet-ssl bug(s)? Since SSL decryption is now supposed to be supported on the Windows installer, I thought I would try out the "snakeoil2" example posted at http://wiki.wireshark.org/SSL. First, I set the RSA keys list as specified - well almost as specified. The wiki says the file name is snakeoil2.key, but it actually extracts as rsasnakeoil2.key. Next, I opened the rsasnakeoil2.cap file. At first glance, things look pretty good. For example, if you select Frame #11, Info column shows "GET / HTTP/1.1", and the packet details pane contains a separate tree for "Hypertext Transfer Protocol", which can be expanded to show the decrypted details. Nice. However if you look at Frame #31, for example, the Info column displays "GET /icons/debian/openlogo-25.jpg HTTP/1.1", but the packet details pane doesn't actually display the decrypted data. Continuing, I then applied an ssl display filter. At this point, things seemed to go horribly wrong. Frame #11 still seemed ok at this point, but most frames, including Frame #31 now showed only "Application Data" in the Info column where more useful text was once shown. What's even weirder to me is that when you clear the ssl display filter, the Info column still displays just the "Application Data" rather than reverting back to the original text. It gets even worse. If you merely close the file, reopen it, then look at Frame #11, its Info column still displays the correct text, but now the HTTP decrypted data no longer appears. Applying the ssl filter and then clearing it now affects Frame #11 the same as all the other frames. Basically you have to exit Wireshark then restart it to ever have that Frame decrypted again. On the Windows PC, I tried the example using wireshark SVN version 19082. I also tried this with Wireshark 0.99.3 running on Linux Fedora Core 4 and had the same results. Regards, Chris - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, 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 email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch for NEMO
No, because ACOA doesn't contain a field for prefix length. See RFC 3775 Section 6.2.5. Regards, Nicolas Le 29.09.2006 16:57, Jaap Keuter a écrit : > Hi, > > Isn't this also true for ACOA? > 8<- > #define MIP6_ACOA_LEN16 > #define MIP6_ACOA_ACOA_OFF2 > #define MIP6_ACOA_ACOA_LEN 16 > 8<- > > Thanx, > Jaap > > On Fri, 29 Sep 2006, Nicolas DICHTEL wrote: > >> Hi, >> >> please find enclosed a patch about Mobile Network Prefix >> option in NEMO. >> Following RFC3963 Section 4.3, lenght of this option is >> 18, not 16. >> >> >> Regards, >> Nicolas >> >> >> > > > > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch for NEMO
Hi, Isn't this also true for ACOA? 8<- #define MIP6_ACOA_LEN16 #define MIP6_ACOA_ACOA_OFF2 #define MIP6_ACOA_ACOA_LEN 16 8<- Thanx, Jaap On Fri, 29 Sep 2006, Nicolas DICHTEL wrote: > Hi, > > please find enclosed a patch about Mobile Network Prefix > option in NEMO. > Following RFC3963 Section 4.3, lenght of this option is > 18, not 16. > > > Regards, > Nicolas > > > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Patch for NEMO
Hi, please find enclosed a patch about Mobile Network Prefix option in NEMO. Following RFC3963 Section 4.3, lenght of this option is 18, not 16. Regards, Nicolas --- wireshark-0.99.3a-orig/epan/dissectors/packet-mip6.h 2006-08-24 19:00:38.0 +0200 +++ wireshark-0.99.3a/epan/dissectors/packet-mip6.h 2006-09-29 16:18:07.967231797 +0200 @@ -10,6 +10,7 @@ * * Modifications for NEMO packets (RFC 3963): Bruno Deniaud * ([EMAIL PROTECTED], [EMAIL PROTECTED]) 12 Oct 2005 + * Copyright 2006, Nicolas DICHTEL - 6WIND - <[EMAIL PROTECTED]> * * Wireshark - Network traffic analyzer * By Gerald Combs <[EMAIL PROTECTED]> @@ -296,7 +297,7 @@ static const value_string fmip6_lla_optc #define MIP6_ACOA_ACOA_OFF2 #define MIP6_ACOA_ACOA_LEN 16 -#define NEMO_MNP_LEN 16 +#define NEMO_MNP_LEN 18 #define NEMO_MNP_PL_OFF 3 #define NEMO_MNP_MNP_OFF 4 #define NEMO_MNP_MNP_LEN 16 ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] LUA Development Issue - Pulling a Character
Ahad L. Amdani <[EMAIL PROTECTED]> writes: > > LEGO ...> writes: > > > > > It depends in how you want the char: > > > > - a one byte unsigned integer can be taken with u = tvb(offset,1):get_uint () > > I'm pulling a single, readable character (looking for a Y or an N) from the > packet. > Okay, correction: it's a 1 byte character with the 8 bits meaning individual things, and I've implemented it as a 1 byte unsigned integer for now, so I get outputs such as 128 or 255, etc. Thanks for all the help, Ahad ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] LUA Development Issue - Pulling a Character
LEGO <[EMAIL PROTECTED]> writes: > > It depends in how you want the char: > > - a one byte unsigned integer can be taken with u = tvb(offset,1):get_uint() > - a string containing just one char (supposing it's printable) would > be taken with str = tvb(offset,1):get_string() > - a bytearray that contains just one char would be ba = > tvb(offset,1):get_bytes() > the you can fetch the value of the first byte with ba[0] > See, the problem lies that when I try and call get_string() or get_bytes(), LUA doesn't recognize them as functions. It recognizes string() and bytes(), but they don't seem to return anything - or at least, that I can throw out onto the screen. I'm pulling a single, readable character (looking for a Y or an N) from the packet. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patch for typo in epan/dissectors/packet-per.c
Checked in. Brg, Tomas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Reinhard Speyerer Sent: Friday, September 29, 2006 12:54 PM To: wireshark-dev@wireshark.org Subject: [Wireshark-dev] Patch for typo in epan/dissectors/packet-per.c The attached patch fixes a small typo in epan/dissectors/packet-per.c. Regards, Reinhard ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Patch for typo in epan/dissectors/packet-per.c
The attached patch fixes a small typo in epan/dissectors/packet-per.c. Regards, Reinhard bitfield-typo-patch.gz Description: Unix tar archive ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] LUA Development Issue - Pulling a Character
It depends in how you want the char: - a one byte unsigned integer can be taken with u = tvb(offset,1):get_uint() - a string containing just one char (supposing it's printable) would be taken with str = tvb(offset,1):get_string() - a bytearray that contains just one char would be ba = tvb(offset,1):get_bytes() the you can fetch the value of the first byte with ba[0] Luis On 9/28/06, Ahad L. Amdani <[EMAIL PROTECTED]> wrote: > Ahad L. Amdani <[EMAIL PROTECTED]> writes: > > > > > Hello, > > > > I'm doing some extension development on Wireshark through LUA and I can't > seem > > to find out how to pull just a single character from the packet. The packet > is > > encoded in little endian format, so I can use the tvbrange:le_uint and > > tvbrange:le_float functions to pull those types of values, but there doesn't > > seem to be a tvbrange:char() -- there is a tvbrange:string() but it doesn't > > work correctly, or at least, in my experience. I also tried the bytes() and > > tried to print out the bytearray, but that didn't work either. > > > > I've just read that LUA also supports calling functions written in C. Is there > a C-based function pre-defined that takes specified amount of bytes or > characters from the packet? Possibly one that assumes little endian format, > such as the le_uint() and le_float() functions? > > Thanks in advance, > Ahad > > ___ > 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 to eyesdn wiretap module
Rolf Fiedler wrote: > I checked, channel 128 is used for ATM cells and channel 129 for layer 1 > indications like "G.708 synced" which are shown as frames. The ISDN dissector doesn't know anything about either of those. Neither of those are ISDN (B-ISDN maybe, but not classic ISDN), so it's not clear that they *should* know about them. Should the eyesdn Wiretap module return a link-layer type of WTAP_ENCAP_PER_PACKET for eyesdn files, and supply link-layer types of WTAP_ENCAP_ISDN for channels 0 through 30, WTAP_ENCAP_ATM with a pseudo-header indicating that the frame is an ATM cell for channel 128, and something appropriate (which might have to be added) for channel 129? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] patch to eyesdn wiretap module
Hi, No wories. I still think it's good to have sanity checks (You do _not_ want to get involved in corrupt capture files), but they should not hinder developement. So what I've done is open up the channel space from 128 up, which covers the cases seen so far and hopefully future stuff. Thanx, Jaap On Fri, 29 Sep 2006, Rolf Fiedler wrote: > > > Hi, > > > > > > I am the author of the eyesdn wiretap module. Recently we added ATM > > > support to our trace format. We used channel id 129 for that, so far > > > only 0 for D channel and 1-30 for bearer channels had been in use. > > > > > I've taken the liberty to keep the sanity check in place and added 129 > as as valid channel ID. > > -- > Sorry Jaap, > but this is no good. So far Wireshark complained about channel 129, now > it gets a little further and then complains about channel 128. I > checked, channel 128 is used for ATM cells and channel 129 for layer 1 > indications like "G.708 synced" which are shown as frames. > Either we implement the complete list of channels that we currently use > (0-D channel, 1-30 B channel, 128 ATM cells, 129 ATM layer indications) > and intend to use in the future and keep on updating that or we simply > remove the test. Sorry for giving you not all the information, but > a trace file format is a moving target in some respects. Either we get > rid of the test or we keep on patching the same spot. > > Sorry for causing more work, but I did not have this information > initially. What do you prefer, maintaining the list of channels in > source or removing the test? I would vote for the later (and wish I had > never included the channel test in the source). > > Best regards, > Rolf > > ___ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] patch to eyesdn wiretap module
> > Hi, > > > > I am the author of the eyesdn wiretap module. Recently we added ATM > > support to our trace format. We used channel id 129 for that, so far > > only 0 for D channel and 1-30 for bearer channels had been in use. > > I've taken the liberty to keep the sanity check in place and added 129 as as valid channel ID. -- Sorry Jaap, but this is no good. So far Wireshark complained about channel 129, now it gets a little further and then complains about channel 128. I checked, channel 128 is used for ATM cells and channel 129 for layer 1 indications like "G.708 synced" which are shown as frames. Either we implement the complete list of channels that we currently use (0-D channel, 1-30 B channel, 128 ATM cells, 129 ATM layer indications) and intend to use in the future and keep on updating that or we simply remove the test. Sorry for giving you not all the information, but a trace file format is a moving target in some respects. Either we get rid of the test or we keep on patching the same spot. Sorry for causing more work, but I did not have this information initially. What do you prefer, maintaining the list of channels in source or removing the test? I would vote for the later (and wish I had never included the channel test in the source). Best regards, Rolf ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
