Guy Harris | 2 Mar 2009 00:31
Picon
Favicon

Re: Splitting packet_info struct for performance reasons?


On Mar 1, 2009, at 12:45 PM, Kaul wrote:

> I was astounded with the huge size of packet_info structure. I  
> believe in 99% of the cases, there is no need for many of the fields  
> within the structure. Wouldn't it make sense, for performance  
> reasons, to leave the most usable ones within it, and create a  
> pointer to an extra structure with the other, less commonly used  
> stuff. I'm pretty sure it'll save memory and probably improve  
> performance, but would require some changes and complicate a bit the  
> programming. Thoughts?

packet_info has become the grab bag of packet information in Wireshark  
(heck, that dates back to when it was still called Ethereal).

There are several issues here:

	1) we do most columns in the packet list by saving the binary  
information and formatting it only when we add the packet to the list  
(to avoid formatting strings in one dissector only to replace that  
string in a higher-layer dissector - that actually did save some CPU  
time);

	2) we use packet_info to handle "dissect as", so that the GUI can  
determine to which flow (at a given protocol layer) the packet belongs;

	3) we might also use this as a way to pass information between  
dissectors, e.g. addresses and ports.

The column handling needs some rethinking, given that:
(Continue reading)

Kaul | 1 Mar 2009 21:45
Picon

Splitting packet_info struct for performance reasons?

I was astounded with the huge size of packet_info structure. I believe in 99% of the cases, there is no need for many of the fields within the structure. Wouldn't it make sense, for performance reasons, to leave the most usable ones within it, and create a pointer to an extra structure with the other, less commonly used stuff. I'm pretty sure it'll save memory and probably improve performance, but would require some changes and complicate a bit the programming. Thoughts?

Semi-random examples:
guint16 src_idx;              /* Source port index (Cisco MDS-specific) */
  guint16 dst_idx;              /* Dest port index (Cisco MDS-specific) */
  guint16 vsan;                 /* Fibre channel/Cisco MDS-specific */

(how many of us need the above?)

  guint16 link_number;
  guint8  annex_a_used;
  guint16 profinet_type;     /* the type of PROFINET packet (0: not a PROFINET packet) */

(It it even 16bit aligned?!)

/* Extra data for DCERPC handling and tracking of context ids */
  guint16 dcectxid;             /* Context ID (DCERPC-specific) */
  int     dcetransporttype;     /* Transport type
                                 * Value -1 means "not a DCERPC packet"
                                 */
  guint16 dcetransportsalt;    /* fid: if transporttype==DCE_CN_TRANSPORT_SMBPIPE */

(can't it reside in its own struct?, again, is it aligned on some boundaries?)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
王睿思 | 2 Mar 2009 09:46
Picon

What kind of L7 protocols are dissected based on content identification?

Hello:
    I have reading the source code for days, and still I can't
distinguish the L7 protocols between the port identified and content
identified.
   for example: supposing an  packet used the protocols:
"IP-TCP-RTSP",  but when dissect how can the dissect_tcp() find its
subdissector is dissect_rtsp(), did it's based port identification or
content identification?
  Besides, is there any method to know the data type in the
application layer?(e.g. if we could find the payload of RTSP is audio
or video and so on)
Some one could, please, tell me ?

Best regards,

 Kathryn
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev <at> wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request <at> wireshark.org?subject=unsubscribe
Marc Lebas | 2 Mar 2009 10:27
Favicon

Re: decoding depth & capture format

Hello Jeff,

Enclosed is a small capture file (99 records, 27Kb). 
i can provide you with a bigger file if this excerpt does not contain IP frames.

Marc

-----Message d'origine-----
De : wireshark-dev-bounces@...
[mailto:wireshark-dev-bounces <at> wireshark.org] De la part de Jeff Morriss
Envoyé : vendredi 27 février 2009 15:53
À : Developer support list for Wireshark
Objet : Re: [Wireshark-dev] decoding depth & capture format

Marc Lebas wrote:
> Hello,
> Maybe its a User question but that could be a dev issue; anyway there 
> was no answer to my question on the User's mailing list.
> 
> The issue : i got different depth in decoding (GPRS over FR), 
> depending on the capture file format :
> With rf5, the analysis is limited to GPRS protocol layers, but never 
> decode IP which is the encapsulated protocol.
> With libpcap, it is OK; Wireshark go deeper as it is able to decode 
> encapsulated IP frames in GPRS frames.
> Why such a behaviour ? Did i missed something in my config ?
> Here is my config on Linux (but the issue is the same on Windows) :
> - preferences : fr.encap: GPRS Network Service
> - cat k12_protos : "gprs_gb","fr"

Not having ever looked at a GPRS capture in Wireshark, I don't know. 
(Small) sample captures would help.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

Marc Lebas | 2 Mar 2009 10:41
Favicon

Re: decoding depth & capture format

Oups.. Better with enclosure 

-----Message d'origine-----
De : wireshark-dev-bounces@...
[mailto:wireshark-dev-bounces@...] De la part de Lebas,
Marc (CTF:8J00)
Envoyé : lundi 2 mars 2009 10:27
À : Developer support list for Wireshark
Objet : Re: [Wireshark-dev] decoding depth & capture format

Hello Jeff,

Enclosed is a small capture file (99 records, 27Kb). 
i can provide you with a bigger file if this excerpt does not contain IP frames.

Marc

-----Message d'origine-----
De : wireshark-dev-bounces@...
[mailto:wireshark-dev-bounces@...] De la part de Jeff
Morriss Envoyé : vendredi 27 février 2009 15:53 À : Developer support list for Wireshark Objet : Re:
[Wireshark-dev] decoding depth & capture format

Marc Lebas wrote:
> Hello,
> Maybe its a User question but that could be a dev issue; anyway there 
> was no answer to my question on the User's mailing list.
> 
> The issue : i got different depth in decoding (GPRS over FR), 
> depending on the capture file format :
> With rf5, the analysis is limited to GPRS protocol layers, but never 
> decode IP which is the encapsulated protocol.
> With libpcap, it is OK; Wireshark go deeper as it is able to decode 
> encapsulated IP frames in GPRS frames.
> Why such a behaviour ? Did i missed something in my config ?
> Here is my config on Linux (but the issue is the same on Windows) :
> - preferences : fr.encap: GPRS Network Service
> - cat k12_protos : "gprs_gb","fr"

Not having ever looked at a GPRS capture in Wireshark, I don't know. 
(Small) sample captures would help.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Attachment (small.rf5): application/octet-stream, 26 KiB
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe
Jeff Morriss | 2 Mar 2009 17:28
Picon

Re: decoding depth & capture format


I think the problem is that the packets are encrypted:

> FCS: 0x3624af  (incorrect, maybe due to ciphering, calculated 0xb5c834)
[...]
> .... .... .... ..1. = E bit:  encrypted frame

The GPRS-LLC dissector does not hand the payload off to the next 
dissector when this is the case.

I suppose in your other (PCAP) captures the data is not encrypted and/or 
the checksums are correct.

Marc Lebas wrote:
> Hello Jeff,
> 
> Enclosed is a small capture file (99 records, 27Kb). 
> i can provide you with a bigger file if this excerpt does not contain IP frames.
> 
> Marc
> 
> -----Message d'origine-----
> De : wireshark-dev-bounces@...
[mailto:wireshark-dev-bounces <at> wireshark.org] De la part de Jeff Morriss
> Envoyé : vendredi 27 février 2009 15:53
> À : Developer support list for Wireshark
> Objet : Re: [Wireshark-dev] decoding depth & capture format
> 
> 
> 
> Marc Lebas wrote:
>> Hello,
>> Maybe its a User question but that could be a dev issue; anyway there 
>> was no answer to my question on the User's mailing list.
>>
>> The issue : i got different depth in decoding (GPRS over FR), 
>> depending on the capture file format :
>> With rf5, the analysis is limited to GPRS protocol layers, but never 
>> decode IP which is the encapsulated protocol.
>> With libpcap, it is OK; Wireshark go deeper as it is able to decode 
>> encapsulated IP frames in GPRS frames.
>> Why such a behaviour ? Did i missed something in my config ?
>> Here is my config on Linux (but the issue is the same on Windows) :
>> - preferences : fr.encap: GPRS Network Service
>> - cat k12_protos : "gprs_gb","fr"
> 
> Not having ever looked at a GPRS capture in Wireshark, I don't know. 
> (Small) sample captures would help.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

buildbot | 2 Mar 2009 21:40
Favicon

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/1834

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: osx-10.5-x86

Build Reason: 
Build Source Stamp: HEAD
Blamelist: etxrab

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

buildbot | 2 Mar 2009 23:47
Favicon

buildbot failure in Wireshark (development) on Solaris-10-SPARC

The Buildbot has detected a new failure of Solaris-10-SPARC on Wireshark (development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/Solaris-10-SPARC/builds/1217

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: solaris-10-sparc

Build Reason: 
Build Source Stamp: HEAD
Blamelist: etxrab,gerald

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

Guy Harris | 2 Mar 2009 18:55
Picon
Favicon

Re: What kind of L7 protocols are dissected based on content identification?


On Mar 2, 2009, at 12:46 AM, 王睿思 wrote:

>   for example: supposing an  packet used the protocols:
> "IP-TCP-RTSP",  but when dissect how can the dissect_tcp() find its
> subdissector is dissect_rtsp(), did it's based port identification or
> content identification?

It depends on the protocol.  In the case of RTSP, it's done by port  
identification; the RTSP dissector registers with the TCP dissector  
with two port numbers (defaulting to 554 and 8554).

Other dissectors register with various dissectors as "heuristic"  
dissectors; the heuristic dissectors get called, one after another,  
and each of them checks the beginning of the data in the packet to see  
if the packet looks as if it's a packet for their protocol - if it is,  
they dissect the packet and return TRUE, so that none of the other  
heuristic dissectors get called, otherwise they stop looking at the  
packet data and return FALSE.

>  Besides, is there any method to know the data type in the
> application layer?(e.g. if we could find the payload of RTSP is audio
> or video and so on)

That depends on the protocol.  The payload of RTSP is an RTSP message;  
that message might include a Content-Type: header that indicates what  
the payload type for the message being set up is.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev <at> wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request <at> wireshark.org?subject=unsubscribe
יוני תובל | 3 Mar 2009 10:12
Picon

Fwd: dissector question- reasembling packets

hi ,
 
i've implemented a dissector in the development version of wireshark and it worked .
when i placed the dissectors dill's in the release version , the dissector failed .
i've debbuged it , and noticed that he function :  tcp_dissect_pdus behaves differently between both version .
 
i am using dynamic arrays in my messages .
that means that it a bit complicated to fetch the size of the packet from within the data.
therefor i am using the function like this

tcp_dissect_pdus(tvb, pinfo, tree, TRUE, fixed_size_to_ask, get_message_len, dissect_mprest_irondome_grds_interface);

and each time i get a maximum size packet, i assue that the message is greater then 1460bytes and i set fixed_size_to_ask = 1461 .
in the development version , the next tvb->length i receive is 1460 + "size of the next packet" .
in the release version i receive the actual size i asked for , 1461 .
 
does anyone know why this happens ?
 
 
 
 
thanks
 
yonatan tuval
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

Gmane