RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1733165 - QEMU Guest Agent For Windows Return Garbled NIC Name
Summary: QEMU Guest Agent For Windows Return Garbled NIC Name
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virtio-win
Version: 8.0
Hardware: x86_64
OS: Windows
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Basil Salman
QA Contact: xiagao
URL:
Whiteboard:
Depends On:
Blocks: 1779878
TreeView+ depends on / blocked
 
Reported: 2019-07-25 09:54 UTC by Su, Jun-Ming
Modified: 2022-05-11 09:40 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1779878 (view as bug list)
Environment:
Last Closed: 2020-02-04 12:27:28 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
socat results (176.98 KB, image/jpeg)
2019-07-25 09:54 UTC, Su, Jun-Ming 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-29027 0 None None None 2022-05-11 09:40:23 UTC

Description Su, Jun-Ming 2019-07-25 09:54:05 UTC 
Created attachment 1593353 [details]
socat results

Description of problem:
I have a windows 2019 server guest and installed qemu guest agent on the guest VM. Once I use socat to connect the socket to the guest qemu agent and show network interface name, It will garbled when the network interface name is texted by chinese.

Version-Release number of selected component (if applicable):
virtio-version: 0.1.149
host disto: Proxmox VE 6.0-4 (Debian Buster)
qemu server: 6.0-5


How reproducible:
Install a Windows and QEMU guest agent on it, naming the NIC in chinese, use socat to connect the agent and send command to get the result.


Steps to Reproduce:
1. Install a Windows.
2. Install the latest QEMU Guest Agent on the Windows guest VM.
3. At the host 
    socat /var/run/qemu-server/XXX.qga -
   XXX is the vmid
4. Input {"execute":"guest-network-get-interfaces"}
5. Get the result
Actual results:
The network interface name will garbled when they named in chinese.

Expected results:
The network interface name should be displayed correctly as naming in chinese.

Additional info:
The attachment is the result of the NIC name in chinese, the first is "喔喔喔", the second is "阿阿阿" , and the last is "嗯嗯", they all translated into Replacement Character, and be garbled.
Comment 1 Bishara AbuHattoum 2019-08-06 13:09:38 UTC 
My first assessment looking at the QEMU gGuest Agent's Windows commands code is that the issue is related to a conflict in encoding and decoding the ifAlias of a network adapter which is in our case the same as the FriendlyName which name is assigned to.

So in the QEMU Guest Agent code the decoding part is done using the code page CP_ACP (The system default Windows ANSI code page), it changes from machine to machine it is changeable, I think that a more concrete code page should be provided to be used in the decoding part of the ifAlias.

More tests should be done, but for now this is my first assessment.
Comment 2 Su, Jun-Ming 2019-08-07 02:45:27 UTC 
Yes, and because of the non-latin windows the nic name will be named default by the locale preference (like in Chinese will be "區域連線" for Local Networks), maybe consider to make good usage for output encoding/decoding.

The following is the part of code, WideCharToMultiByte()

https://github.com/qemu/qemu/blob/629d166994725773dea9cef843fcb0ae5f3585fe/qga/commands-win32.c#L1394
Comment 3 Su, Jun-Ming 2019-08-12 07:23:01 UTC 
Hi, I've test the thought that I describe before, and it will be fixed to do WideCharToMultiByte() twice.

The code of qemu/qga/commands-win32.c should to be modified like this for supporting windows utf-8.

static char *guest_wctomb_dup(WCHAR *wstr)
{
    char *str = NULL;
    size_t i;

    i = WideCharToMultiByte(CP_UTF8, 0, wstr, -1, NULL, 0, NULL, NULL);
    //i = wcslen(wstr) + 1;
    str = g_malloc(i+1);
    //WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK,
    //                    wstr, -1, str, i, NULL, NULL);

    WideCharToMultiByte(CP_UTF8, 0, wstr, -1, str, i, NULL, NULL);
    return str;
}

The record of this modification is the link https://gist.github.com/sujunmin/bff63c05df2541dcc5d71dbe04dc1609
Comment 4 Bishara AbuHattoum 2019-08-13 08:40:28 UTC 
Great work.
I have tested the functionality with these changes, the name is returned correctly, (Unicode encoded format).
But there is now the issue of the returned Chinese name being in a Unicode encoded format, so for a name like "喔喔喔" the returned value is {"name": "\u5594\u5594\u5594"}
Is that the wanted behavior? or we need a double decoding? I need to clarify this.
Comment 5 Bishara AbuHattoum 2019-08-13 08:53:32 UTC 
(In reply to Bishara AbuHattoum from comment #4)
> Great work.
> I have tested the functionality with these changes, the name is returned
> correctly, (Unicode encoded format).
> But there is now the issue of the returned Chinese name being in a Unicode
> encoded format, so for a name like "喔喔喔" the returned value is {"name":
> "\u5594\u5594\u5594"}
> Is that the wanted behavior? or we need a double decoding? I need to clarify
> this.

I take what I said back, the returned value is correct.
Will further test and send changes ASAP.
Comment 6 xiagao 2019-08-20 10:51:15 UTC 
Can reproduce with mingw-qemu-ga-win-100.0.0.0-3.el7ev

The nic interface name in chinese is changed to "???" via "guest-network-get-interfaces" guest agent cmd.

The following is the result of the NIC name in chinese, the first is "测试", the second is "红帽测试".
{"execute":"guest-network-get-interfaces"}
{"return": [{"name": "??", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "2620:52:0:4948:4c3d:1085:dc2d:8584", "prefix": 64}, {"ip-address-type": "ipv6", "ip-address": "fe80::4c3d:1085:dc2d:8584%5", "prefix": 64}, {"ip-address-type": "ipv4", "ip-address": "10.73.75.113", "prefix": 22}], "statistics": {"tx-packets": 1189, "tx-errs": 0, "rx-bytes": 507263, "rx-dropped": 0, "rx-packets": 933, "rx-errs": 0, "tx-bytes": 299837, "tx-dropped": 0}, "hardware-address": "00:52:11:36:3f:00"}, {"name": "Loopback Pseudo-Interface 1", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "::1", "prefix": 128}, {"ip-address-type": "ipv4", "ip-address": "127.0.0.1", "prefix": 8}], "statistics": {"tx-packets": 0, "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0, "tx-bytes": 0, "tx-dropped": 0}}]}
{"execute":"guest-network-get-interfaces"}
{"return": [{"name": "????", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "2620:52:0:4948:4c3d:1085:dc2d:8584", "prefix": 64}, {"ip-address-type": "ipv6", "ip-address": "fe80::4c3d:1085:dc2d:8584%5", "prefix": 64}, {"ip-address-type": "ipv4", "ip-address": "10.73.75.113", "prefix": 22}], "statistics": {"tx-packets": 1210, "tx-errs": 0, "rx-bytes": 529955, "rx-dropped": 0, "rx-packets": 951, "rx-errs": 0, "tx-bytes": 304785, "tx-dropped": 0}, "hardware-address": "00:52:11:36:3f:00"}, {"name": "Loopback Pseudo-Interface 1", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "::1", "prefix": 128}, {"ip-address-type": "ipv4", "ip-address": "127.0.0.1", "prefix": 8}], "statistics": {"tx-packets": 0, "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0, "tx-bytes": 0, "tx-dropped": 0}}]}
Comment 7 Bishara AbuHattoum 2019-08-21 07:03:30 UTC 
(In reply to xiagao from comment #6)
> Can reproduce with mingw-qemu-ga-win-100.0.0.0-3.el7ev
> 
> The nic interface name in chinese is changed to "???" via
> "guest-network-get-interfaces" guest agent cmd.
> 
> The following is the result of the NIC name in chinese, the first is "测试",
> the second is "红帽测试".
> {"execute":"guest-network-get-interfaces"}
> {"return": [{"name": "??", "ip-addresses": [{"ip-address-type": "ipv6",
> "ip-address": "2620:52:0:4948:4c3d:1085:dc2d:8584", "prefix": 64},
> {"ip-address-type": "ipv6", "ip-address": "fe80::4c3d:1085:dc2d:8584%5",
> "prefix": 64}, {"ip-address-type": "ipv4", "ip-address": "10.73.75.113",
> "prefix": 22}], "statistics": {"tx-packets": 1189, "tx-errs": 0, "rx-bytes":
> 507263, "rx-dropped": 0, "rx-packets": 933, "rx-errs": 0, "tx-bytes":
> 299837, "tx-dropped": 0}, "hardware-address": "00:52:11:36:3f:00"}, {"name":
> "Loopback Pseudo-Interface 1", "ip-addresses": [{"ip-address-type": "ipv6",
> "ip-address": "::1", "prefix": 128}, {"ip-address-type": "ipv4",
> "ip-address": "127.0.0.1", "prefix": 8}], "statistics": {"tx-packets": 0,
> "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0,
> "tx-bytes": 0, "tx-dropped": 0}}]}
> {"execute":"guest-network-get-interfaces"}
> {"return": [{"name": "????", "ip-addresses": [{"ip-address-type": "ipv6",
> "ip-address": "2620:52:0:4948:4c3d:1085:dc2d:8584", "prefix": 64},
> {"ip-address-type": "ipv6", "ip-address": "fe80::4c3d:1085:dc2d:8584%5",
> "prefix": 64}, {"ip-address-type": "ipv4", "ip-address": "10.73.75.113",
> "prefix": 22}], "statistics": {"tx-packets": 1210, "tx-errs": 0, "rx-bytes":
> 529955, "rx-dropped": 0, "rx-packets": 951, "rx-errs": 0, "tx-bytes":
> 304785, "tx-dropped": 0}, "hardware-address": "00:52:11:36:3f:00"}, {"name":
> "Loopback Pseudo-Interface 1", "ip-addresses": [{"ip-address-type": "ipv6",
> "ip-address": "::1", "prefix": 128}, {"ip-address-type": "ipv4",
> "ip-address": "127.0.0.1", "prefix": 8}], "statistics": {"tx-packets": 0,
> "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0,
> "tx-bytes": 0, "tx-dropped": 0}}]}

Yes, we are  aware of this issue.
Sent changes patch to qemu-devel:
https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg03564.html
Comment 8 Basil Salman 2019-10-31 13:18:05 UTC 
The build with the fix:
https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=995415
Comment 10 xiagao 2019-11-06 04:56:15 UTC 
(In reply to Basil Salman from comment #8)
> The build with the fix:
> https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=995415

I test with this build,but still hit this issue,the network is named "测试".

{"execute":"guest-network-get-interfaces"}
{"return": [{"name": "??", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "fe80::4450:cc:8d84:d48a%3", "prefix": 64}, {"ip-address-type": "ipv4", "ip-address": "10.73.75.87", "prefix": 22}], "statistics": {"tx-packets": 33518, "tx-errs": 0, "rx-bytes": 120006420, "rx-dropped": 0, "rx-packets": 61984, "rx-errs": 0, "tx-bytes": 8352964, "tx-dropped": 0}, "hardware-address": "00:52:11:36:3f:00"}, {"name": "Loopback Pseudo-Interface 1", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "::1", "prefix": 128}, {"ip-address-type": "ipv4", "ip-address": "127.0.0.1", "prefix": 8}], "statistics": {"tx-packets": 0, "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0, "tx-bytes": 0, "tx-dropped": 0}}, {"name": "isatap.lab.eng.pek2.redhat.com", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "fe80::5efe:10.73.75.87%7", "prefix": 128}], "statistics": {"tx-packets": 0, "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0, "tx-bytes": 0, "tx-dropped": 0}, "hardware-address": "00:00:00:00:00:00"}]}
Comment 11 Su, Jun-Ming 2019-11-06 06:12:26 UTC 
(In reply to Basil Salman from comment #8)
> The build with the fix:
> https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=995415

Hi, 

can this build be tested from others (like me)?

I can access this site o get the build.

Thanks.
Comment 13 Basil Salman 2019-11-11 23:04:08 UTC 
(In reply to xiagao from comment #10)
> (In reply to Basil Salman from comment #8)
> > The build with the fix:
> > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=995415
> 
> I test with this build,but still hit this issue,the network is named "测试".
> 
> {"execute":"guest-network-get-interfaces"}
> {"return": [{"name": "??", "ip-addresses": [{"ip-address-type": "ipv6",
> "ip-address": "fe80::4450:cc:8d84:d48a%3", "prefix": 64},
> {"ip-address-type": "ipv4", "ip-address": "10.73.75.87", "prefix": 22}],
> "statistics": {"tx-packets": 33518, "tx-errs": 0, "rx-bytes": 120006420,
> "rx-dropped": 0, "rx-packets": 61984, "rx-errs": 0, "tx-bytes": 8352964,
> "tx-dropped": 0}, "hardware-address": "00:52:11:36:3f:00"}, {"name":
> "Loopback Pseudo-Interface 1", "ip-addresses": [{"ip-address-type": "ipv6",
> "ip-address": "::1", "prefix": 128}, {"ip-address-type": "ipv4",
> "ip-address": "127.0.0.1", "prefix": 8}], "statistics": {"tx-packets": 0,
> "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0,
> "tx-bytes": 0, "tx-dropped": 0}}, {"name": "isatap.lab.eng.pek2.redhat.com",
> "ip-addresses": [{"ip-address-type": "ipv6", "ip-address":
> "fe80::5efe:10.73.75.87%7", "prefix": 128}], "statistics": {"tx-packets": 0,
> "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0,
> "tx-bytes": 0, "tx-dropped": 0}, "hardware-address": "00:00:00:00:00:00"}]}

Can you confirm this build fixes the issue:
https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1007350


I tested it myself with network name '喔喔喔' and i think that the issue is fixed:
{"execute":"guest-network-get-interfaces"}
{"return": [{"name": "\u5594\u5594\u5594", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "fe80::64c5:2f6a:d6c2:4752%7", "prefix": 64}, {"ip-address-type": "ipv4", "ip-address": "10.0.1.2", "prefix": 16}], "statistics": {"tx-packets": 91746, "tx-errs": 0, "rx-bytes": 154917677, "rx-dropped": 0, "rx-packets": 92226, "rx-errs": 0, "tx-bytes": 10544102, "tx-dropped": 0}, "hardware-addre": "52:4c:c1:61:cc:c3"}, {"name": "Loopback Pseudo-Interface 1", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "::1", "prefix": 128}, {"ip-address-type": "ipv4", "ip-address": "127.0.0.1 "prefix": 8}], "statistics": {"tx-packets": 0, "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0, "tx-bytes": 0, "tx-dropped": 0}}]}
Comment 14 xiagao 2019-11-12 03:20:36 UTC 
Verify this bug with mingw-qemu-ga-win-101.0.0.1-4.el7ev pkg.

network name is "测试(ABCD)"
{"execute":"guest-network-get-interfaces"}
{"return": [{"name": "\u6D4B\u8BD5(ABCD)", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "2620:52:0:4948:947c:6e7d:3d6c:864d", "prefix": 64}, {"ip-address-type": "ipv6", "ip-address": "fe80::947c:6e7d:3d6c:864d%14", "prefix": 64}, {"ip-address-type": "ipv4", "ip-address": "10.73.75.87", "prefix": 22}], "statistics": {"tx-packets": 3116, "tx-errs": 0, "rx-bytes": 7324880, "rx-dropped": 0, "rx-packets": 6768, "rx-errs": 0, "tx-bytes": 874122, "tx-dropped": 0}, "hardware-address": "00:52:11:36:3f:00"}, {"name": "Loopback Pseudo-Interface 1", "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "::1", "prefix": 128}, {"ip-address-type": "ipv4", "ip-address": "127.0.0.1", "prefix": 8}], "statistics": {"tx-packets": 0, "tx-errs": 0, "rx-bytes": 0, "rx-dropped": 0, "rx-packets": 0, "rx-errs": 0, "tx-bytes": 0, "tx-dropped": 0}}]}
Comment 15 Su, Jun-Ming 2019-11-12 04:44:17 UTC 
> Can you confirm this build fixes the issue:
> https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1007350
> 
> 
> I tested it myself with network name '喔喔喔' and i think that the issue is
> fixed:
> {"execute":"guest-network-get-interfaces"}
> {"return": [{"name": "\u5594\u5594\u5594", "ip-addresses":
> [{"ip-address-type": "ipv6", "ip-address": "fe80::64c5:2f6a:d6c2:4752%7",
> "prefix": 64}, {"ip-address-type": "ipv4", "ip-address": "10.0.1.2",
> "prefix": 16}], "statistics": {"tx-packets": 91746, "tx-errs": 0,
> "rx-bytes": 154917677, "rx-dropped": 0, "rx-packets": 92226, "rx-errs": 0,
> "tx-bytes": 10544102, "tx-dropped": 0}, "hardware-addre":
> "52:4c:c1:61:cc:c3"}, {"name": "Loopback Pseudo-Interface 1",
> "ip-addresses": [{"ip-address-type": "ipv6", "ip-address": "::1", "prefix":
> 128}, {"ip-address-type": "ipv4", "ip-address": "127.0.0.1 "prefix": 8}],
> "statistics": {"tx-packets": 0, "tx-errs": 0, "rx-bytes": 0, "rx-dropped":
> 0, "rx-packets": 0, "rx-errs": 0, "tx-bytes": 0, "tx-dropped": 0}}]}

I can not download this build, but it seems fixed for the result.
Comment 17 errata-xmlrpc 2020-02-04 12:27:28 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:0351
Note You need to log in before you can comment on or make changes to this bug.