https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6189
apohal9@xxxxxxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|Low |Medium
Status|RESOLVED |REOPENED
Version|1.0.15 |1.6.1
Resolution|WONTFIX |
--- Comment #5 from apohal9@xxxxxxxxxxxxxx 2011-08-02 03:38:57 PDT ---
We tested with 1.6.1 again. The problem is the same.
As a background information: We need to replay decrypted ssl/tls traffic and
because of replaying decrypted raw data is not supported, we try to use the way
of redireting decrypted data in hex-format to a text file. We then use this hex
dump, text2pcap it and replay it with tshark/ tcpreplay.
The decrypted data goes to the text file perfectly. See ssl_01.txt as an
example.
The command line for this capture was: /usr/local/bin/tshark -o "ssl.keys_list:
0.0.0.0,443,http,/root/staff/serverkey.key" -i eth1 -n port 443 -V -R http -x
-o ssl.debug_file:"/root/staff/debug.log" > /root/staff/decrypt7.txt
As expected we can see plain html in the dump.
Converting hex-dump to pcap. text2pcap output is in ssl_02.txt.
The command line was: /usr/local/bin/text2pcap /root/staff/decrypt7.txt
/root/staff/decrypt7.pcap
And here something goes wrong.
As an example, see ssl_03.txt.
Why does text2pcap generate malformed ethernet frames?! See "[Protocols in
frame: eth:data]". The hex dump always has "[Protocols in frame:
eth:ip:tcp:ssl:http:http:http:data:data:data:data:data:data:data-text-lines]".
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.