[Wireshark-dev] Please copy 20562 to 0.99.5 branch
subject says it all. 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
[Wireshark-dev] [Patch] SCSI persistent reserve in
Hi,
This patch fixes three problems with the SCSI persistent reserve in command:
- The Additional length starts at offset 4 and not 0
- The len field contains the length used by the keys and doesn't include the
header length. So don't substract the header length from the length.
- The key list is traversed from the beginning to end end and not the other way
around.
Patrick
Index: epan/dissectors/packet-scsi.c
===
--- epan/dissectors/packet-scsi.c (revision 20564)
+++ epan/dissectors/packet-scsi.c (working copy)
@@ -3050,20 +3050,20 @@
proto_tree_add_text (tree, tvb, offset, 4, Generation Number: 0x%08x,
tvb_get_ntohl (tvb, offset));
len = tvb_get_ntohl (tvb, offset+4);
-proto_tree_add_text (tree, tvb, offset, 4, Additional Length: %u,
+proto_tree_add_text (tree, tvb, offset+4, 4, Additional Length: %u,
len);
len = (payload_len len) ? len : payload_len;
if ((flags 0x1F) == SCSI_SPC2_RESVIN_SVCA_RDKEYS) {
/* XXX - what if len is 8? That may be illegal, but
that doesn't make it impossible */
-numrec = (len - 8)/8;
+numrec = len / 8;
offset += 8;
for (i = 0; i numrec; i++) {
proto_tree_add_item (tree, hf_scsi_persresv_key, tvb, offset,
8, 0);
-offset -= 8;
+offset += 8;
}
}
else if ((flags 0x1F) == SCSI_SPC2_RESVIN_SVCA_RDRESV) {
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Using tcp_dissect pdus and fragment, segment reassembly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Graham Bloice wrote:
I've been attempting to add tcp fragment reassembly using
tcp_dissect_pdus() to an existing dissector that already used the epan
reassembly code for an internal part of the protocol.
However it seems that when I add the tcp_dissect_pdus() call then the
other reassembly stops working. The call to fragment_add_seq_check()
never returns a non-null fragment_data pointer.
I grep'd all the other dissectors and didn't find any using a
combination of both methods.
Is there a problem with using both, or have I just gone wrong somewhere?
I've now resolved my issues with the combination of the two reassembly
options, and the problem was down to errors in my dissector.
In doing so, I ran across a couple of documentation issues:
In the Developers Guide, Section 9.3, Example 9.17. Decompressing data
packets for dissection
The code calls tvb_set_free_cb() for the newly created next_tvb. This
is unnecessary as the call to tvb_set_child_real_data() adds next_tvb to
the chained list of tvb, thus ensuring that next_tvb is correctly
deleted. In fact when I had the call in, Visual Studio kept breaking
deep down in ntdll.dll, probably because of a double free every time the
main tvb was deleted.
In README.developer, para 2..2.7 The example conversation code doesn't
assign the result of conversation_new() back into the conversation variable.
I've attached patches for these two items.
- --
Regards,
Graham Bloice
Software Developer
Trihedral UK Limited
Tel: +44 (0)7002 874433
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFujSNcs4xxHO/MtURAhePAKCpo8vEg5zQq7wJ+t6u/qonrO8mHgCfSe85
eSti+m46GPuNkkT7jqSaM8o=
=MiNy
-END PGP SIGNATURE-
README.developer.patch.sig
Description: Binary data
WSDG_chapter_dissection.xml.patch.sig
Description: Binary data
Index: doc/README.developer
===
--- doc/README.developer(revision 20501)
+++ doc/README.developer(working copy)
@@ -2809,7 +2809,7 @@
/* create the conversation with your data pointer */
-conversation_new(pinfo-fd-num, pinfo-src, pinfo-dst, pinfo-ptype,
+conversation = conversation_new(pinfo-fd-num, pinfo-src, pinfo-dst,
pinfo-ptype,
pinfo-srcport, pinfo-destport, 0);
conversation_add_proto_data(conversation, my_proto, (void *)data_ptr);
}
Index: docbook/wsdg_src/WSDG_chapter_dissection.xml
===
--- docbook/wsdg_src/WSDG_chapter_dissection.xml(revision 20501)
+++ docbook/wsdg_src/WSDG_chapter_dissection.xml(working copy)
@@ -682,7 +682,6 @@
next_tvb = tvb_new_real_data(decompressed_buffer, orig_size,
orig_size);
tvb_set_child_real_data_tvbuff(tvb, next_tvb);
add_new_data_source(pinfo, next_tvb, Decompressed Data);
- tvb_set_free_cb(next_tvb, g_free);
} else {
next_tvb = tvb_new_subset(tvb, offset, -1, -1);
}
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Warning about radius directory
Team,
I notice that wireshark emits unconditionally warning mentioning that it
Could not find the radius directory.
I do not think that radius dictionary is needed for operation in all
environments, is is possible to move this output to some kind of
diagnostics mode?
Based on my search, it appears there for some time:
http://www.wireshark.org/lists/wireshark-bugs/200610/msg00501.html
I applied following patch:
Index: epan/dissectors/packet-radius.c
===
--- epan/dissectors/packet-radius.c (revision 20564)
+++ epan/dissectors/packet-radius.c (working copy)
@@ -1469,7 +1469,6 @@
dict = radius_load_dictionary(dir,dictionary,dict_err_str);
} else {
dict = NULL;
- dict_err_str = g_strdup(Could not find the radius directory);
}
g_free(dir);
Thanks
Andrej
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Warning about radius directory
The radius dictionary gets loaded way before preferences are
evaluated. Giving no warning and then having the packets undecoded
isn't elegant.
Your patch suppresses the error altoghether which is not a nice solution.
What you can do is just add a dummy radius dir and a dummy dictionary:
$ cd $WIRESHARK_DATA
$ mkdir radius
$ touch radius/dictionary
3 commands and the Warning is gone.
On 1/27/07, Andrej Mikus [EMAIL PROTECTED] wrote:
Team,
I notice that wireshark emits unconditionally warning mentioning that it
Could not find the radius directory.
I do not think that radius dictionary is needed for operation in all
environments, is is possible to move this output to some kind of
diagnostics mode?
Based on my search, it appears there for some time:
http://www.wireshark.org/lists/wireshark-bugs/200610/msg00501.html
I applied following patch:
Index: epan/dissectors/packet-radius.c
===
--- epan/dissectors/packet-radius.c (revision 20564)
+++ epan/dissectors/packet-radius.c (working copy)
@@ -1469,7 +1469,6 @@
dict = radius_load_dictionary(dir,dictionary,dict_err_str);
} else {
dict = NULL;
- dict_err_str = g_strdup(Could not find the radius
directory);
}
g_free(dir);
Thanks
Andrej
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark w/ MSVC++ 2005 EE fails to capture
On Thu, Jan 25, 2007 at 04:36:33PM -0800, Stephen Fisher wrote: On Thu, Jan 25, 2007 at 10:53:32PM +0100, Ulf Lamping wrote: Stephen Fisher wrote: When I run MSVC++ and attach to the process to debug before it crashes, it fails on line 650 of gui_utils.c. The line is within pipe_timer_cb() and says: handle = (HANDLE) _get_osfhandle (pipe_input-source); Hmmm, don't look familiar. I can capture with a msvc2005ee build without problems. I couldn't find anything wrong with the code so I deleted my source code and started over in the developer's guide. One thing I hadn't done before was change the config.nmake to use the 2005EE compiler instead of MSVC6. Now I can capture and open files :) One problem remains with name lookup - do you have that enabled when doing a msvc2005ee build? It's crashing at addr_resolv.c in the add_ipv4_name() function where it performs this: strncpy(tp-name, name, MAXNAMELEN). Name is an invalid pointer when it crashes after opening or capturing 10-30 frames or so even though adns is returning adns_s_ok in the previous call (host_name_lookup_process). Can you duplicate this problem? I can work on it further, but I wanted to make sure it isn't just a problem with my setup first. Thanks, Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent recursive IP dissector to fill summary columns
Hi, In the meantime I found Wireshark wishlist and I find my question related to first topic in dissection section at http://wiki.wireshark.org/WishList#head-415ef1ebe1134681b1db49769aa1d8bf027db057 Further check in header files reveals much more info compared to README files. Found that the functionality I was looking for it (partially) achieved by flag in_error_pkt. Also found information about modification of info column. To conclude, the attached patch would be acceptable? Thanks Andrej On Mon, 22.Jan.07 10:37:20 +0100, Andrej Mikus wrote: Team, While troubleshooting wccp traffic it is very useful that Wireshark goes deep into gre redirected packet and pulls the IP address from it. It makes it easy to follow tcp stream also when server responses are not GRE encapsulated. There are however also situations when the IP information from top level is interesting (what router redirected the packet to what wccp client) and I would like to implement a preference setting to get this kind of information. Some questions: - Where this preference should be most logical to place? (ip, gre, wccp) - How to actually implement it? It requires that packet-ip.c when called for second time should not update columns (and fields for display filter), but still continues to build tree for detailed display. Is there any way to find out if the packet being dissected is raw IP packet, or comes from GRE payload? I would like to modify the Info column in all cases to indicate that the packet is redirected, for example by prepending char '' to the info, regardless of dissector that produced it. Is this feasible? I notice that dissectors call col_clear all the time. Is it possible to modify the column after packet is completely dissected? In next step I am thinking of using '' to indicate packet returned back to router, but at this point still need to work out some protocol details. Attached is an example of packet I am concerned about. I hope it would help to assist. Output I would like to get after my changes is as follows: With new preference disabled (current operation): No. TimeSourceDestination Protocol Info 1 09:50:26.794117 10.254.127.19510.254.108.228DCERPC Request: call_id: 1 opnum: 16 ctx_id: 0 New preference enabled (show top level info in summary for wccp redirected frames) No. TimeSourceDestination Protocol Info 1 09:50:26.794117 10.254.127.19410.254.214.82 GREWCCP Redirected frame Frame 1 (282 bytes on wire, 282 bytes captured) Ethernet II, Src: Cisco_3a:ab:40 (00:0f:35:3a:ab:40), Dst: Ibm_28:99:a8 (00:14:5e:28:99:a8) Internet Protocol, Src: 10.254.127.194 (10.254.127.194), Dst: 10.254.214.82 (10.254.214.82) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 268 Identification: 0xac83 (44163) Flags: 0x00 Fragment offset: 0 Time to live: 253 Protocol: GRE (0x2f) Header checksum: 0xa42e [correct] Source: 10.254.127.194 (10.254.127.194) Destination: 10.254.214.82 (10.254.214.82) Generic Routing Encapsulation (WCCP) Flags and version: Protocol Type: WCCP (0x883e) Redirect header 0... = Well-known service .0.. = Alternative bucket not used Service ID: Unknown (0x59) Primary bucket index: 72 Internet Protocol, Src: 10.254.127.195 (10.254.127.195), Dst: 10.254.108.228 (10.254.108.228) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 240 Identification: 0x9114 (37140) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0xa650 [correct] Source: 10.254.127.195 (10.254.127.195) Destination: 10.254.108.228 (10.254.108.228) Transmission Control Protocol, Src Port: 1291 (1291), Dst Port: microsoft-ds (445), Seq: 0, Ack: 0, Len: 188 NetBIOS Session Service SMB (Server Message Block Protocol) SMB Pipe Protocol DCE RPC Request, Fragment: Single, FragLen: 100, Call: 1 Ctx: 0 Many thanks for your cooperation Andrej Mikus ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev my_patch.gz Description: application/gunzip ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark w/ MSVC++ 2005 EE fails to capture
Stephen Fisher wrote: I couldn't find anything wrong with the code so I deleted my source code and started over in the developer's guide. One thing I hadn't done before was change the config.nmake to use the 2005EE compiler instead of MSVC6. Now I can capture and open files :) Ah, someone followed the guide :-) It might be a good idea to add a compile time check, it the MSVC_VARIANT setting matches the _MSC_VER define. This way, such problems are at least harder to make :-) One problem remains with name lookup - do you have that enabled when doing a msvc2005ee build? It's crashing at addr_resolv.c in the add_ipv4_name() function where it performs this: strncpy(tp-name, name, MAXNAMELEN). Name is an invalid pointer when it crashes after opening or capturing 10-30 frames or so even though adns is returning adns_s_ok in the previous call (host_name_lookup_process). Can you duplicate this problem? I can work on it further, but I wanted to make sure it isn't just a problem with my setup first. It's working like a charm, with and without DNS / ADNS enabled. Without looking too deeply into it, I don't even know why this should go wrong. ADNS shouldn't provide any C runtime things that could cause trouble because of the different msvcr*.dll versions used. Sorry, no idea to help you ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Warning about radius directory
On 1/27/07, Andrej Mikus [EMAIL PROTECTED] wrote:
Thanks for comments.
Of course, I removed the message to stop coming out after I realized
that it is coming before preferences.
Creating file in my system does not address this problem for others.
Yep but Others usually install either with make install or from a
package that has the dictionary.
If you are tailoring a custom ws and do not need radius why do you
compile it to begin with you may save much more space removing 550
protocols that you don't need than removing the radius dictionary.
Elegant solution would be perhaps to postpone reading the directory until
it is really needed.
the hfarray is generated from the radius dictionary, it needs to be
registered at protocol registartion, at most at protocol handoff,
that's when its needed.
To filter on radius.UserName may be unelegant. Why a network
administrator would ever need that?
Alternatively, put the error message to tree output of relevant packets.
This way the user would realize very fast why his packets are not
decoded, while others do not see irrelevant warning.
That could be an Idea...
I am still wondering whether radius is the only dissector that uses
external file. If not, how do the others handle this kind of issue?
XML uses DTDs in the dtds directory but if it does not find any dtds
it does not register any extra protocols. For XML each DTD registers a
different protocol, the catch-all XML protocol gets registered anyway
but does not allow you to filter on a.b == bbb when there's
a\ba
Diameter does what you said before it tries to load the diictionary at
the first diameter packet, but diameter does not allow YET to filter
on contents of AVPS (i.e diameter.UserName does not exist, that's
sad).
AFAIK I'm the only one that has written such user configurable
dissectors so far...
I also failed to understand why tshark does not give this warning message.
maybe g_warning is handled differently (?)
Regards
Andrej
On Sat, 27.Jan.07 01:55:35 +0100, Luis Ontanon wrote:
The radius dictionary gets loaded way before preferences are
evaluated. Giving no warning and then having the packets undecoded
isn't elegant.
Your patch suppresses the error altoghether which is not a nice solution.
What you can do is just add a dummy radius dir and a dummy dictionary:
$ cd $WIRESHARK_DATA
$ mkdir radius
$ touch radius/dictionary
3 commands and the Warning is gone.
On 1/27/07, Andrej Mikus [EMAIL PROTECTED] wrote:
Team,
I notice that wireshark emits unconditionally warning mentioning that it
Could not find the radius directory.
I do not think that radius dictionary is needed for operation in all
environments, is is possible to move this output to some kind of
diagnostics mode?
Based on my search, it appears there for some time:
http://www.wireshark.org/lists/wireshark-bugs/200610/msg00501.html
I applied following patch:
Index: epan/dissectors/packet-radius.c
===
--- epan/dissectors/packet-radius.c (revision 20564)
+++ epan/dissectors/packet-radius.c (working copy)
@@ -1469,7 +1469,6 @@
dict =
radius_load_dictionary(dir,dictionary,dict_err_str);
} else {
dict = NULL;
- dict_err_str = g_strdup(Could not find the radius
directory);
}
g_free(dir);
Thanks
Andrej
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Warning about radius directory
On Sat, Jan 27, 2007 at 12:36:55AM +0100, Andrej Mikus wrote: I notice that wireshark emits unconditionally warning mentioning that it Could not find the radius directory. I assume that you are running Wireshark from its build directory without having a version installed? Guy recently added a feature whereby you can set the environment variable WIRESHARK_RUN_FROM_BUILD_DIRECTORY to 1 in your shell and it will use the directory wireshark is run from as the data directory (where there is a radius/ directory). Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Wireshark w/ MSVC++ 2005 EE fails to capture
Stephen Fisher wrote: On Sat, Jan 27, 2007 at 03:39:58AM +0100, Ulf Lamping wrote: It might be a good idea to add a compile time check, it the MSVC_VARIANT setting matches the _MSC_VER define. This way, such problems are at least harder to make :-) Would it be possible to just set MSVC_VARIANT automatically according to the _MSC_VER define Unfortunately not - at least not in a way that I see. For example there are four compiler packages possible for the C compiler version 8.0, so there's no 1:1 relationship. In addition the MSVC_VARIANT is needed for some differences in the NSIS packaging (and probably elsewhere), where _MSC_VER has just no effect. In fact most (all?) changes controlled with MSVC_VARIANT are outside the scope of _MSC_VER. So what could be done is a check that MSVC_VARIANT matches the _MSC_VER, at least this will prevent people from forgetting to set this altogether - as _MSC_VER 6 (the default) is only supported by one compiler package :-) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] update wiretap and sub dissector
On 1/23/07, Paolo Abeni [EMAIL PROTECTED] wrote: The linux header is enforced in host byte order by the wiretap/libpcap code: when a capture saved on by a host with different endianess is loaded and the data link is of the capture is DLT_USB_LINUX, the linux header fields are swapped. One problem is that the proto_tree_add_* calls set the little_endian flag to true regardless of the endianness of the host. For instance, if I create a .pcap file with text2pcap -l 189 ... on a big-endian machine, then the .pcap file seems not to have the byte-swapped flag set. That code seems to handle the case where an x86 machine captures and a PowerPC displays (for instance). Maybe I'm misinterpreting how this should work, though. It will probably be clearer once I get a chance to see real sample pcap files. If this patch is merged, must I update the wiki to reflect current status? Another thing here - it might be good to mention on the Wiki the versions of Wireshark that support the old raw USB encapsulation, and the new format that your patch adds/replaces. -- - Charles Lepple ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
