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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-users
_______________________________________________
Wireshark-users mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-users
---------------------------------
Want to start your own business? Learn how on Yahoo! Small Business.
_______________________________________________
Wireshark-users mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-users
