Bug 1466597 - There was no login message after connect to the guest which was taken as gnutls-serv so doubting it worked as expected or not.
There was no login message after connect to the guest which was taken as gnut...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.4
All Unspecified
medium Severity medium
: rc
: ---
Assigned To: Gerd Hoffmann
Chao Yang
:
Depends On: 1498967
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-29 23:27 EDT by Min Deng
Modified: 2018-01-12 05:01 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
wireshark log (13.91 KB, text/plain)
2017-10-04 02:55 EDT, Gerd Hoffmann
no flags Details
client certificate (5.19 KB, text/plain)
2017-10-04 05:58 EDT, Gerd Hoffmann
no flags Details
systemtap script for debugging TLS (1.10 KB, text/plain)
2017-10-05 11:27 EDT, Daniel Berrange
no flags Details

  None (edit)
Description Min Deng 2017-06-29 23:27:07 EDT
Description of problem:
There was no login message after connect to the guest which was taken as gnutls-serv
Version-Release number of selected component (if applicable):
gnutls-3.3.26-9.el7.x86_64
kernel-3.10.0-690.el7.x86_64
qemu-kvm-rhev-2.9.0-14.el7.x86_64

How reproducible:
2/2

Steps to Reproduce:
1.Firstly create a gnutls-serv relevant key files
---------------------------------------------------------
certtool --generate-privkey > x509-ca-key.pem
echo 'cn = dhcp-10-122.nay.redhat.com' > ca.tmpl
echo 'ca' >> ca.tmpl
echo 'cert_signing_key' >> ca.tmpl
certtool --generate-self-signed --load-privkey x509-ca-key.pem --template ca.tmpl --outfile x509-ca.pem

certtool --generate-privkey > x509-server-key.pem
echo 'organization = GnuTLS test server' > server.tmpl
echo 'cn = dhcp-10-122.nay.redhat.com' >> server.tmpl
echo 'tls_www_server' >> server.tmpl
echo 'encryption_key' >> server.tmpl
echo 'signing_key' >> server.tmpl
echo 'dns_name = dhcp-10-122.nay.redhat.com' >> server.tmpl
certtool --generate-certificate --load-privkey x509-server-key.pem --load-ca-certificate x509-ca.pem --load-ca-privkey x509-ca-key.pem --template server.tmpl --outfile x509-server.pem

certtool --generate-privkey > x509-client-key.pem
echo 'cn = dhcp-10-122.nay.redhat.com' > client.tmpl
echo 'tls_www_client' >> client.tmpl
echo 'encryption_key' >> client.tmpl
echo 'signing_key' >> client.tmpl
certtool --generate-certificate --load-privkey x509-client-key.pem --load-ca-certificate x509-ca.pem --load-ca-privkey x509-ca-key.pem --template client.tmpl --outfile x509-client.pem

certtool --to-p12 --load-ca-certificate x509-ca.pem --load-privkey x509-client-key.pem --load-certificate x509-client.pem --outder --outfile x509-client.p12

ln -s x509-ca.pem ca-cert.pem
ln -s x509-server.pem server-cert.pem
ln -s x509-server-key.pem server-key.pem

By the way,in order to make sure the file are correct please run the following cli to check.
gnutls-serv --echo \
            --x509cafile ca-cert.pem \
            --x509keyfile server-key.pem \
            --x509certfile server-cert.pem

2.Boot up guest with the following cli - endpoint was server here
  /usr/libexec/qemu-kvm -m 8G -smp 16 -name vocado-vt-vm1 -vga std -device virtio-blk-pci,id=disk,drive=drive-disk0,bootindex=1 -drive file=rhel74-64-virtio.qcow2,format=qcow2,if=none,id=drive-disk0,cache=none,werror=stop -enable-kvm -monitor stdio -vnc :0 -vga std -object tls-creds-x509,id=tls0,endpoint=server,dir=/home/mdeng -chardev socket,id=s0,host=dhcp-10-122.nay.redhat.com,port=12121,tls-creds=tls0,server,nowait -device isa-serial,chardev=s0
3.boot another instance in order to connect to the above server
 /usr/libexec/qemu-kvm -object tls-creds-x509,id=tls0,endpoint=client,dir=/home/mdeng -chardev socket,id=s0,host=dhcp-10-122.nay.redhat.com,port=12121,tls-creds=tls0 -device isa-serial,chardev=s0 -monitor stdio

4.According to test case
#screen /dev/ttyS0 inside server guest.

Actual results:
No output at all

Expected results:
There should some greetings message pops up,otherwise QE doubted if it worked or not

Additional info:
Both x86 and power have the issue so it was marked as "All"
Comment 4 Min Deng 2017-07-12 04:18:43 EDT
Reproduced the similar issue on the following builds on x86 platform
qemu-kvm-rhev-2.6.0-28.el7_3.12.x86_64
kernel-3.10.0-514.27.1.el7.x86_64 (host and guest)
Comment 5 Ademar Reis 2017-09-18 19:29:07 EDT
(In reply to Min Deng from comment #0)
> Description of problem:
> There was no login message after connect to the guest which was taken as
> gnutls-serv
> Version-Release number of selected component (if applicable):
> gnutls-3.3.26-9.el7.x86_64
> kernel-3.10.0-690.el7.x86_64
> qemu-kvm-rhev-2.9.0-14.el7.x86_64
> 
> How reproducible:
> 2/2
> 
> Steps to Reproduce:
> 1.Firstly create a gnutls-serv relevant key files
> ---------------------------------------------------------
> certtool --generate-privkey > x509-ca-key.pem
> echo 'cn = dhcp-10-122.nay.redhat.com' > ca.tmpl
> echo 'ca' >> ca.tmpl
> echo 'cert_signing_key' >> ca.tmpl
> certtool --generate-self-signed --load-privkey x509-ca-key.pem --template
> ca.tmpl --outfile x509-ca.pem
> 
> certtool --generate-privkey > x509-server-key.pem
> echo 'organization = GnuTLS test server' > server.tmpl
> echo 'cn = dhcp-10-122.nay.redhat.com' >> server.tmpl
> echo 'tls_www_server' >> server.tmpl
> echo 'encryption_key' >> server.tmpl
> echo 'signing_key' >> server.tmpl
> echo 'dns_name = dhcp-10-122.nay.redhat.com' >> server.tmpl
> certtool --generate-certificate --load-privkey x509-server-key.pem
> --load-ca-certificate x509-ca.pem --load-ca-privkey x509-ca-key.pem
> --template server.tmpl --outfile x509-server.pem
> 
> certtool --generate-privkey > x509-client-key.pem
> echo 'cn = dhcp-10-122.nay.redhat.com' > client.tmpl
> echo 'tls_www_client' >> client.tmpl
> echo 'encryption_key' >> client.tmpl
> echo 'signing_key' >> client.tmpl
> certtool --generate-certificate --load-privkey x509-client-key.pem
> --load-ca-certificate x509-ca.pem --load-ca-privkey x509-ca-key.pem
> --template client.tmpl --outfile x509-client.pem
> 
> certtool --to-p12 --load-ca-certificate x509-ca.pem --load-privkey
> x509-client-key.pem --load-certificate x509-client.pem --outder --outfile
> x509-client.p12
> 
> ln -s x509-ca.pem ca-cert.pem
> ln -s x509-server.pem server-cert.pem
> ln -s x509-server-key.pem server-key.pem
> 
> By the way,in order to make sure the file are correct please run the
> following cli to check.
> gnutls-serv --echo \
>             --x509cafile ca-cert.pem \
>             --x509keyfile server-key.pem \
>             --x509certfile server-cert.pem
> 
> 2.Boot up guest with the following cli - endpoint was server here
>   /usr/libexec/qemu-kvm -m 8G -smp 16 -name vocado-vt-vm1 -vga std -device
> virtio-blk-pci,id=disk,drive=drive-disk0,bootindex=1 -drive
> file=rhel74-64-virtio.qcow2,format=qcow2,if=none,id=drive-disk0,cache=none,
> werror=stop -enable-kvm -monitor stdio -vnc :0 -vga std -object
> tls-creds-x509,id=tls0,endpoint=server,dir=/home/mdeng -chardev
> socket,id=s0,host=dhcp-10-122.nay.redhat.com,port=12121,tls-creds=tls0,
> server,nowait -device isa-serial,chardev=s0
> 3.boot another instance in order to connect to the above server
>  /usr/libexec/qemu-kvm -object
> tls-creds-x509,id=tls0,endpoint=client,dir=/home/mdeng -chardev
> socket,id=s0,host=dhcp-10-122.nay.redhat.com,port=12121,tls-creds=tls0
> -device isa-serial,chardev=s0 -monitor stdio
> 
> 4.According to test case
> #screen /dev/ttyS0 inside server guest.
> 
> Actual results:
> No output at all
> 
> Expected results:
> There should some greetings message pops up,otherwise QE doubted if it
> worked or not
> 
> Additional info:
> Both x86 and power have the issue so it was marked as "All"


Is this a valid use-case under libvirt? Otherwise we might close it downstream.

CC'ing Gerd and Daniel for (potential) feedback on this particular use-case.
Comment 6 Gerd Hoffmann 2017-09-19 02:48:27 EDT
> > 
> > 4.According to test case
> > #screen /dev/ttyS0 inside server guest.
> > 
> > Actual results:
> > No output at all
> > 
> > Expected results:
> > There should some greetings message pops up,otherwise QE doubted if it
> > worked or not

If you have a serial console configured in the other guest, then yes, there should be a login prompt.  You might have to tap "enter" to see it.

> Is this a valid use-case under libvirt? Otherwise we might close it
> downstream.

I think libvirt supports listening sockets (-chardev socket,${args},server,nowait) only.
Comment 7 Min Deng 2017-09-20 03:19:11 EDT
Just got the reply from libvirt QE,the use case is valid under libvirt.Thanks a lot.
Comment 9 Gerd Hoffmann 2017-09-26 05:13:22 EDT
Works fine for me.

Server guest configuration:

    <serial type='pty'>
      <target port='0'/>
    </serial>
    <serial type='tcp'>
      <source mode='bind' host='127.0.0.1' service='4444' tls='yes'/>
      <protocol type='raw'/>
      <target port='1'/>
    </serial>

Client guest configuration:

    <serial type='pty'>
      <target port='0'/>
    </serial>
    <serial type='tcp'>
      <source mode='connect' host='127.0.0.1' service='4444' tls='yes'/>
      <protocol type='raw'/>
      <target port='1'/>
    </serial>

Certificate files are in /etc/pki/qemu (default libvirt location).
ttyS0 is used as serial console (available via virsh console).
ttyS1 is links the guests to each other via tcp.

Boot guest 0 (server), start screen on /dev/ttyS1.
Boot guest 1 (client), edit kernel command line (console=ttyS1,115200) in grub

Can watch guest 1 boot messages using screen running in guest 0 just fine.
Get a login prompt, can login without problems.
Comment 10 Gerd Hoffmann 2017-09-26 05:14:33 EDT
> If you have a serial console configured in the other guest, then yes, there
> should be a login prompt.  You might have to tap "enter" to see it.

So, is your client guest actually configured for a serial console?
Comment 11 Min Deng 2017-09-30 00:00:33 EDT
(In reply to Gerd Hoffmann from comment #10)
> > If you have a serial console configured in the other guest, then yes, there
> > should be a login prompt.  You might have to tap "enter" to see it.
> 
> So, is your client guest actually configured for a serial console?

Hi Gerd,
   In my client guest,it was set like this "console=ttyS0,115200" in kernel line.And I still can reproduce the issue.And did you try the steps from comment0 ? Thanks a lot.
CLI,/usr/libexec/qemu-kvm -m 8G -smp 16 -name vocado-vt-vm1 -vga std -device virtio-blk-pci,id=disk,drive=drive-disk0,bootindex=1 -drive file=rhel74-64-virtio.qcow2,format=qcow2,if=none,id=drive-disk0,cache=none,werror=stop -enable-kvm -monitor stdio -vnc :0 -vga std -object tls-creds-x509,id=tls0,endpoint=server,dir=/home/mdeng -chardev socket,id=s0,host=dhcp-10-208.nay.redhat.com,port=12121,tls-creds=tls0,server,nowait -device isa-serial,chardev=s0
root      2297  9.0 23.2 9073864 1814240 pts/2 Sl+  11:49   0:44 /usr/libexec/qemu-kvm -m 8G -smp 16 -name vocado-vt-vm1 -vga std -device virtio-blk-pci,id=disk,drive=drive-disk0,bootindex=1 -drive file=rhel74-64-virtio-client.qcow2,format=qcow2,if=none,id=drive-disk0,cache=none,werror=stop -enable-kvm -monitor stdio -vnc :1 -vga std -object tls-creds-x509,id=tls0,endpoint=client,dir=/home/mdeng -chardev socket,id=s0,host=dhcp-10-208.nay.redhat.com,port=12121,tls-creds=tls0 -device isa-serial,chardev=s0

Best regards,
Min
Comment 12 Gerd Hoffmann 2017-10-04 02:23:30 EDT
(In reply to Min Deng from comment #11)
> (In reply to Gerd Hoffmann from comment #10)
> > > If you have a serial console configured in the other guest, then yes, there
> > > should be a login prompt.  You might have to tap "enter" to see it.
> > 
> > So, is your client guest actually configured for a serial console?
> 
> Hi Gerd,
>    In my client guest,it was set like this "console=ttyS0,115200" in kernel
> line.And I still can reproduce the issue.And did you try the steps from
> comment0 ? Thanks a lot.

I'm using libvirt to manage my guests.  The generated qemu command line is:

server: 

-object tls-creds-x509,id=objcharserial1_tls0,dir=/etc/pki/qemu,endpoint=server,verify-peer=no -chardev socket,id=charserial1,host=127.0.0.1,port=4444,server,nowait,tls-creds=objcharserial1_tls0 -device isa-serial,chardev=charserial1,id=serial1

client:

-object tls-creds-x509,id=objcharserial1_tls0,dir=/etc/pki/qemu,endpoint=client,verify-peer=no -chardev socket,id=charserial1,host=127.0.0.1,port=4444,tls-cred=objcharserial1_tls0 -device isa-serial,chardev=charserial1,id=serial1

Obvious difference is "verify-peer=no" added by libvirt.
Comment 13 Gerd Hoffmann 2017-10-04 02:45:16 EDT
Enabled verification in /etc/libvirt/qemu.conf

default_tls_x509_verify = 1

Now libvirt starts qemu with "verify-peer=yes".

And guests talking to each other stops working indeed.

tcp connection is established according to netstat:

root@sirius ~# netstat -tnap | grep 4444
tcp        0      0 127.0.0.1:4444          0.0.0.0:*               LISTEN      3319/qemu-kvm       
tcp        0      0 127.0.0.1:32804         127.0.0.1:4444          ESTABLISHED 3452/qemu-kvm       
tcp        0      0 127.0.0.1:4444          127.0.0.1:32804         ESTABLISHED 3319/qemu-kvm       

Nothing obvious in the logs.
Comment 14 Gerd Hoffmann 2017-10-04 02:55 EDT
Created attachment 1334059 [details]
wireshark log

Not an TLS expert, but to me it looks like the tls handshake doesn't complete and is stuck somewhere in the client certificate verification.
Comment 15 Gerd Hoffmann 2017-10-04 02:58:17 EDT
Daniel, any clue?
Comment 16 Daniel Berrange 2017-10-04 05:13:01 EDT
(In reply to Gerd Hoffmann from comment #14)
> Created attachment 1334059 [details]
> wireshark log
> 
> Not an TLS expert, but to me it looks like the tls handshake doesn't
> complete and is stuck somewhere in the client certificate verification.

When you set 'verify-peer=yes' on the TLS peer with endpoint=server, this means that the TLS client must have a client certificate. So if setting this causes the handshake to fail, then most likely you are missing the client-cert.pem & client-key.pem files in /etc/pki/qemu, or they are invalid in some manner.
Comment 17 Gerd Hoffmann 2017-10-04 05:58 EDT
Created attachment 1334151 [details]
client certificate
Comment 18 Gerd Hoffmann 2017-10-04 06:04:07 EDT
> When you set 'verify-peer=yes' on the TLS peer with endpoint=server, this
> means that the TLS client must have a client certificate. So if setting this
> causes the handshake to fail, then most likely you are missing the
> client-cert.pem & client-key.pem files in /etc/pki/qemu, or they are invalid
> in some manner.

Certificate is present and should be valid too (see comment 17 attachment).
And, yes, ca-cert.pem is the ca certificate used to sign this.
Comment 19 Daniel Berrange 2017-10-04 06:14:48 EDT
Best bet to debug this kind of thing is to take one of the QEMU's out of the picture and replace it with gnutls CLI tools.

eg use 'gnutls-cli' as the client instead of the QEMU with endpoint=client. If that works, then do the reverse, use gnutls-serv instead of the QEMU with endpoint=server. Likely one of these setups will fail but if they both work then it would suggest a QEMU bug.
Comment 20 Gerd Hoffmann 2017-10-04 08:50:40 EDT
Test 1:

gnutls-cli --x509certfile=client-cert.pem --x509keyfile=client-key.pem -p 4444 sirius.home.kraxel.org

Works fine.

Test 2:

gnutls-cli -p 4444 sirius.home.kraxel.org

Connects ok: gnutls says "Handshake was completed" and enters simple client mode.

I've expected gnutls-cli throw an error though, saying something along the lines that a client certificate is required.

Chars typed in simple client mode do not show up in the guest, i.e. behavior is simliar to the case with the two qemu instances linked to each other.

Moreover qemu seems to be stuck in this state forever.  When stopping gnutls-cli and trying to connect again it says "Connecting to '192.168.2.105:4444'..." then hangs.
Comment 21 Daniel Berrange 2017-10-05 11:23:20 EDT
(In reply to Min Deng from comment #0)
> ln -s x509-ca.pem ca-cert.pem
> ln -s x509-server.pem server-cert.pem
> ln -s x509-server-key.pem server-key.pem

Here you setup the CA and the server certs for QEMU, but no client certs.


> 2.Boot up guest with the following cli - endpoint was server here
>   /usr/libexec/qemu-kvm -m 8G -smp 16 -name vocado-vt-vm1 -vga std -device
> virtio-blk-pci,id=disk,drive=drive-disk0,bootindex=1 -drive
> file=rhel74-64-virtio.qcow2,format=qcow2,if=none,id=drive-disk0,cache=none,
> werror=stop -enable-kvm -monitor stdio -vnc :0 -vga std -object
> tls-creds-x509,id=tls0,endpoint=server,dir=/home/mdeng -chardev
> socket,id=s0,host=dhcp-10-122.nay.redhat.com,port=12121,tls-creds=tls0,
> server,nowait -device isa-serial,chardev=s0

The 'tls-creds-x509' you have here does not have 'verify-peer' present, so it will use the default of 'yes', which means client certs are *required*.


> 3.boot another instance in order to connect to the above server
>  /usr/libexec/qemu-kvm -object
> tls-creds-x509,id=tls0,endpoint=client,dir=/home/mdeng -chardev
> socket,id=s0,host=dhcp-10-122.nay.redhat.com,port=12121,tls-creds=tls0
> -device isa-serial,chardev=s0 -monitor stdio

Since you didn't setup client-cert.pem and client-key.pem when creating the certs, this QEMU will not supply any certs to the server and so its connection will fail handshake

So this looks like just a mis-configuration when setting up certs.

I've tested this setup myself, providing a suitable client-cert.pem and client-key.pem and it works as expected.

Inside the server guest I did 'cat /dev/ttyS0' and in the client guets I did 'echo hello > /dev/ttyS0' and it was seen by the server.
Comment 22 Daniel Berrange 2017-10-05 11:25:30 EDT
(In reply to Gerd Hoffmann from comment #20)
> Test 1:
> 
> gnutls-cli --x509certfile=client-cert.pem --x509keyfile=client-key.pem -p
> 4444 sirius.home.kraxel.org
> 
> Works fine.
> 
> Test 2:
> 
> gnutls-cli -p 4444 sirius.home.kraxel.org
> 
> Connects ok: gnutls says "Handshake was completed" and enters simple client
> mode.
> 
> I've expected gnutls-cli throw an error though, saying something along the
> lines that a client certificate is required.
> 
> Chars typed in simple client mode do not show up in the guest, i.e. behavior
> is simliar to the case with the two qemu instances linked to each other.
> 
> Moreover qemu seems to be stuck in this state forever.  When stopping
> gnutls-cli and trying to connect again it says "Connecting to
> '192.168.2.105:4444'..." then hangs.

I've found a bug in the chardev code which explains this. When TLS handshake fails the server calls 'tcp_chr_disconnect', which should close the client io channel & listen for new client. There's a bogus check on 's->connected' in there though, causing it to skip all the cleanup code.  This explains why gnutls-cli doesn't see its connection dropped, but data typed won't appear - the server left the client connected, but is ignoring it.
Comment 23 Daniel Berrange 2017-10-05 11:27 EDT
Created attachment 1334895 [details]
systemtap script for debugging TLS

This systemtap script will print out information about the key phases of the TLS process. Just run 'stap tls.stp' as root and then launch the two guests.
Comment 24 Daniel Berrange 2017-10-05 11:34:55 EDT
This patch fixes the bug Gerd saw in handling TLS handshake failures

https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg01061.html
Comment 25 Daniel Berrange 2017-10-05 12:37:17 EDT
(In reply to Daniel Berrange from comment #24)
> This patch fixes the bug Gerd saw in handling TLS handshake failures
> 
> https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg01061.html

I filed a separate bug for the problem with reconnects that Gerd discovered

https://bugzilla.redhat.com/show_bug.cgi?id=1498967
Comment 26 Gerd Hoffmann 2017-10-06 01:27:15 EDT
Can you please re-test with proper client certificate setup (see comment 21)?
Comment 27 Min Deng 2017-10-10 04:57:59 EDT
Hi Gerd,
   Sorry for delay,I am just back to work today since last week was our National Holidays.
   I re-tested the bug again according to comment21 and comment0.
Case I,
   It really works when set "verify-peer=no" 
Case II 
   It still cannot work when set verify-peer=yes explicitly or by default.
  
  In fact,in my steps,the client relevant key files have been created but didn't make alias.I did these extra steps at this time.From my opinions,they were suitable key files as well.

   ln -s x509-client-key.pem client-key.pem
   ln -s x509-client.pem client.pem

My dir,
[root@dhcp-10-208 mdeng]# ll
total 19273120
lrwxrwxrwx 1 root root         11 Sep 30 11:39 ca-cert.pem -> x509-ca.pem
lrwxrwxrwx 1 root root         19 Oct 10 15:56 client-key.pem -> x509-client-key.pem
lrwxrwxrwx 1 root root         15 Oct 10 15:56 client.pem -> x509-client.pem
lrwxrwxrwx 1 root root         15 Sep 30 11:39 server-cert.pem -> x509-server.pem
lrwxrwxrwx 1 root root         19 Sep 30 11:40 server-key.pem -> x509-server-key.pem
-rw-r--r-- 1 root root        146 Sep 30 11:38 server.tmpl
-rw-r--r-- 1 root root       5816 Sep 30 11:37 x509-ca-key.pem
-rw-r--r-- 1 root root       1127 Sep 30 11:38 x509-ca.pem
-rw-r--r-- 1 root root       5823 Sep 30 11:39 x509-client-key.pem
-rw-r--r-- 1 root root       3582 Sep 30 11:39 x509-client.p12
-rw-r--r-- 1 root root       1196 Sep 30 11:39 x509-client.pem
-rw-r--r-- 1 root root       5816 Sep 30 11:38 x509-server-key.pem
-rw-r--r-- 1 root root       1289 Sep 30 11:38 x509-server.pem

By the way,the tools from comment 25,there was some debug error on my host.
[root@dhcp-10-208 mdeng]# stap tls.stp
/tmp/stapeLvzow/stap_44e8737015209cbf6ff488db8b3cc1dc_4083_src.c:10:29: fatal error: runtime_defines.h: No such file or directory
 #include "runtime_defines.h"
                             ^
compilation terminated.
make[1]: *** [/tmp/stapeLvzow/stap_44e8737015209cbf6ff488db8b3cc1dc_4083_src.o] Error 1
make: *** [_module_/tmp/stapeLvzow] Error 2
WARNING: kbuild exited with status: 2
Pass 4: compilation failed.  [man error::pass4]

In a nutshell,it works with "verify-peer=no" but doesn't work with "verify-peer=yes" even I have set client cert with my keys.Is there any other steps for it ? Thanks a lot.

Min
Comment 28 Gerd Hoffmann 2017-11-14 07:07:24 EST
> In a nutshell,it works with "verify-peer=no" but doesn't work with
> "verify-peer=yes" even I have set client cert with my keys.Is there any
> other steps for it ? Thanks a lot.

I think we have to wait for bug 1498967 being fixed.
Added dependency.
Comment 29 Gerd Hoffmann 2018-01-12 05:01:00 EST
> I think we have to wait for bug 1498967 being fixed.

that bug was moved to 7.6, doing the same here.

Note You need to log in before you can comment on or make changes to this bug.