On Wed, May 04, 2011 at 04:40:12PM -0600, Stephen Fisher wrote:
On Wed, May 04, 2011 at 09:19:08PM +, darkja...@wireshark.org wrote:
Log:
XXX, should this code use g_try_malloc instead?
is that inside GTK+ and GLib,
they still use g_malloc, so we can't totally eliminate the
Hi
I have written a dissector for MIH protocol as specified by IEEE 802.21
standard, and have submitted it as a patch in bugzilla..
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5881
But I have some problem, what is the transport protocol and the port
number to be used to decode the
Hi,
epan/ftypes/ftype_bytes.c:ipv6_repr_len() returns 39 which is length of:
:::::::
But it's common to have INET6_ADDRSTRLEN defined to 46, which I believe is
length of ::::::255.255.255.255 + 1 byte for NUL.
IMHO when IPv4-mapping is
On Thu, May 05, 2011 at 02:01:06PM +0200, Jakub Zawadzki wrote:
IMHO when IPv4-mapping is used the longest address is:
:::255.255.255.255 (22B)
Anyone knows inet_ntop(AF_INET6, ..) implementation which can actually use 46
bytes?
Maybe some inet_ntop() implementation don't generate
Ankith Agarwal wrote:
Hi
I have written a dissector for MIH protocol as specified by IEEE 802.21
standard, and have submitted it as a patch in bugzilla..
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5881
But I have some problem, what is the transport protocol and the port
number to be
Jakub Zawadzki wrote:
On Wed, May 04, 2011 at 04:40:12PM -0600, Stephen Fisher wrote:
On Wed, May 04, 2011 at 09:19:08PM +, darkja...@wireshark.org wrote:
Log:
XXX, should this code use g_try_malloc instead?
is that inside GTK+ and GLib,
they still use g_malloc, so we can't totally
Fernandez, Rafael Rafael.Fernandez@... writes:
I am writing a dissector plugin and I am using tcp_dissect_pdus in order to
reassemble packets. However, I
am experiencing issues when there are multiple application layer messages in
one packet and the last one
is not complete. Specifically, I
On 05/05/2011 16:00, Chris Maynard wrote:
Fernandez, Rafael Rafael.Fernandez@... writes:
I am writing a dissector plugin and I am using tcp_dissect_pdus in order to
reassemble packets. However, I
am experiencing issues when there are multiple application layer messages in
one packet and the
Graham Bloice graham.bloice@... writes:
The
get_message_tcpmessage_len function should also check that there
are enough bytes in the passed in tvb to call tvb_get_letohl(),
as the OP's code did.--
I don't think that's the case as tcp_dissect_pdus() is told how
On 05/05/2011 16:27, Chris Maynard wrote:
Graham Bloice graham.bloice@... writes:
The
get_message_tcpmessage_len function should also check that there
are enough bytes in the passed in tvb to call tvb_get_letohl(),
as the OP's code did.--
I don't think that's
I've been trying to review some patches lately, but have not had much
free time... But don't worry, since it's in the database, it will not
be forgotten.
Ankith Agarwal wrote:
Hi
Thank you for the reply.. Can you also review the patch which I have
uploaded for inclusion in wireshark main
All,
I used to have a very simple get_message_tcpmessage_len. But most of the TCP
packets would then say [TCP segment of a reassembled PDU].
I eliminated everything again. This is my current get_message_tcpmessage_len:
guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
Fernandez, Rafael Rafael.Fernandez@... writes:
This is my current get_message_tcpmessage_len:
guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
offset)
{
guint remaining = tvb_length_remaining(tvb, offset);
guint last_size = tvb_get_letohl(tvb,
OK. This function returns exactly the same as yours. The rest of the code in
there for debugging purposes. I appreciate you trying to help me but you are
focusing in wireshark coding standards and lines that do not have anything to
do with the issue I am experiencing. The issue is the
On 5/5/11 6:01 AM, Jakub Zawadzki wrote:
On Thu, May 05, 2011 at 02:01:06PM +0200, Jakub Zawadzki wrote:
IMHO when IPv4-mapping is used the longest address is:
:::255.255.255.255 (22B)
Anyone knows inet_ntop(AF_INET6, ..) implementation which can actually use
46 bytes?
Maybe some
FYI
Wireshark 1.5.1 can export SMB objects:
http://www.wireshark.org/download.html
Jose Pico submitted a patch to add this feature to Wireshark:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4451
The white paper: A tool for capturing SMB files with Wireshark by David
Perez Jose Pico is
Most network traffic is in network byte order and uses Big-Endian.
I am trying to dissect a packet that uses Little-Endian.
Before I write my own bit decoder...is there any built in functions
that will convert Little-Endian to Big-Endian for me..??
Thanks,
Brian
On Thu, May 05, 2011 at 02:39:05PM -0400, Brian Oleksa wrote:
Before I write my own bit decoder...is there any built in functions
that will convert Little-Endian to Big-Endian for me..??
http://developer.gnome.org/glib/unstable/glib-Byte-Order-Macros.html
You are interested in G*_SWAP_LE_BE
On May 5, 2011, at 11:39 AM, Brian Oleksa wrote:
Most network traffic is in network byte order and uses Big-Endian.
Actually, lots of network traffic is plain text or raw binary data (HTTP, for
example), and SMB/SMB2 are little-endian except for the raw binary data (read
and write payload) -
There are only TCP packets in my capture file. I don't have access to svn at
work, I just tried the 1.5.1 dev version code. It is the same.
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Chris Maynard
Sent:
Correct. Please look at the message I sent about an hour ago for a detailed
explanation of the issue.
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: Thursday, May 05, 2011 2:26 PM
To: Developer
On May 5, 2011, at 10:39 AM, Fernandez, Rafael wrote:
The issue is the following:
In epan/dissectors/packet-tcp.c-tcp_dissect_pdus():
line 1993: get_pdu_len returns 322. Sets plen to 322.
line 2053-2061: length_remaining is 144. Thus (length_remaining plen) is
true. Sets
Fernandez, Rafael Rafael.Fernandez@... writes:
There are only TCP packets in my capture file.
That may be true, but as described in the doc/README.developer file in section
1.2 Skeleton code,
A protocol dissector may be called in 2 different ways - with, or
without a non-null tree
On May 5, 2011, at 1:06 PM, Chris Maynard wrote:
Note, however, that you must fill in column information, create
conversations, reassemble packets, build any other persistent state
needed for dissection, and call subdissectors regardless of whether
tree is NULL or not. ...
I.e.,
I completely agree with your answer. That is what I expect to happen.
I was able to download wireshark-1.5.2-SVN-36997, compile against it, and the
issue still happens.
I must note that there is a [TCP Previous segment lost] and a [TCP
out-of-order] 10 frames apart and it is also where the
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/3053
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-x86
Build Reason:
The Buildbot has detected a new failure of OSX-10.6-x64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.6-x64/builds/2603
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.6-x64
Build Reason:
Fernandez, Rafael wrote:
I completely agree with your answer. That is what I expect to happen.
I was able to download wireshark-1.5.2-SVN-36997, compile against it, and the
issue still happens.
I must note that there is a [TCP Previous segment lost] and a [TCP
out-of-order] 10 frames apart and
On May 5, 2011, at 1:49 PM, John Sullivan wrote:
I think knowing these things is pretty useful for the prospective
dissector writer - it certainly gives a better feel for the dynamics
of dissection and may help optimize the places where expensive work is
done - so I think that section of the
2011/5/6 Jeff Morriss jeff.morriss...@gmail.com:
Oh, those out-of-order packets are quite possibly the problem: see the
recent discussion here on Handling TCP packets reordering.
Would love to fix this problem somehow, but I'm lack of knowledge of
wireshark's core :(
--
Max
The Buildbot has detected a new failure of OSX-10.5-PowerPC on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-PowerPC/builds/2644
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-ppc
Build
The Buildbot has detected a new failure of Visual-Studio-Code-Analysis on
Wireshark (development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Visual-Studio-Code-Analysis/builds/649
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build:
The Buildbot has detected a new failure of Windows-7-x64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Windows-7-x64/builds/1744
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: windows-7-x64
Build Reason:
33 matches
Mail list logo
