Same Issue with Editcap

(No. 0)  No. 1  No. 2  No. 3  No. 4 

This page is another work on data posted in the page before previous.

You only need to download the PCAP file and the SSL-keys file from page.

And, just as I wrote today to Wireshark Mailing List

(

but the email is awaiting moderation, and be admitted or not to the ML:

[[ LINK HERE when it is admitted, or when I resend it without the attachment, in which case the attachment I will make available for downloading on this page ]]

For a while, the attachment was, I think, actually available from:
Filtering on (negated) frame.time_relative filters out wrong frame.number

and if other Wireshark ML subscribers got what I did, it was also delivered to subscribers. But apparently later is was removed from the web, which is fine, since I offered this option. So here it is (along with the SSL-keys):

dump_170317_0928_g0n_EDIT-1070.pcap dump_170317_0928_g0n_SSLKEYLOGFILE.txt

(

And then, just as I wrote today to Wireshark Mailing List, try running this command:

$ editcap dump_170317_0928_g0n.pcap  dump_170317_0928_g0n_EDIT-1070.pcap 1070

and then (I'm only reusing the line from my email, and correcting it with adding the SSL-keys option):

$ for i in $(ls -1 dump_170317_0928_g0n_EDIT-*.pcap); do ls -l $i ; \
	tshark -o "ssl.keylog_file: dump_170317_0928_g0n_SSLKEYLOGFILE.txt" -r \
	$i | grep sign_in | grep www-form-urle ; echo "---" ;  done ;
-rw------- 1 miro miro 888512 2017-05-02 14:51 dump_170317_0928_g0n_EDIT-1070.pcap

and if it gets you such a PCAP that you too when you grep it get this:

 1070 33.105854500  192.168.1.4 → 78.26.97.141 HTTP 812 POST /users/sign_in
 HTTP/1.1  (application/x-www-form-urlencoded)
$

(this second part of the output of the command has been manually wrapped)

(also without that correction, you can't get anything anyhow, that your Wireshark be or not with this issue like mine, it's SSL-encrypted...)

then you have the same problem as me.

( Why that POST packet? Because it contains the password, and should have been removed, but... wrong counting there for some reason. Pls. see previous pages of this topic for more... )

Anyway, when you follow the above, I get (I just retried with my current Wireshark 2.2.6):

$ sha256sum dump_170317_0928_g0n_EDIT-1070.pcap dump_170317_0928_g0n_EDIT-1070.pcap.PREV 
0f7119eaa525047b4473ee617a9dea815af073db8c9cb226c9ea7308fa317dbc  dump_170317_0928_g0n_EDIT-1070.pcap
0f7119eaa525047b4473ee617a9dea815af073db8c9cb226c9ea7308fa317dbc  dump_170317_0928_g0n_EDIT-1070.pcap.PREV
$

what I (PREV is for previously) consistently get...

But the issue may be only here, in my Wireshark, in my instance of Gentoo.

Read some more is in the email on Wireshark ML that I linked above.

...And so... I'm still waiting for confirmation of such an issue, or a denial of any such issue, from some Wireshark ML reader... And also from hopefully some kind reader from Gentoo users ML:

Inconsistent behavior in my Gentoo OS instance

( suggestion: the next email that I'm about to send to that thread --so I don't have its address at the time of writing this-- should be clearer to follow )

---

The (current) list of files that you might find useful for this study are listed in:

ls-1-4 (by the way, links have already been given above, this time; and the keys are the same as already posted on the page before previous)

dump_170317_0928_g0n_EDIT-1070.pcap
dump_170317_0928_g0n_SSLKEYLOGFILE.txt

which verify to: ls-1-4.sum signed by: ls-1-4.sum.asc

You might find dump_dLo.sh script from my uncenz program more useful then downloading each file separately.

BTW, it'd be even more work to demonstrate what filters wrong in my Wireshark without these (very clumsy and unpolished --and unfinished, the second one-- sets of scripts):

tshark-streams

tshark-hosts-conv