Thank you for the help. But here I get exactly the same data as you. So I suppose the issue is on the server side only. I will try with gdb now.
On Wed, Jul 15, 2020 at 16:02, Michal Privoznik <mprivozn@xxxxxxxxxx> wrote:
On 7/14/20 7:42 PM, Valentin David wrote:Hello all, I have been trying to get libvirtd to work but when I connect to it with virsh, I get "error : virNetMessageDecodeLength:131 : Unable to decode message length" This happens with libvirt 6.1.0, libtirpc 1.2.6, rpcsvc-proto 1.4.1. I have tried with other versions, but I still get the same error. If anybody has any tip on what to try next, that would be helpful. Thank you in advance. Here is the debug log of libvirtd when I try to connect with virsh:2020-07-14 16:29:58.220+0000: 5352: error : virNetMessageDecodeLength:131 : Unable to decode message lengthThis is interesting. The error message is reported when xdr_u_int() fails. It is trying to decode first 4 bytes of incoming message to see how long it is. I can think of two possible reasons for this: 1) the client did not send 4 bytes 2) the rpcgen generated some wrong code that libtirpc is unable to decode. I suggest using wireshark to check what data is send (don't forget to use plain TCP transport in URI, for instance 'virsh -c qemu+tcp://localhost/system'). The first call that virsh does is AUTH_LIST procedure and it should look like this: 0000 00 00 00 00 00 00 00 00 00 00 00 00 86 dd 60 04 0010 52 cc 00 3c 06 40 00 00 00 00 00 00 00 00 00 00 0020 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 01 df 6c 40 7d fd e7 38 94 09 92 0040 bf 48 80 18 02 00 00 44 00 00 01 01 08 0a c9 4f 0050 f4 f2 c9 4f f4 f2 00 00 00 1c 20 00 80 86 00 00 0060 00 01 00 00 00 42 00 00 00 00 00 00 00 00 00 00 0070 00 00 bytes 0x56-0x59 contain 0x1c (= 28) which is the length of the packet (28 bytes). This is how our dissector decodes it: Libvirt length: 28 program: REMOTE (0x20008086) version: 1 procedure: AUTH_LIST (66) type: CALL (0) serial: 0 status: OK (0) Michal
