Re: GTP session plugin

[Pascal Quantin <pascal.quantin () gmail com>]

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

> 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 () gmail com]
> 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 () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe