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 packe
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 i
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 elimi
Hi
Thank you for the reply.. Can you also review the patch which I have
uploaded for inclusion in wireshark main source of dissectors.
Regards
Ankith
On Thu, May 5, 2011, Jeff Morriss said:
> Ankith Agarwal wrote:
>> Hi
>> I have written a dissector for MIH protocol as specified by IEEE 802
Fernandez, Rafael 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 have 5 messages in o
On 05/05/2011 16:00, Chris Maynard wrote:
> Fernandez, Rafael 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
>> i
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 many bytes are
n
On 05/05/2011 16:27, Chris Maynard wrote:
> 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
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 so
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 offse
Fernandez, Rafael 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, offset)+MESSAGE_HE
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 following:
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?
>
> M
On 05/05/2011 16:59, Fernandez, Rafael wrote:
> 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_t
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
Fernandez, Rafael writes:
> OK. This function returns exactly the same as yours. The rest of the code in
there for debugging purposes.
You're right. I got distracted by the comparison still being done between
last_size and remaining.
> Don't you think there is an issue with this?
Can you try
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_
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: Thursday
On May 5, 2011, at 8:59 AM, Fernandez, Rafael wrote:
> 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, offset)+MESSAGE_HEADER_SIZE;
So, in your pro
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 suppo
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 pinfo->de
Fernandez, Rafael 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" argument.
If the pro
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
On Thursday, May 5, 2011, 9:06:27 PM, Chris Maynard wrote:
> Fernandez, Rafael 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 w
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 proble
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:
Bui
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:
Bui
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
2011/5/6 Jeff Morriss :
> 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 Reas
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: vs
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:
37 matches
Mail list logo
