Wireshark-dev: Re: [Wireshark-dev] GTP session plugin

From: "POZUELO Gloria (BCS/PSD)" <gloria.pozuelo@xxxxxxxx>
Date: Wed, 11 Nov 2015 12:36:57 +0000

Hi,

 

I’ve almost finished the plugin I’m working on, but now I’m trying to improve the performance. I’d like to ask you if there’s a way to know if wireshark has dissected all packets of the pcap file, this way I could avoid to calculate all the necessary things for getting the GTP session every time I sort the pcap, for example. Now, what I’ve done, is that every packet checks if it has a session ID or not, but for that, we have to loop over all the existing sessions and if the pcap is bigger enough, then the performance is not as good as expected. I think that knowing when the first calculus has finished will improve the performance, since we only have to show the corresponding session ID.

 

Thank you very much.

 

Regards.

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Pascal Quantin
Sent: Monday 2 November 2015 17:11
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] GTP session plugin

 

 

 

2015-11-02 17:07 GMT+01:00 POZUELO Gloria (BCS/PSD) <gloria.pozuelo@xxxxxxxx>:

Thank you very much! It worked! I don’t know the utility of the scope parameter, I’ve set it  to NULL, is it correct?

 

Setting it to NULL means that you need to manually free the memory (using wmem_free function) when you are done with it. Other scopes (like packet scope or file scope for example) are freed automatically when the lifetime of the pool expires. The validity of the scope depends where you are putting your code (and you will get an assert if you try to use a memory scope outside of its valid context). See doc/README.wmem for more information.

BR,

Pascal.

 

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Pascal Quantin
Sent: Monday 2 November 2015 16:29
To: Developer support list for Wireshark

Subject: Re: [Wireshark-dev] GTP session plugin

 

 

 

2015-11-02 16:20 GMT+01:00 POZUELO Gloria (BCS/PSD) <gloria.pozuelo@xxxxxxxx>:

Hello!

I would like to ask you about a problem that I encountered while working in this development. I need to get the IP dst from the packet information and convert it to string (char *), but by inspecting the type _address I can see the data pointer, which I thought it would be the memory address of the final IP data, but I've checked if this integer correspond with the IP dst and turned out not to be the expected address. Could you help me with this matter? Is there a better way to get the IP address from pinfo and convert it to string?

Thank you very much in advance,

Regards.

 

Hi Gloria,

you did not indicate us which Wireshark version you are using, but assuming it's a recent one you are probably interested by the address_to_str() function found in epan/to_str.h file.

Best regards,

Pascal.

-----Original Message-----
From: Jeff Morriss [mailto:jeff.morriss.ws@xxxxxxxxx]
Sent: Friday 23 October 2015 20:56
To: Developer support list for Wireshark; POZUELO Gloria (BCS/PSD)
Subject: Re: [Wireshark-dev] GTP session plugin

On 10/22/15 03:43, POZUELO Gloria (BCS/PSD) wrote:
> Hi all,
>
> I get in touch with you, since I would like to develop a new plugin
> for GTP protocol (V1 and V2 versions). This functionality would
> consists of looking for all messages that belongs to the same session.
> For
> instance: you select from 1 to N Create Session Request or Create PDP
> Context and all the information about those sessions will be shown,
> this way you could export those specific packets.

It sounds like what you're describing is similar to what another of other dissectors (like TCP, SCTP, and I think SCCP).  You would basically need to modify the GTP dissector to build up state which includes information about each GTP session (similar to the way the TCP dissector builds up state information about each TCP connection).

I can't really offer any specific advice other than to look at how other dissectors do it.  If you want a starting point, look at the "tcp.stream" field (which uniquely identifies a TCP connection that the TCP dissector has found).  Also you need to be aware that dissectors usually build up this state only on the first pass through the packets (when pinfo->fd->flags.visited is FALSE).


________________________________

**** DISCLAIMER****
http://www.bics.com/maildisclaimer/

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

 


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