bitozoid | 3 Apr 12:06 2012
Picon

Wrong protocol detection - wrong decryption

I'm trying to decrypt a starttls connection via smtp. I have done it
before without any trouble. However, I am having some trouble now.

I have seen that wireshark does not recognise the protocol properly.
It shows TLSv1 (SSL in tshark) when it should be SMTP.

Is this normal?

Thanks

wireshark 1.6.4
gnutls 2.12.18
libgcrypt 1.4.6
openssl 1.0.0h

  8   0.002115 10.141.188.79 -> 10.141.188.73 SSL 104 Continuation Data

0000  00 1e 68 c0 d3 fe 00 0c 29 90 07 25 08 00 45 00   ..h.....)..%..E.
0010  00 5a c8 fa 40 00 40 06 e3 f0 0a 8d bc 4f 0a 8d   .Z.. <at> . <at> ......O..
0020  bc 49 92 dd 00 19 e6 3c 0a 3b 87 f0 61 e3 80 18   .I.....<.;..a...
0030  00 5c 8d ff 00 00 01 01 08 0a 00 3f c2 ce 1d 27   .\.........?...'
0040  56 bf 45 48 4c 4f 20 61 6e 61 78 61 67 6f 72 61   V.EHLO anaxagora
[deleted]

  9   0.002689 10.141.188.73 -> 10.141.188.79 SSL 337 Continuation Data

0000  00 0c 29 90 07 25 00 1e 68 c0 d3 fe 08 00 45 00   ..)..%..h.....E.
0010  01 43 73 f9 40 00 80 06 f8 08 0a 8d bc 49 0a 8d   .Cs. <at> ........I..
0020  bc 4f 00 19 92 dd 87 f0 61 e3 e6 3c 0a 61 80 18   .O......a..<.a..
0030  01 04 ac 41 00 00 01 01 08 0a 1d 27 56 bf 00 3f   ...A.......'V..?
(Continue reading)

bitozoid | 3 Apr 13:35 2012
Picon

Re: Wrong protocol detection - wrong decryption

I have also checked the private key and exported certificate:
$ openssl x509 -in exported_certificate_from_wireshark.der -inform DER
-noout -modulus | openssl md5
(stdin)= 03b659a8802627399f3289b8254e69aa
$ openssl rsa -in /home/bitozoid/server-private.key -inform PEM -noout
-modulus | openssl md5
(stdin)= 03b659a8802627399f3289b8254e69aa

This is another capture. Still having the same problem.
#117 is a [TCP segment of a reassembled PDU].

---------

ssl_association_remove removing TCP 25 - smtp handle 0x1eb9c50
Private key imported: KeyID 6e:1a:a0:7a:e0:0c:73:eb:b7:52:90:df:f4:0e:41:6f:...
ssl_init IPv4 addr '10.141.188.73' (10.141.188.73) port '25' filename
'/home/bitozoid/server-private.key' password(only for p12 file) ''
ssl_init private key file /home/bitozoid/server-private.key successfully loaded.
association_add TCP port 25 protocol smtp handle 0x1eb9c50

dissect_ssl enter frame #110 (first time)
ssl_session_init: initializing ptr 0x7fec8cb40420 size 680
  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
  record: offset = 0, reported_length_remaining = 104

dissect_ssl enter frame #112 (first time)
  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
  record: offset = 0, reported_length_remaining = 38

dissect_ssl enter frame #113 (first time)
(Continue reading)

Barry Constantine | 4 Apr 01:30 2012

Wireless Capture

Hello,

 

Besides AirPcap, are there other ways to capture promiscuously on a wireless network and to capture the WiFi physical layer information?

 

Thank you,

Barry Constantine

 

JDSU Communications Test

Principal Member Technical Staff

301-325-7069

 

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe
Guy Harris | 4 Apr 03:40 2012
Picon

Re: Wireless Capture


On Apr 3, 2012, at 7:30 PM, Barry Constantine wrote:

> Besides AirPcap, are there other ways to capture promiscuously on a wireless network and to capture the
WiFi physical layer information?

Yes:

	1) run Linux;

	2) run *BSD;

	3) run OS X;

	4) if you're stuck running Windows, do your capture with another application, such as Microsoft Network Monitor:

		http://www.microsoft.com/download/en/details.aspx?id=4865

	   if you're running Vista or later and have a Wi-Fi adapter with an NDIS 6 river that supports Native Wi-Fi, or
TamoSoft CommView for Wi-Fi:

		http://www.tamos.com/products/commwifi/

	   if you have a compatible Wi-Fi adapter and supported Windows version:

		http://www.tamos.com/products/commwifi/adapterlist.php

	   and possibly read those files into Wireshark;

	5) if you're stuck running Windows, and it's Vista or later, and want to capture with Wireshark (or WinDump
or any other WinPcap-based application), modify WinPcap so that, on Windows Vista and later, it's an NDIS
6 driver and uses the Native Wi-Fi mechanism (and the monitor mode APIs from libpcap 1.0 and later, which
means upgrading WinDump's underlying libpcap version to 1.0 or later).  (Contribute the changes to the
WinPcap developers if you don't want to continue supporting them yourself.)

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

Kevin Cullimore | 4 Apr 08:30 2012

Re: Wireless Capture

On 4/3/2012 9:40 PM, Guy Harris wrote:
> On Apr 3, 2012, at 7:30 PM, Barry Constantine wrote:
>
>> Besides AirPcap, are there other ways to capture promiscuously on a wireless network and to capture the
WiFi physical layer information?
> Yes:
>
> 	1) run Linux;
>
> 	2) run *BSD;
>
> 	3) run OS X;
>
> 	4) if you're stuck running Windows, do your capture with another application, such as Microsoft Network Monitor:
>
> 		http://www.microsoft.com/download/en/details.aspx?id=4865
It's not clear that this option satisfies the "capture the WiFi physical 
layer information" requirement.
>
> 	if you're running Vista or later and have a Wi-Fi adapter with an NDIS 6 river that supports Native Wi-Fi,
or TamoSoft CommView for Wi-Fi:
>
> 		http://www.tamos.com/products/commwifi/
>
> 	   if you have a compatible Wi-Fi adapter and supported Windows version:
>
> 		http://www.tamos.com/products/commwifi/adapterlist.php
>
> 	   and possibly read those files into Wireshark;
>
> 	5) if you're stuck running Windows, and it's Vista or later, and want to capture with Wireshark (or
WinDump or any other WinPcap-based application), modify WinPcap so that, on Windows Vista and later,
it's an NDIS 6 driver and uses the Native Wi-Fi mechanism (and the monitor mode APIs from libpcap 1.0 and
later, which means upgrading WinDump's underlying libpcap version to 1.0 or later).  (Contribute the
changes to the WinPcap developers if you don't want to continue supporting them yourself.)
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list<wireshark-users@...>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>               mailto:wireshark-users-request@...?subject=unsubscribe
>
>

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

Guy Harris | 4 Apr 08:58 2012
Picon

Re: Wireless Capture


On Apr 4, 2012, at 2:30 AM, Kevin Cullimore wrote:

> On 4/3/2012 9:40 PM, Guy Harris wrote:
>> On Apr 3, 2012, at 7:30 PM, Barry Constantine wrote:
>> 
>>> Besides AirPcap, are there other ways to capture promiscuously on a wireless network and to capture the
WiFi physical layer information?
>> Yes:

	...

>> 	4) if you're stuck running Windows, do your capture with another application, such as Microsoft
Network Monitor:
>> 
>> 		http://www.microsoft.com/download/en/details.aspx?id=4865
> 
> It's not clear that this option satisfies the "capture the WiFi physical layer information" requirement.

Depends on what you mean by "Wi-Fi physical layer information"; it supplies 802.11 headers and at least
some radio information (channel, RSSI, rate).  (See the WiFiMetadata structure in the
Base/wireless.npl NPL file in the set of NPL files for NetMon 3.4.)

However, if the head of Tamosoft is correct, it's not clear that this option satisfies the presumed
"doesn't suck" requirement:

	http://twitter.com/#!/TamoSoft/status/177670392276713472

" <at> firemywires It's not that rosy,unfortunately.NativeWiFi is poorly implemented in most of the
drivers.And you can't capture 40 MHz channels"

	http://twitter.com/#!/TamoSoft/status/182380964125745152

" <at> DevinAkin  <at> Ben_SniffWiFi  <at> firemywires No 40 MHz ch,no FCS info,broken sig.level (Ralink),broken
chan.selection (Intel),invalid HT rate info"

Tamosoft's Commview for Wi-Fi solves this by having its own drivers, rather than relying on the
vendor/Microsoft drivers, with the advantage that they can avoid vendor and/or Microsoft driver writer
suckage and the disadvantage that if you don't have a card for which they have a driver, you lose.

>> 	5) if you're stuck running Windows, and it's Vista or later, and want to capture with Wireshark (or
WinDump or any other WinPcap-based application), modify WinPcap so that, on Windows Vista and later,
it's an NDIS 6 driver and uses the Native Wi-Fi mechanism (and the monitor mode APIs from libpcap 1.0 and
later, which means upgrading WinDump's underlying libpcap version to 1.0 or later).  (Contribute the
changes to the WinPcap developers if you don't want to continue supporting them yourself.)

And that would have the same characteristics as NetMon, given that it'd use the same code path, and hence the
same presumed suckage.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

NITIN GOYAL | 4 Apr 09:46 2012
Picon

Issue with RTT values in Wireshark

Hi All

I have an issue with the Wireshark for calcuating the RTT values. For few pcaps, I have a higher value of RTT on one side or direction but the lower value of RTT on other side. 
I have taken the trace in the middle of the connections and in one direction the RTT calculated by Wireshark is around 40 ms but on what other direction its 1.5 ms. 

But i think ideally both the sides should have the same values as its round trip time(like a loop).

The trace is RTP over UDP over a VoIP tool.

Now, when i use some other licensed tool based on libpacp used by Wireshark as well, the values for both the sides is almost same with the same pcap file.

So, i am not sure if Wireshark is calculating the wrong RTT values or the interpreation is differnet by other tools as how to calcuate the RTT vlaues?? 

Any idea about this??

Regards
Nitin
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe
Kevin Cullimore | 4 Apr 09:47 2012

Re: Wireless Capture

On 4/4/2012 2:58 AM, Guy Harris wrote:
> On Apr 4, 2012, at 2:30 AM, Kevin Cullimore wrote:
>
> <SNIP>
>>> 	4) if you're stuck running Windows, do your capture with another application, such as Microsoft
Network Monitor:
>>>
>>> 		http://www.microsoft.com/download/en/details.aspx?id=4865
>> It's not clear that this option satisfies the "capture the WiFi physical layer information" requirement.
> Depends on what you mean by "Wi-Fi physical layer information"; it supplies 802.11 headers and at least
some radio information (channel, RSSI, rate).  (See the WiFiMetadata structure in the
Base/wireless.npl NPL file in the set of NPL files for NetMon 3.4.)
Thanks for the reference. It turns out I WAS encountering a violation of 
the "doesn't suck" criterion, which might fail to surprise, given the 
OS/Vendor constraints (although the contrast between the 
functionality/visibility available in modern versions of netmon vs. 
older ones leads me not to complain as loudly as I otherwise might).
>
> However, if the head of Tamosoft is correct, it's not clear that this option satisfies the presumed
"doesn't suck" requirement:
>
> 	http://twitter.com/#!/TamoSoft/status/177670392276713472
>
> " <at> firemywires It's not that rosy,unfortunately.NativeWiFi is poorly implemented in most of the
drivers.And you can't capture 40 MHz channels"
>
> 	http://twitter.com/#!/TamoSoft/status/182380964125745152
>
> " <at> DevinAkin  <at> Ben_SniffWiFi  <at> firemywires No 40 MHz ch,no FCS info,broken sig.level (Ralink),broken
chan.selection (Intel),invalid HT rate info"
>
> Tamosoft's Commview for Wi-Fi solves this by having its own drivers, rather than relying on the
vendor/Microsoft drivers, with the advantage that they can avoid vendor and/or Microsoft driver writer
suckage and the disadvantage that if you don't have a card for which they have a driver, you lose.
>
>>> 	5) if you're stuck running Windows, and it's Vista or later, and want to capture with Wireshark (or
WinDump or any other WinPcap-based application), modify WinPcap so that, on Windows Vista and later,
it's an NDIS 6 driver and uses the Native Wi-Fi mechanism (and the monitor mode APIs from libpcap 1.0 and
later, which means upgrading WinDump's underlying libpcap version to 1.0 or later).  (Contribute the
changes to the WinPcap developers if you don't want to continue supporting them yourself.)
> And that would have the same characteristics as NetMon, given that it'd use the same code path, and hence
the same presumed suckage.
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list<wireshark-users@...>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>               mailto:wireshark-users-request@...?subject=unsubscribe
>
>

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

Sake Blok | 4 Apr 13:40 2012
Picon

Re: Wrong protocol detection - wrong decryption

Have you used "start_tls" instead of the port number in your SSL-keys list? So something like:

1.2.3.4,start_tls,smtp,/tmp/key.pem

Cheers,
Sake

On 3 apr 2012, at 13:35, bitozoid wrote:

> I have also checked the private key and exported certificate:
> $ openssl x509 -in exported_certificate_from_wireshark.der -inform DER
> -noout -modulus | openssl md5
> (stdin)= 03b659a8802627399f3289b8254e69aa
> $ openssl rsa -in /home/bitozoid/server-private.key -inform PEM -noout
> -modulus | openssl md5
> (stdin)= 03b659a8802627399f3289b8254e69aa
> 
> This is another capture. Still having the same problem.
> #117 is a [TCP segment of a reassembled PDU].
> 
> ---------
> 
> ssl_association_remove removing TCP 25 - smtp handle 0x1eb9c50
> Private key imported: KeyID 6e:1a:a0:7a:e0:0c:73:eb:b7:52:90:df:f4:0e:41:6f:...
> ssl_init IPv4 addr '10.141.188.73' (10.141.188.73) port '25' filename
> '/home/bitozoid/server-private.key' password(only for p12 file) ''
> ssl_init private key file /home/bitozoid/server-private.key successfully loaded.
> association_add TCP port 25 protocol smtp handle 0x1eb9c50
> 
> dissect_ssl enter frame #110 (first time)
> ssl_session_init: initializing ptr 0x7fec8cb40420 size 680
>  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
>  record: offset = 0, reported_length_remaining = 104
> 
> dissect_ssl enter frame #112 (first time)
>  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
>  record: offset = 0, reported_length_remaining = 38
> 
> dissect_ssl enter frame #113 (first time)
>  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
>  record: offset = 0, reported_length_remaining = 271
> 
> dissect_ssl enter frame #114 (first time)
>  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
>  record: offset = 0, reported_length_remaining = 10
> 
> dissect_ssl enter frame #115 (first time)
>  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
>  record: offset = 0, reported_length_remaining = 29
> 
> dissect_ssl enter frame #116 (first time)
>  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
>  record: offset = 0, reported_length_remaining = 72
> dissect_ssl3_record: content_type 22
> decrypt_ssl3_record: app_data len 67, ssl state 0x00
> association_find: TCP port 37610 found (nil)
> packet_from_server: is from server - FALSE
> decrypt_ssl3_record: using client decoder
> decrypt_ssl3_record: no decoder available
> dissect_ssl3_handshake iteration 1 type 1 offset 5 length 63 bytes, remaining 72
> packet_from_server: is from server - FALSE
> ssl_find_private_key server 10.141.188.73:25
> dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01
> 
> dissect_ssl enter frame #117 (first time)
>  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
>  record: offset = 0, reported_length_remaining = 1448
>  need_desegmentation: offset = 0, reported_length_remaining = 1448
> 
> dissect_ssl enter frame #118 (first time)
>  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
>  record: offset = 0, reported_length_remaining = 2114
> dissect_ssl3_record found version 0x0301 -> state 0x11
> dissect_ssl3_record: content_type 22
> decrypt_ssl3_record: app_data len 2109, ssl state 0x11
> packet_from_server: is from server - TRUE
> decrypt_ssl3_record: using server decoder
> decrypt_ssl3_record: no decoder available
> dissect_ssl3_handshake iteration 1 type 2 offset 5 length 70 bytes,
> remaining 2114
> dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13
> dissect_ssl3_hnd_srv_hello found CIPHER 0x002F -> state 0x17
> dissect_ssl3_hnd_srv_hello trying to generate keys
> ssl_generate_keyring_material not enough data to generate key (0x17
> required 0x37 or 0x57)
> dissect_ssl3_hnd_srv_hello can't generate keyring material
> dissect_ssl3_handshake iteration 0 type 11 offset 79 length 2027
> bytes, remaining 2114
> dissect_ssl3_handshake iteration 0 type 14 offset 2110 length 0 bytes,
> remaining 2114
> 
> dissect_ssl enter frame #120 (first time)
>  conversation = 0x7fec8cb3ff70, ssl_session = 0x7fec8cb40420
>  record: offset = 0, reported_length_remaining = 267
> dissect_ssl3_record: content_type 22
> decrypt_ssl3_record: app_data len 262, ssl state 0x17
> packet_from_server: is from server - FALSE
> decrypt_ssl3_record: using client decoder
> decrypt_ssl3_record: no decoder available
> dissect_ssl3_handshake iteration 1 type 16 offset 5 length 258 bytes,
> remaining 267
> pre master encrypted[256]:
> 08 63 96 70 3a 19 14 b8 d0 57 7b 5d 9b ed ad 77
> 93 e6 96 76 e5 18 3c ef 00 d0 fc 81 3d d5 8d b7
> 1d 46 b7 5f 93 01 76 bf 69 00 b7 4a 4c f6 d7 42
> f5 fe 69 89 5f 43 9b d6 63 d8 67 43 81 d4 58 85
> f6 b2 b3 fb 32 af 70 80 22 b3 95 f6 b7 4b a8 a1
> c9 1d 3b 25 67 a4 c7 be 91 30 2e c8 98 c2 c5 d0
> 97 48 9c bd 13 35 91 75 b3 14 e0 37 89 08 72 a1
> 28 2b 22 33 44 2b e9 cd c1 8f ee f0 3e 38 5e f1
> 88 fb f1 fa 61 6f 8b df 6f 97 56 de 71 e3 73 49
> 40 7a f5 d5 fa 66 bd 39 11 e6 61 15 03 3b ff c9
> 94 0d d4 f8 79 d5 96 8a e2 f0 df ba 33 30 c2 a9
> 46 04 74 02 9c 16 a2 3b 0d ef 1d ee 39 45 1d 2b
> 42 df 71 88 3c 0e 0b 17 ac 18 e1 a9 9f 83 7a 4e
> d9 82 be a6 30 8b d9 c3 a7 45 9d cd 9f 28 d8 2a
> 30 a7 31 8e 2b cd af a8 73 c3 a0 6d e8 ad 28 d4
> a0 d1 2f e4 fe eb 33 ec f6 b9 6a 9f 9c dc df e7
> ssl_decrypt_pre_master_secret:RSA_private_decrypt
> pcry_private_decrypt: stripping 31 bytes, decr_len 256
> decrypted_unstrip_pre_master[256]:
> 93 58 39 9d c5 0c 2c 75 99 46 31 a1 17 9f 14 43
> 0d f9 26 25 29 d3 e4 f5 50 af 68 34 c9 54 00 e4
> 76 1b 58 c0 ce f8 f3 38 92 03 1f 7e c3 a3 25 21
> e8 a1 71 7d 33 4b 1c f7 0a 9b d3 f2 dd 40 e1 1a
> c5 50 6b fc 83 ce 63 c4 31 5a df 72 37 fb c1 7f
> f9 e0 88 6f 80 13 68 b7 e8 63 0a 1b 8a a6 5b f3
> ed 42 22 99 e0 55 57 f2 38 75 d8 94 08 0b 8c cf
> 36 fc d8 e5 04 84 b2 c0 e7 93 bb 81 d9 65 0f 00
> 4a 8e 07 71 a6 c9 5d f7 e9 5f 45 e4 c9 70 35 95
> e9 6a 24 4b 7f 90 78 a3 9f bf 05 5d b0 62 aa 08
> 50 4c cd 15 95 06 8b 1d a5 9f 49 40 ff 09 98 5e
> 82 bb ba 28 83 19 88 94 4a 08 c0 7c fe 45 e1 5d
> ae b7 61 c2 b6 ee 04 f7 e9 fe 2f a5 e0 70 4b a7
> aa b0 a5 a5 75 98 d2 24 aa 29 27 40 ac 5a a5 3b
> e8 ca 3c 15 6b b4 6d 6a ba 7f 43 35 67 fa 3c 85
> ff 22 30 d6 ae c0 01 9f e3 3b b6 a3 85 49 a1 dc
> ssl_decrypt_pre_master_secret wrong pre_master_secret length (225, expected 48)
> dissect_ssl3_handshake can't decrypt pre master secret
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@...>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request@...?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

bitozoid | 4 Apr 17:04 2012
Picon

Re: Wrong protocol detection - wrong decryption

I have tried both. Same result.

On Wed, Apr 4, 2012 at 12:40 PM, Sake Blok <sake@...> wrote:
> Have you used "start_tls" instead of the port number in your SSL-keys list? So something like:
>
> 1.2.3.4,start_tls,smtp,/tmp/key.pem
>
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe


Gmane