[Wireshark-dev] MIH protocol dissector
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 packet as MIH protocol. I have gone through the standard and I did not get any answer. For now I have directly taken it as 4551(as specified by IANA), is it right? Regards Ankith -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] IPv6 longest representation vs INET6_ADDRSTRLEN
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 used the longest address is: :::255.255.255.255 (22B) Anyone knows inet_ntop(AF_INET6, ..) implementation which can actually use 46 bytes? I'm asking because current code can lead to buffer overlow: ipv6_to_repr() -> ip6_to_str_buf((struct e_in6_addr *)fv->value.bytes->data, buf); -> inet_ntop(AF_INET6, (const guchar*)ad, buf, INET6_ADDRSTRLEN); I'm planning to fix it by #define MAX_IPV6_STR_LEN inside to_str.h (like we do for other addresses), but should it be 40 or 46 (or defined to INET6_ADDRSTRLEN)? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] IPv6 longest representation vs INET6_ADDRSTRLEN
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 short addresses? ( instead of ::) so ipv4 mapped address would be: "::::::255.255.255.255" I think I'll just copy inet_ntop6() from wsutil/inet_ntop.c to address_to_str.c... ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] MIH protocol dissector
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 used to decode the packet as MIH protocol. I have gone through the standard and I did not get any answer. For now I have directly taken it as 4551(as specified by IANA), is it right? Yes, using the IANA assignment certainly seems correct. RFC 5677 lists this IANA assignment too: http://tools.ietf.org/html/rfc5677#section-9 ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 36988: /trunk/ /trunk/epan/dissectors/: packet-iwarp-mpa.c packet-spnego.c packet-ssl-utils.c /trunk/: tap-iostat.c
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 eliminate the
possibilty of Wireshark being aborted when out of memory.
Hmm, we could set our own allocator (g_mem_set_vtable()),
and THROW OutOfMemoryError (instead of aborting)
for example vtab.malloc routine:
#v+
static gpointer
ws_malloc(gsize n_bytes)
{
gpointer ptr = malloc(n_bytes);
if (!ptr)
THROW(OutOfMemoryError);
return ptr;
}
#v-
Is it likely/possible that:
a) GTK (or glib) might acquire a lock before allocating something
b) (and) we might call another GTK function which requires the same lock
thus leading to a deadlock if we jump out of the allocation failure?
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] MIH protocol dissector
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.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 packet as MIH protocol. I have gone >> through the standard and I did not get any answer. For now I have directly >> taken it as 4551(as specified by IANA), is it right? > > Yes, using the IANA assignment certainly seems correct. > > RFC 5677 lists this IANA assignment too: > > http://tools.ietf.org/html/rfc5677#section-9 > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 one TCP packet. There are
5 calls to the get_pdu_len
> function and four calls to the dissect_pdu function. Since there is not enough
data in the current
> tvbuff_t, tcp_dissect_pdus returns. When dissect_message is called again, the
beginning of the
> message is lost. When get_pdu_len gets called again it reads a garbage size.
>
> Per https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectReassemble.html,
I thought that
> tcp_dissect_pdus is supposed to handle this. I can't find example code in any
dissector in
> /epan/dissectors/* that handles this unlike I am. Am I missing something?
>
> This is part of my code:
>
> void dissect_message(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
> {
> if(pinfo->tcp_tree != NULL) {
> tcp_dissect_pdus(tvb, pinfo, tree, TRUE, MESSAGE_HEADER_SIZE,
> get_message_tcpmessage_len,
dissect_message_tcpmessage);
> }
> else {
> // For UDP just print the data for now.
> call_dissector(data_handle, tvb, pinfo, tree);
> }
> }
>
> guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
> offset)
> {
> if(tvb_length_remaining(tvb, offset) <= 8)
> return 0;
>
> gint32 size = tvb_get_letohl(tvb, offset)+MESSAGE_HEADER_SIZE;
> gint32 type = tvb_get_letohl(tvb, offset+4);
> printf("Len: %u type %d\n", size, type);
> if(strcmp(typeAsString(type), "Unknown") == 0)
> {
> return tvb_length_remaining(tvb, offset);
> }
> return size;
> }
I don't think your get_message_tcpmessage_len() function is coded correctly. It
looks like you're trying to do some heuristics in there when all you really
should be doing is returning the length of your PDU. In your case, it looks
like the length field is the 1st 4-bytes of the header, so I think you should
probably just be doing something like this:
if(pinfo->tcp_tree != NULL) {
tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4, get_message_tcpmessage_len,
dissect_message_tcpmessage);
}
(NOTE: Here, you could use MESSAGE_HEADER_SIZE instead of 4, but you really only
need the 1st 4 bytes to determine the length of the entire PDU.)
guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int offset)
{
return tvb_get_letohl(tvb, offset) + MESSAGE_HEADER_SIZE;
}
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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
>> is not complete. Specifically, I have 5 messages in one TCP packet. There are
> 5 calls to the get_pdu_len
>> function and four calls to the dissect_pdu function. Since there is not
>> enough
> data in the current
>> tvbuff_t, tcp_dissect_pdus returns. When dissect_message is called again, the
> beginning of the
>> message is lost. When get_pdu_len gets called again it reads a garbage size.
>>
>> Per
>> https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectReassemble.html,
> I thought that
>> tcp_dissect_pdus is supposed to handle this. I can't find example code in any
> dissector in
>> /epan/dissectors/* that handles this unlike I am. Am I missing something?
>>
>> This is part of my code:
>>
>> void dissect_message(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
>> {
>> if(pinfo->tcp_tree != NULL) {
>> tcp_dissect_pdus(tvb, pinfo, tree, TRUE, MESSAGE_HEADER_SIZE,
>> get_message_tcpmessage_len,
> dissect_message_tcpmessage);
>> }
>> else {
>> // For UDP just print the data for now.
>> call_dissector(data_handle, tvb, pinfo, tree);
>> }
>> }
>>
>> guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
>> offset)
>> {
>> if(tvb_length_remaining(tvb, offset) <= 8)
>> return 0;
>>
>> gint32 size = tvb_get_letohl(tvb, offset)+MESSAGE_HEADER_SIZE;
>> gint32 type = tvb_get_letohl(tvb, offset+4);
>> printf("Len: %u type %d\n", size, type);
>> if(strcmp(typeAsString(type), "Unknown") == 0)
>> {
>> return tvb_length_remaining(tvb, offset);
>> }
>> return size;
>> }
> I don't think your get_message_tcpmessage_len() function is coded correctly.
> It
> looks like you're trying to do some heuristics in there when all you really
> should be doing is returning the length of your PDU. In your case, it looks
> like the length field is the 1st 4-bytes of the header, so I think you should
> probably just be doing something like this:
>
> if(pinfo->tcp_tree != NULL) {
> tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4,
> get_message_tcpmessage_len,
> dissect_message_tcpmessage);
> }
>
> (NOTE: Here, you could use MESSAGE_HEADER_SIZE instead of 4, but you really
> only
> need the 1st 4 bytes to determine the length of the entire PDU.)
>
> guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
> offset)
> {
> return tvb_get_letohl(tvb, offset) + MESSAGE_HEADER_SIZE;
> }
>
>
>
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.
--
Regards,
Graham Bloice
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 needed via the fixed_len argument, so it won't call get_message_tcpmessage_len() until at least that many bytes are available. See packet-tcp.c's tcp_dissect_pdus() where it checks for "if (length_remaining < fixed_len)". ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 as tcp_dissect_pdus() is told how many bytes are > needed via the fixed_len argument, so it won't call > get_message_tcpmessage_len() > until at least that many bytes are available. > > See packet-tcp.c's tcp_dissect_pdus() where it checks for "if > (length_remaining > < fixed_len)". > I knew I should have looked at the code and not spouted forth from memory, Chris is right. I was thinking of some similar code that does some heuristic checks before calling tcp_dissct_pdus(). -- Regards, Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] MIH protocol dissector
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 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.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 packet as MIH protocol. I have gone through the standard and I did not get any answer. For now I have directly taken it as 4551(as specified by IANA), is it right? Yes, using the IANA assignment certainly seems correct. RFC 5677 lists this IANA assignment too: http://tools.ietf.org/html/rfc5677#section-9 ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 offset)
{
guint remaining = tvb_length_remaining(tvb, offset);
guint last_size = tvb_get_letohl(tvb, offset)+MESSAGE_HEADER_SIZE;
if(last_size > remaining)
{
printf("not enough data: %d remaining: %d\n", last_size,
remaining);
}
return last_size;
}
I get the following output in consecutive packets from host A to host B:
not enough data: 322 remaining: 144
not enough data: 445080968 remaining: 1448
There are no 445080968 byte messages being sent, ever. It is that the dissector
called by tcp_dissect_pdus gets a partial message. Clearly, it is not buffering
the packets correctly. I *could* hack it together but I thought this is part of
what tcp_dissect_pdus was supposed to do.
BTW - I am using and compiling against 1.4.6.
Thank you for your responses,
Rafael
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Chris Maynard
Sent: Thursday, May 05, 2011 10:00 AM
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
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 one TCP packet. There are
5 calls to the get_pdu_len
> function and four calls to the dissect_pdu function. Since there is not enough
data in the current
> tvbuff_t, tcp_dissect_pdus returns. When dissect_message is called again, the
beginning of the
> message is lost. When get_pdu_len gets called again it reads a garbage size.
>
> Per https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectReassemble.html,
I thought that
> tcp_dissect_pdus is supposed to handle this. I can't find example code in any
dissector in
> /epan/dissectors/* that handles this unlike I am. Am I missing something?
>
> This is part of my code:
>
> void dissect_message(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
> {
> if(pinfo->tcp_tree != NULL) {
> tcp_dissect_pdus(tvb, pinfo, tree, TRUE, MESSAGE_HEADER_SIZE,
> get_message_tcpmessage_len,
dissect_message_tcpmessage);
> }
> else {
> // For UDP just print the data for now.
> call_dissector(data_handle, tvb, pinfo, tree);
> }
> }
>
> guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int
> offset)
> {
> if(tvb_length_remaining(tvb, offset) <= 8)
> return 0;
>
> gint32 size = tvb_get_letohl(tvb, offset)+MESSAGE_HEADER_SIZE;
> gint32 type = tvb_get_letohl(tvb, offset+4);
> printf("Len: %u type %d\n", size, type);
> if(strcmp(typeAsString(type), "Unknown") == 0)
> {
> return tvb_length_remaining(tvb, offset);
> }
> return size;
> }
I don't think your get_message_tcpmessage_len() function is coded correctly. It
looks like you're trying to do some heuristics in there when all you really
should be doing is returning the length of your PDU. In your case, it looks
like the length field is the 1st 4-bytes of the header, so I think you should
probably just be doing something like this:
if(pinfo->tcp_tree != NULL) {
tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4, get_message_tcpmessage_len,
dissect_message_tcpmessage);
}
(NOTE: Here, you could use MESSAGE_HEADER_SIZE instead of 4, but you really only
need the 1st 4 bytes to determine the length of the entire PDU.)
guint get_message_tcpmessage_len(packet_info *pinfo, tvbuff_t *tvb, int offset)
{
return tvb_get_letohl(tvb, offset) + MESSAGE_HEADER_SIZE;
}
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
CONFIDENTIALITY AND SECURITY NOTICE
The contents of this message and any attachments may be confidential and
proprietary and also may be covered by the Electronic Communications Privacy
Act. This message is not intended to be used by, and should not be relied upon
in any way, by any third party. If you are not an intended recipient, please
inform the sender of the transmission error and delete this message immediately
without reading, disseminating, distributing or copying the contents. Ci
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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_HEADER_SIZE;
> if(last_size > remaining)
> {
> printf("not enough data: %d remaining: %d\n", last_size,
remaining);
> }
> return last_size;
> }
>
This is still wrong. You shouldn't be trying to figure out if you've got enough
data; tcp_dissect_pdus() will handle all that for you. This function only needs
to return the length of the entire PDU so tcp_dissect_pdus() knows how much data
it needs to reassemble before calling your dissector. Try changing the function
to something like what I posted earlier.
You might also re-read section 2.7.1 of doc/README.developer, as it could help
you in the case of UDP. And take a look at other examples in the Wireshark
codebase, such as packet-dns.c which doc/README.developer references in its
example.
And stop using printf(). If you need to, try using g_warning() instead.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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:
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->desegment_offset and pinfo->desegment_len. tcp_dissect_pdus
returns.
In my_dissector.c:
1. Once tcp_dissect_pdus returns, dissect_message returns.
2. dissect_message gets called soon after and calls tcp_dissect_pdus again.
In packet-tcp.c-tcp_dissect_pdus:
Line 1993: get_pdu_len gets called again. It read 4 bytes starting from the
178th (322-144) byte of the application message. Thus, it returns a garbage
size.
Don't you think there is an issue with this?
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Chris Maynard
Sent: Thursday, May 05, 2011 11:27 AM
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
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_HEADER_SIZE;
> if(last_size > remaining)
> {
> printf("not enough data: %d remaining: %d\n", last_size,
remaining);
> }
> return last_size;
> }
>
This is still wrong. You shouldn't be trying to figure out if you've got enough
data; tcp_dissect_pdus() will handle all that for you. This function only needs
to return the length of the entire PDU so tcp_dissect_pdus() knows how much data
it needs to reassemble before calling your dissector. Try changing the function
to something like what I posted earlier.
You might also re-read section 2.7.1 of doc/README.developer, as it could help
you in the case of UDP. And take a look at other examples in the Wireshark
codebase, such as packet-dns.c which doc/README.developer references in its
example.
And stop using printf(). If you need to, try using g_warning() instead.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
CONFIDENTIALITY AND SECURITY NOTICE
The contents of this message and any attachments may be confidential and
proprietary and also may be covered by the Electronic Communications Privacy
Act. This message is not intended to be used by, and should not be relied upon
in any way, by any third party. If you are not an intended recipient, please
inform the sender of the transmission error and delete this message immediately
without reading, disseminating, distributing or copying the contents. Citadel
makes no assurances that this e-mail and any attachments are free of viruses
and other harmful code.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] IPv6 longest representation vs INET6_ADDRSTRLEN
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 inet_ntop() implementation don't generate short addresses? ( > instead of ::) > so ipv4 mapped address would be: > "::::::255.255.255.255" > > I think I'll just copy inet_ntop6() from wsutil/inet_ntop.c to > address_to_str.c... RFC 2553 section 6.6 and MSDN's InetNtop documentation both specify 46 characters, but you'd think that if an implementation was smart enough to check for v4-mapped addresses it would be smart enough to compress zeroes. -- Join us for Sharkfest ’11! · Wireshark® Developer and User Conference Stanford University, June 13-16 · http://sharkfest.wireshark.org ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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_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;
> if(last_size > remaining)
> {
> printf("not enough data: %d remaining: %d\n", last_size,
> remaining);
> }
> return last_size;
> }
>
> I get the following output in consecutive packets from host A to host B:
>
> not enough data: 322 remaining: 144
> not enough data: 445080968 remaining: 1448
>
> There are no 445080968 byte messages being sent, ever. It is that the
> dissector called by tcp_dissect_pdus gets a partial message. Clearly, it is
> not buffering the packets correctly. I *could* hack it together but I thought
> this is part of what tcp_dissect_pdus was supposed to do.
> BTW - I am using and compiling against 1.4.6.
>
> Thank you for your responses,
> Rafael
>
The types you are using to hold "remaining" and "last_size" might be an issue,
tvb_length_remaining() returns a gint and tvb_get_letohl() returns a guint32.
--
Regards,
Graham Bloice
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Wireshark 1.5.1: Export SMB Objects
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 freely available. http://www.taddong.com/docs/WP_SMBPlugin.pdf The white paper describes the plug-in they have created, the identifying of the SMB streams and gives an explanation of the columns in the "Wireshark: Export SMB object list" Best regards, Joke ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 removing the "if(pinfo->tcp_tree != NULL)" check?
if(pinfo->tcp_tree != NULL) {
tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4, get_message_tcpmessage_len,
dissect_message_tcpmessage);
}
If that helps, then you should look into structuring your code like the dns
dissector does, with separate dissect_message_tcp() and dissect_message_udp()
functions.
If that doesn't help, then you might try compiling your code against the latest
development trunk as I believe there have been some changes made recently
concerning reassembly that might help you.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] network byte order
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 ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] network byte order
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 macros, ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] network byte order
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 other protocols that use little-endian values as well. > I am trying to dissect a packet that uses Little-Endian. Not a problem. Either 1) you're fetching values from the packet, and thus converting them from whatever byte order it's in to *host* byte order, in which case: for big-endian integral values, you use tvb_get_ntohs() for 2-byte values, tvb_get_ntoh24() for 3-byte values, tvb_get_ntohl() for 4-byte values, tvb_get_ntoh40() for 5-byte values, tvb_get_ntoh48() for 6-byte values, tvb_get_ntoh56() for 7-byte values, and tvb_get_ntoh64() for 8-byte values; for big-endian IEEE floating-point values, you use tvb_get_ntohieee_float() for single precision and tvb_get_ntohieee_double() for double-precision; for little-endian integral values, you use tvb_get_letohs() for 2-byte values, tvb_get_letoh24() for 3-byte values, tvb_get_letohl() for 4-byte values, tvb_get_letoh40() for 5-byte values, tvb_get_letoh48() for 6-byte values, tvb_get_letoh56() for 7-byte values, and tvb_get_letoh64() for 8-byte values; for little-endian IEEE floating-point values, you use tvb_get_letohieee_float() for single precision and tvb_get_letohieee_double() for double-precision; or 2) you're just using proto_tree_add_item(), in which case for big-endian values you pass ENC_BIG_ENDIAN as the last argument and for little-endian values you pass ENC_LITTLE_ENDIAN as the last argument. > Before I write my own "bit decoder"...is there any built in functions that > will "convert" Little-Endian to Big-Endian for me..?? No, because that's not what you want to do. You want either to fetch data and convert it to *host* byte order if you're going to look at the value in your code (for example, a message type value, which you need in order to determine the format of the rest of the message) or just use proto_tree_add_item() if you're just adding the value to the protocol tree. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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, May 05, 2011 1:26 PM
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
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 removing the "if(pinfo->tcp_tree != NULL)" check?
if(pinfo->tcp_tree != NULL) {
tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4, get_message_tcpmessage_len,
dissect_message_tcpmessage);
}
If that helps, then you should look into structuring your code like the dns
dissector does, with separate dissect_message_tcp() and dissect_message_udp()
functions.
If that doesn't help, then you might try compiling your code against the latest
development trunk as I believe there have been some changes made recently
concerning reassembly that might help you.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
CONFIDENTIALITY AND SECURITY NOTICE
The contents of this message and any attachments may be confidential and
proprietary and also may be covered by the Electronic Communications Privacy
Act. This message is not intended to be used by, and should not be relied upon
in any way, by any third party. If you are not an intended recipient, please
inform the sender of the transmission error and delete this message immediately
without reading, disseminating, distributing or copying the contents. Citadel
makes no assurances that this e-mail and any attachments are free of viruses
and other harmful code.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 protocol:
all messages start with a fixed-length header MESSAGE_HEADER_SIZE bytes
long, and may have zero or more bytes after that header;
the first 4 bytes of a message (i.e., the first 4 bytes of the header)
are a little-endian value that is the length of the part of the message after
the fixed-length header?
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 support list for Wireshark
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
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 protocol:
all messages start with a fixed-length header MESSAGE_HEADER_SIZE bytes
long, and may have zero or more bytes after that header;
the first 4 bytes of a message (i.e., the first 4 bytes of the header)
are a little-endian value that is the length of the part of the message after
the fixed-length header?
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
CONFIDENTIALITY AND SECURITY NOTICE
The contents of this message and any attachments may be confidential and
proprietary and also may be covered by the Electronic Communications Privacy
Act. This message is not intended to be used by, and should not be relied upon
in any way, by any third party. If you are not an intended recipient, please
inform the sender of the transmission error and delete this message immediately
without reading, disseminating, distributing or copying the contents. Citadel
makes no assurances that this e-mail and any attachments are free of viruses
and other harmful code.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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->desegment_offset and pinfo->desegment_len. tcp_dissect_pdus > returns. ...meaning that the TCP segment handed to tcp_dissect_pdus() didn't have a complete message, so there's nothing more for it to do at that point. > In my_dissector.c: > 1. Once tcp_dissect_pdus returns, dissect_message returns. > 2. dissect_message gets called soon after and calls tcp_dissect_pdus again. ...when the next segment is available. dissect_message() should, at that point, have been handed to it by the TCP dissector a reassembled tvbuff containing: the 144 bytes from the TCP segment that was handed to it in the previous call; following it, up to 178 bytes of additional data from the next segment; in which case... > In packet-tcp.c-tcp_dissect_pdus: > Line 1993: get_pdu_len gets called again. It read 4 bytes starting from the > 178th (322-144) byte of the application message. Thus, it returns a garbage > size. ...get_pdu_len() should be handed the reassembled tvbuff in question, with an offset argument of 0, so it should be reading the same 4 bytes that it did on the first call, *not* the first 4 bytes of the second segment. dissect_message() is the dissector you registered with TCP as the dissector for your protocol, right? > Don't you think there is an issue with this? There's an issue with *something*, but, given that tcp_dissect_pdus() has worked and continues to work fine for a number of other protocols, it's not a simple or obvious issue. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 proto_tree argument is null, Wireshark does not need to use
the protocol tree information from your dissector, and therefore is
passing the dissector a null "tree" argument so that it doesn't
need to do work necessary to build the protocol tree.
In the interest of speed, if "tree" is NULL, avoid building a
protocol tree and adding stuff to it, or even looking at any packet
data needed only if you're building the protocol tree, if possible.
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. ...
> Can you try removing the "if(pinfo->tcp_tree != NULL)" check?
>
> if(pinfo->tcp_tree != NULL) {
> tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4,
> get_message_tcpmessage_len,
> dissect_message_tcpmessage);
> }
So again, can you try this?
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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., there is *no* guarantee that, for all calls to the dissector for a TCP
segment, pinfo->tcp_tree will be non-null.
If, for example, that's not the case in the first pass through the packets,
when the capture file is being read, the behavior of TCP reassembly of the
protocol will be incorrect, because the reassembly depends on *every* segment
being handed to the dissector in order.
What should be done is:
void dissect_for_tcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
tcp_dissect_pdus(tvb, pinfo, tree, TRUE, MESSAGE_HEADER_SIZE,
get_message_tcpmessage_len,
dissect_message_tcpmessage);
}
and register that as the dissector for TCP and *ONLY* TCP, and have a separate
dissector for UDP, and register that for UDP.
The two dissectors can possibly share common code; when running over UDP, is
the one message per UDP datagram, with the messages looking exactly like the
TCP messages?
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 ways - with, or
>without a non-null "tree" argument.
(Not directly applicable to the original question, but...)
Hmm. I note from observation while working with capture files that the
current behaviour is slightly more complicated:
1) There is an initial scan through the complete file with tree==NULL
and columns disabled. Presumably to efficiently let all involved
dissectors construct a view of entire conversations without UI
slowdowns.
2) There is a second scan through with tree==NULL with column info
enabled. This is presumably to allow wireshark to give the appearance
of nice responsive building of the packet list without the initial
dissection work slowing down the UI work. (At least for dissectors
that cache the work done and reuse when pinfo.visited is true.)
3) As and when a single packet in the packet list is selected, a third
call with tree!=NULL is made on that single packet to populate the
tree pane.
(I think 2 was a complete scan, though ISTR there may have been
additional scans later on for subsets as the packet list is scrolled.
Not completely confident on that.)
I suspect this is for files only: the distinction between (1) and (2)
making less sense for live captures, and obviously it not being
possible to visit everything before it's been captured!
Another point is that tvbs from lower-level dissectors get thrown away
between 1 and 2, and 2 and 3, (possibly between individual calls
during 1 or 2, but I don't think I saw that) so a nested dissector
never sees the "same data" twice, can't cache subset/composite tvbs
for later use, etc. (which would be a very useful property sometimes -
this area has come up a few times recently in discussions on
composites and _FROM_FILE handling.)
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 documentation ought to be
expanded to mention it.
>If the proto_tree argument is null, Wireshark does not need to use
>the protocol tree information from your dissector, and therefore is
>passing the dissector a null "tree" argument so that it doesn't
>need to do work necessary to build the protocol tree.
>In the interest of speed, if "tree" is NULL, avoid building a
>protocol tree and adding stuff to it, or even looking at any packet
>data needed only if you're building the protocol tree, if possible.
>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. ...
>> Can you try removing the "if(pinfo->tcp_tree != NULL)" check?
>>
>> if(pinfo->tcp_tree != NULL) {
>> tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4,
>> get_message_tcpmessage_len,
>> dissect_message_tcpmessage);
>> }
> So again, can you try this?
> ___
> Sent via:Wireshark-dev mailing list
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
John
--
Dead stars still burn
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 problem starts occurring
until the end of the capture file.
I now register a different dissector for UDP and TCP.
Nonetheless, This is my current code:
void dissect_tcp_message(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
tcp_dissect_pdus(tvb, pinfo, tree, TRUE, 4,
get_tcp_message_len,
dissect_tcp_message);
}
void dissect_tcp_message(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
if (check_col(pinfo->cinfo, COL_PROTOCOL))
col_set_str(pinfo->cinfo, COL_PROTOCOL, "MyMessage");
gint32 length, type, legacy;
if(tvb_bytes_exist(tvb, 0, MESSAGE_HEADER_SIZE))
{
length = tvb_get_letohl(tvb, 0);
type = tvb_get_letohl(tvb, 4);
legacy = tvb_get_letohl(tvb, 8);
}
else
{
call_dissector(data_handle, tvb, pinfo, tree);
return;
}
if (check_col(pinfo->cinfo, COL_INFO))
{
col_add_fstr(pinfo->cinfo, COL_INFO, "[%s] ",
typeAsString(type));
col_set_fence(pinfo->cinfo, COL_INFO);
}
if(!tree)
{
return;
}
proto_item *base_item, *header_item, *body_item;
proto_tree *base_tree, *header_tree;
base_item = header_item = body_item = NULL;
base_tree = header_tree = NULL;
base_item = proto_tree_add_item(tree, proto_mymessage, tvb, 0, -1,
FALSE);
base_tree = proto_item_add_subtree(base_item, ett_mymessage);
header_tree = proto_item_add_subtree(base_item, ett_mymessage);
header_item = proto_tree_add_item(base_tree, hf_header, tvb, 0,
MESSAGE_HEADER_SIZE, FALSE);
body_item = proto_tree_add_item(base_tree, hf_body, tvb,
MESSAGE_HEADER_SIZE, -1, FALSE);
header_tree = proto_item_add_subtree(header_item, ett_mymessage);
proto_tree_add_int(header_tree, hf_header_length, tvb, 0, 4, length);
proto_tree_add_string_format_value(header_tree, hf_header_type, tvb, 4,
4, "", "%s [%d]",
typeAsString(type),
type);
proto_tree_add_int(header_tree, hf_header_seq, tvb, 8, 4, legacy);
}
guint get_tcp_message_len(packet_info *pinfo, tvbuff_t *tvb, int offset)
{
return tvb_get_letohl(tvb, offset)+MESSAGE_HEADER_SIZE;
}
-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:59 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] TCP dissect issue when app-level message spans
multiple TCP packets
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->desegment_offset and pinfo->desegment_len. tcp_dissect_pdus
> returns.
...meaning that the TCP segment handed to tcp_dissect_pdus() didn't have a
complete message, so there's nothing more for it to do at that point.
> In my_dissector.c:
> 1. Once tcp_dissect_pdus returns, dissect_message returns.
> 2. dissect_message gets called soon after and calls tcp_dissect_pdus again.
...when the next segment is available.
dissect_message() should, at that point, have been handed to it by the TCP
dissector a reassembled tvbuff containing:
the 144 bytes from the TCP segment that was handed to it in the
previous call;
following it, up to 178 bytes of additional data from the next segment;
in which case...
> In packet-tcp.c-tcp_dissect_pdus:
> Line 1993: get_pdu_len gets called again. It read 4 bytes starting from the
> 178th (322-144) byte of the application message. Thus, it returns a garbage
> size.
...get_pdu_len() should be handed the reassembled tvbuff in question, with an
offset argument of 0, so it should be reading the same 4 bytes that it did on
the first call, *not* the first 4 bytes of the second segment.
dissect_message() is the dissector you registered with TCP as the dissector for
your protocol, right?
> Don't you think there is an issue with this?
There's an issue with *something*, but, given that tcp_dissect_pdus() has
worked and continues to work fine for a number of other protocols, it's not a
simple or obvious issue.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wiresha
[Wireshark-dev] buildbot failure in Wireshark (development) on OSX-10.5-x86
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: Build Source Stamp: 37000 Blamelist: darkjames,morriss BUILD FAILED: failed compile sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark (development) on OSX-10.6-x64
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: Build Source Stamp: 37000 Blamelist: darkjames,morriss BUILD FAILED: failed compile sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 it is also where the problem starts occurring until the end of the capture file. Oh, those out-of-order packets are quite possibly the problem: see the recent discussion here on "Handling TCP packets reordering". ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 documentation ought to be > expanded to mention it. Actually, what dissector writers need to know is "do not make any assumptions whatsoever about whether the tree argument will be null or not on any pass through the packets, as it's subject to change from release to release, from user configuration to user configuration, and from program to program (dissectors currently run in Wireshark *and* TShark)". ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
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 ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark (development) on OSX-10.5-PowerPC
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 Reason: Build Source Stamp: 37000 Blamelist: darkjames,morriss BUILD FAILED: failed compile sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark (development) on Visual-Studio-Code-Analysis
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-code-analysis Build Reason: Build Source Stamp: 37003 Blamelist: morriss BUILD FAILED: failed nmake all sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark (development) on Windows-7-x64
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: Build Source Stamp: 37003 Blamelist: morriss BUILD FAILED: failed nmake all sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
