That was the intent: packet-rtp.[ch] already had the following added ready for 
this approach a long time back:

struct srtp_info
{
    guint      encryption_algorithm;              /* at present only NULL vs 
non-NULL matter */
    guint      auth_algorithm;                                           /* at 
present only NULL vs non-NULL matter */
    guint      mki_len;                                                         
                 /* number of octets used for the MKI in the RTP payload */
    guint      auth_tag_len;                                               /* 
number of octets used for the Auth Tag in the RTP payload */
#if 0       /* these are only needed once the dissector include the crypto 
functions to decrypt and/or authenticate */
    struct srtp_key_info **master_keys; /* an array of pointers to master keys 
and their info, the array and each key struct being wmem_file_scope'ed  */
    void       *enc_alg_info,                                              /* 
algorithm-dependent info struct - may be void for default alg with default 
params */
    void       *auth_alg_info                                             /* 
algorithm-dependent info struct - void for default alg with default params */
#endif
};

/* Add an SRTP conversation with the given details */
WS_DLL_PUBLIC
void srtp_add_address(packet_info *pinfo,
                     address *addr, int port,
                     int other_port,
                     const gchar *setup_method,
                     guint32 setup_frame_number,
                                                                                
gboolean is_video,
                     rtp_dyn_payload_t *rtp_dyn_payload,
                     struct srtp_info *srtp_info);

There are small differences in packet-rtp handling when SRTP is used, but those 
differences are easy to handle inline.

Regards,
Neil

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
Sent: 30 June 2015 11:41
To: Developer support list for Wireshark
Subject: [!!Mass Mail]Re: [Wireshark-dev] "Wireshark-dev: Re: using pinfo 
structure to save data after first iteration"

Hi,
Isn’t a SRTP packet in essence an RTP packet with encrypted payload? So I don’t 
see why it should be a problem to process the packet in packet-rtp.c
On the first pass.

Tip p_get_proto_data() can be used for per packet data. Are you using the 
development version as there seems to be some basic stuff for SRTP already in 
the dissector.
Regards
Anders

From: 
wireshark-dev-boun...@wireshark.org<mailto:wireshark-dev-boun...@wireshark.org> 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of koundinya poluri
Sent: den 30 juni 2015 11:28
To: wireshark-dev
Subject: [Wireshark-dev] "Wireshark-dev: Re: using pinfo structure to save data 
after first iteration"

Hi, Anders,

I had a similar idea on how it should be done.I wanted to save some srtp 
related data once you processs the packets first time like creating a context 
which carries the ssrc and keys so that it can relate the packets to keys using 
the ssrc.But unfortunately wireshark cant differentiate between a rtp packet 
and srtp packet so it just processes the srtp packet as an rtp packet and 
changes the visited flag to one.

So cant use that flag which is generally used to differentiate the first 
iteration from the next ones.So i tried to put my own flag in the pinfo 
structure and modify it,but that did not work, as it looks like pinfo structure 
is a READ ONLY structure from a dissector's point of view.So how do I 
differentiate between iterations??

Is my understanding correct ?If so what is the solution to my problem?Thanks!

Also I am using UAT for entering keys!

-koundinya
___________________________________________________________________________
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-requ...@wireshark.org?subject=unsubscribe

Reply via email to