Yes the UDP packets are presumably OpenVPN packets which contain the RTP/SIP/SDP information embedded within. Decryption on the OpenVPN is currently not enabled to aid in debug. I understand that OpenVPN is suppose to provide additional privacy and security and that me trying to view the packets as the actual RTP/SIP and SDP traffic defeats part of the whole purpose of OpenVPN, however there are issues with our software that seem only to occur within the VPN tunnel or are more pronounced through OpenVPN so it is a necessary evil to try to tear OpenVPN packets apart for debug purposes.
I will be trying Guy Harris' suggestion later on today and hopefully that will be of help.
Bill
"Kukosa, Tomas" <tomas.kukosa@xxxxxxxxxxx> wrote:
I am affraid those UDP packets are OpenVPN
packet, are not?
I.e. it would be necessary to implement OpenVPN (as I know it is not
implemented) and its decryption.
-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: Tuesday, December 05, 2006 9:33 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] openvpn and packet sniffing
Bill Fassler wrote:
> Sorry I should have provided a better info. Anyway I do get a capture
> and I see only UDP traffic. I am sure the RTP and SIP traffic is
within
> those packets.
I.e., this is "the packets *are* in the capture but aren't recognized by
Wireshark as RTP packets" case.
> I thought of a perl script to possibly parse out what I
> want to see or writing another plugin, that gets to the RTP and then
> passes it off to the appropriate dissector.
All such a
plugin would do is detect RTP traffic and cause it to be
dissected as RTP; the way to do *that* is to have the RTP dissector do
that - which is what the "try turning the 'try to decode RTP outside of
conversations preference for RTP on" suggestion was for. If a plugin
could do a better job of detecting RTP traffic than the current RTP
dissector's heuristic, it shouldn't be done as a plugin dissector, it
should be done as a change to the RTP dissector. (If the heuristics are
strong enough - i.e., they won't identify a lot of non-RTP traffic as
being RTP - they could be turned on by default.)
> In any event, I don't want
> to reinvent the wheel and I'm sure someone has already jumped this
> hurdle. I will try your "decode as" suggestion. I think this might
let
> me more easily see what I want although it soudns a little cumbersome.
Why not try the other
suggestion?
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users
Want to start your own business? Learn how on
Yahoo! Small Business.