Re: [libvirt] creating stream
On 04/20/2017 03:55 PM, Vasiliy Tolstov wrote:
2017-04-06 14:59 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>:
That is not going to be enough. The RPC protocol is spread among other files too. You really should not hook into our RPC protocol. My question is still unanswered though - why do you need it anyway?
Thanks for all your help, i'm create mostly complete libvirt binding using generator. Last problem - do you know binary representation ofr virTypedParams? Does it xdr encoded when passed via wire or not? And format of this field?
You can see for yourself - just fire up wireshark with libvirt dissector installed and issue the API. Also, you may look at remote_typed_param_value and remote_typed_param structs defined in src/remote/remote_protocol.h. Michal
2017-04-20 17:16 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>:
You can see for yourself - just fire up wireshark with libvirt dissector installed and issue the API.
in my fedora 25 i don't tshark -Ylibvirt does not provide typed params..
Also, you may look at remote_typed_param_value and remote_typed_param structs defined in src/remote/remote_protocol.h.
Thanks, but i don't understand, firstly xdr data contains number of params (params_len) or length of params (it size) ? -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru
2017-04-20 20:55 GMT+03:00 Vasiliy Tolstov <v.tolstov@selfip.ru>:
Thanks, but i don't understand, firstly xdr data contains number of params (params_len) or length of params (it size) ?
I found , so i can decode all typed params to map[string]interface{} thanks! -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru
2017-04-20 21:14 GMT+03:00 Vasiliy Tolstov <v.tolstov@selfip.ru>:
I found , so i can decode all typed params to map[string]interface{} thanks!
I'm try to add support for DomainOpenConsole and don't understand underline payload: https://gist.github.com/vtolstov/f8a0f80de82100440b1c0e824436be5a I'm not handmade this data, i'm use generator from remote_protocol.x to get request struct. If i compare to virsh payload i see , that payload size different. Virsh send 80 byte payload, but i send only 76. https://gist.github.com/vtolstov/56344b8ce309f54441f2dbce851f6b59 type RemoteDomainOpenConsoleReq struct { Domain *RemoteDomain DevName string Flags uint32 } If i add to generated struct 4 empty bytes, and change order of variables inside all works fine, but flags not passed (because it shifted). But payload looks ok. So my question - what i miss in this specific case? (P.S. DomainScreenshot that have identical parts of call and workflow works fine for me using generated structs) type RemoteDomainOpenConsoleReq struct { Domain *RemoteDomain Flags uint32 DevName string Flags2 uint32 } -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru
On 04/21/2017 12:12 PM, Vasiliy Tolstov wrote:
2017-04-20 21:14 GMT+03:00 Vasiliy Tolstov <v.tolstov@selfip.ru>:
I found , so i can decode all typed params to map[string]interface{} thanks!
I'm try to add support for DomainOpenConsole and don't understand underline payload: https://gist.github.com/vtolstov/f8a0f80de82100440b1c0e824436be5a
I'm not handmade this data, i'm use generator from remote_protocol.x to get request struct. If i compare to virsh payload i see , that payload size different. Virsh send 80 byte payload, but i send only 76. https://gist.github.com/vtolstov/56344b8ce309f54441f2dbce851f6b59
type RemoteDomainOpenConsoleReq struct { Domain *RemoteDomain DevName string Flags uint32 }
If i add to generated struct 4 empty bytes, and change order of variables inside all works fine, but flags not passed (because it shifted). But payload looks ok. So my question - what i miss in this specific case? (P.S. DomainScreenshot that have identical parts of call and workflow works fine for me using generated structs)
type RemoteDomainOpenConsoleReq struct { Domain *RemoteDomain Flags uint32 DevName string Flags2 uint32 }
That's how strings are encoded in RPC. the first four bytes say how long the string is followed by N bytes (padded to 4 bytes boundary) of the actual string. Michal
2017-04-21 14:14 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>:
That's how strings are encoded in RPC. the first four bytes say how long the string is followed by N bytes (padded to 4 bytes boundary) of the actual string.
I know, I'm use https://godoc.org/github.com/davecgh/go-xdr/xdr2 and as i see EncodeString already to that. And all other functions what operates on strings works fine. Fow example LookupDomainByName. Or StoragePool functions Bad payload from own prog: 0x0000: 6001 2a87 006c 0640 2a04 ac00 0006 0001 `.*..l.@*....... 0x0010: 0000 0000 0000 0001 2a04 ac00 0004 0010 ........*....... 0x0020: 0ec4 7aff fe54 cb0a e8b2 407d e44c 1249 ..z..T....@}.L.I 0x0030: eafc 4a72 8018 00e1 ffba 0000 0101 080a ..Jr............ 0x0040: 2ef0 9ea7 02ad afcb 0000 004c 2000 8086 ...........L.... 0x0050: 0000 0001 0000 00c9 0000 0000 0000 0009 ................ 0x0060: 0000 0000 0000 0006 3134 3331 3737 0000 ........143177.. 0x0070: 49bf 97e1 4bda 5749 ca89 0000 7db6 2f02 I...K.WI....}./. 0x0080: 0000 0001 0000 0007 7365 7269 616c 3000 ........serial0. 0x0090: 0000 0001 .... Good payload from virsh: 0x0000: 6009 09de 0070 0640 2a04 ac00 0006 0001 `....p.@*....... 0x0010: 0000 0000 0000 0001 2a04 ac00 0004 0010 ........*....... 0x0020: 0ec4 7aff fe54 cb0a e8a8 407d e159 1a3e ..z..T....@}.Y.> 0x0030: 2e25 4a72 8018 00ea ffbe 0000 0101 080a .%Jr............ 0x0040: 2eed 6e7c 02ac e3be 0000 0050 2000 8086 ..n|.......P.... 0x0050: 0000 0001 0000 00c9 0000 0000 0000 0009 ................ 0x0060: 0000 0000 0000 0006 3134 3331 3737 0000 ........143177.. 0x0070: 49bf 97e1 4bda 5749 ca89 0000 7db6 2f02 I...K.WI....}./. 0x0080: 0000 0001 0000 0001 0000 0007 7365 7269 ............seri 0x0090: 616c 3000 0000 0000 al0..... Good payload from own prog append Flags before dev_name and after: 0x0000: 6001 84e3 0070 0640 2a04 ac00 0006 0001 `....p.@*....... 0x0010: 0000 0000 0000 0001 2a04 ac00 0004 0010 ........*....... 0x0020: 0ec4 7aff fe54 cb0a e8b6 407d 9e48 cd8b ..z..T....@}.H.. 0x0030: e141 7380 8018 00e1 ffbe 0000 0101 080a .As............. 0x0040: 2ef2 d3de 02ae 3d19 0000 0050 2000 8086 ......=....P.... 0x0050: 0000 0001 0000 00c9 0000 0000 0000 0009 ................ 0x0060: 0000 0000 0000 0006 3134 3331 3737 0000 ........143177.. 0x0070: 49bf 97e1 4bda 5749 ca89 0000 7db6 2f02 I...K.WI....}./. 0x0080: 0000 0001 0000 0001 0000 0007 7365 7269 ............seri 0x0090: 616c 3000 0000 0001 al0..... So i think that in case of function Open conse Libvirt send to remote server flags twice. Before dev_name and after. Do you have any comments ? -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru
On 04/21/2017 01:36 PM, Vasiliy Tolstov wrote:
2017-04-21 14:14 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>:
That's how strings are encoded in RPC. the first four bytes say how long the string is followed by N bytes (padded to 4 bytes boundary) of the actual string.
I know, I'm use https://godoc.org/github.com/davecgh/go-xdr/xdr2 and as i see EncodeString already to that. And all other functions what operates on strings works fine. Fow example LookupDomainByName. Or StoragePool functions
Bad payload from own prog: 0x0000: 6001 2a87 006c 0640 2a04 ac00 0006 0001 `.*..l.@*....... 0x0010: 0000 0000 0000 0001 2a04 ac00 0004 0010 ........*....... 0x0020: 0ec4 7aff fe54 cb0a e8b2 407d e44c 1249 ..z..T....@}.L.I 0x0030: eafc 4a72 8018 00e1 ffba 0000 0101 080a ..Jr............ 0x0040: 2ef0 9ea7 02ad afcb 0000 004c 2000 8086 ...........L.... 0x0050: 0000 0001 0000 00c9 0000 0000 0000 0009 ................ 0x0060: 0000 0000 0000 0006 3134 3331 3737 0000 ........143177.. 0x0070: 49bf 97e1 4bda 5749 ca89 0000 7db6 2f02 I...K.WI....}./. 0x0080: 0000 0001 0000 0007 7365 7269 616c 3000 ........serial0. 0x0090: 0000 0001 ....
Good payload from virsh: 0x0000: 6009 09de 0070 0640 2a04 ac00 0006 0001 `....p.@*....... 0x0010: 0000 0000 0000 0001 2a04 ac00 0004 0010 ........*....... 0x0020: 0ec4 7aff fe54 cb0a e8a8 407d e159 1a3e ..z..T....@}.Y.> 0x0030: 2e25 4a72 8018 00ea ffbe 0000 0101 080a .%Jr............ 0x0040: 2eed 6e7c 02ac e3be 0000 0050 2000 8086 ..n|.......P.... 0x0050: 0000 0001 0000 00c9 0000 0000 0000 0009 ................ 0x0060: 0000 0000 0000 0006 3134 3331 3737 0000 ........143177.. 0x0070: 49bf 97e1 4bda 5749 ca89 0000 7db6 2f02 I...K.WI....}./. 0x0080: 0000 0001 0000 0001 0000 0007 7365 7269 ............seri
So the extra "byte" (in fact 4 bytes) are at 0x0084-0x0087. So this is how strings are encoded. There are basically two types of strings when it comes to XDR. The first one is nonnull_string, which are encoded [length][string]. With just this it would be impossible to differentiate between NULL and an empty string "" as both would be encoded in the same way. Therefore, there is remote_string (libvirt terminology) or xdr_pointer (XDR terminology) which encodes a pointer as [bool][pointer] where bool is either 00 00 00 00 meaning the pointer is NULL or something else (e.g. 00 00 00 01) meaning the pointer has a non-NULL value. So long story short, what you can see here is: 00 00 00 01 00 00 00 07 73 65 72 69 61 6c 30 which is the same as (regroup) [00 00 00 01] [00 00 00 07] [73 65 72 69 61 6c 30] which means: the following pointer is a non-NULL pointer, and it is a string of the length 7 and the string is "serial0".
0x0090: 616c 3000 0000 0000 al0.....
Michal
2017-04-21 17:34 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>:
So the extra "byte" (in fact 4 bytes) are at 0x0084-0x0087. So this is how strings are encoded. There are basically two types of strings when it comes to XDR. The first one is nonnull_string, which are encoded [length][string]. With just this it would be impossible to differentiate between NULL and an empty string "" as both would be encoded in the same way. Therefore, there is remote_string (libvirt terminology) or xdr_pointer (XDR terminology) which encodes a pointer as [bool][pointer] where bool is either 00 00 00 00 meaning the pointer is NULL or something else (e.g. 00 00 00 01) meaning the pointer has a non-NULL value. So long story short, what you can see here is:
00 00 00 01 00 00 00 07 73 65 72 69 61 6c 30
which is the same as (regroup)
[00 00 00 01] [00 00 00 07] [73 65 72 69 61 6c 30]
which means: the following pointer is a non-NULL pointer, and it is a string of the length 7 and the string is "serial0".
Ahh sorry. This is bug in xdr2 package, and i merge pr for it and now works fine =). Thanks again for help! -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru
participants (2)
-
Michal Privoznik -
Vasiliy Tolstov