Unable to decode message length

[Valentin David]

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 at redhat.com> 
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 length
> 
> This 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20200716/abffbccb/attachment.htm>