On Thursday 24 April 2014 16:41:02 [email protected] wrote: > After looking at this, I'd have to say the DTLS decryption test is > "flawed". It sets up a key to decifer traffic as HTTP, but it's not really > HTTP, it's just a bunch of ASCII strings. I can change it to any of the > valid dissectors and presuming the DTLS decyption is done correctly (which > I presume is the real point of this test), that protocol will attempt to be > dissected in the subsequent frames (and be caught by that protocol's > filter). > > Ideas on the best way to fix this so I can restore removing the "bogus" HTTP > tree when it's not really HTTP?
The Wireshark GUI has some panels for data sources on the bottom which shows "Frame" and "Decrypted DTLS data". If something like "dtls.data.data" and/or "dtls.data.str" (or something generic for all data sources) would be added, then that would solve this problem. Though I don't know how feasible this is, in terms of memory and CPU. Kind regards, Peter ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
