Closed Bischoff closed 5 months ago
Yes, it's a valid issue.
I only wondering under what situation can Virtual_Network_Adapter_Query_Extended
output include the IPv6 address?
E.g. I have a z/VM guest which has NIC as following, seems it has an IPv6 address, but Virtual_Network_Adapter_Query_Extended
output doesn't include this IPv6 address, only IPv4.
2: enc1000: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 02:01:03:14:3d:b1 brd ff:ff:ff:ff:ff:ff
inet 172.26.3.11/17 brd 172.26.127.255 scope global noprefixroute enc1000
valid_lft forever preferred_lft forever
inet6 fe80::1:3ff:fe14:3db1/64 scope link
valid_lft forever preferred_lft forever
adapter_count=1
adapter_address=1000
port_type=0
extended_port_status=00
adapter_type=2
network_device_count=3
adapter_status=02
lan_owner=SYSTEM
lan_name=VSICIC
device_options=C1000000
router_status=00
mac_count=4
mac_address=01005E000001
mac_address_type=01
mac_status=00
mac_address=020103143DB1
mac_address_type=00
mac_status=00
mac_ip_version=4
mac_ip_address=172.26.3.11
mac_address=333300000001
mac_address_type=01
mac_status=00
mac_address=3333FF143DB1
mac_address_type=01
mac_status=00
mac_info_end
adapter_info_end
Hello,
fe80:...
is a link-local address, therefore unusable outside of this segment. That could be a reason for not returning it.
However if you look at the output I detailed in my original message, I get the fe80:...
address, in addition to routable addresses.
I can see a few possible explanations:
Virtual_Network_Adapter_Query_Extended
intentionally refrains from returning any IPv6 address if there is only the link-local Could you try getting a routable IPv6 address ? You need to set this up on your router. You might also try to fool the system by adding a routable static IPv6 address.
In any case, that does not change anything to the problem I mention, nor to the patch I propose.
Could you try getting a routable IPv6 address ? You need to set this up on your router. You might also try to fool the system by adding a routable static IPv6 address.
I will try but doubt my testing environment allows me to set a routable IPv6 address.
In any case, that does not change anything to the problem I mention, nor to the patch I propose.
Yes, I agree. Thank you.
For the static IPv6 "cheat", from the guest Linux:
# ip -6 address add 2a07:de40:b208:0:1:3ff:fe14:3db1/64 dev enc1000
This address will of course not be usable, but maybe that's enough to fool Virtual_Network_Adapter_Query_Extended
call.
For the static IPv6 "cheat", from the guest Linux:
# ip -6 address add 2a07:de40:b208:0:1:3ff:fe14:3db1/64 dev enc1000
This address will of course not be usable, but maybe that's enough to fool
Virtual_Network_Adapter_Query_Extended
call.
Thanks. I did this way, but still the Virtual_Network_Adapter_Query_Extended
output only contains version 4 IP address. Maybe there are other reasons.
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enc1000: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 02:01:03:14:3d:b1 brd ff:ff:ff:ff:ff:ff
inet 172.26.3.11/17 brd 172.26.127.255 scope global noprefixroute enc1000
valid_lft forever preferred_lft forever
inet6 2a07:de40:b208:0:1:3ff:fe14:3db1/64 scope global dadfailed tentative
valid_lft forever preferred_lft forever
inet6 fe80::1:3ff:fe14:3db1/64 scope link
valid_lft forever preferred_lft forever
# smcli Virtual_Network_Adapter_Query_Extended -T IAAS020F -k 'image_device_number=*'
adapter_count=1
adapter_address=1000
port_type=0
extended_port_status=00
adapter_type=2
network_device_count=3
adapter_status=02
lan_owner=SYSTEM
lan_name=VSICIC
device_options=C1000000
router_status=00
mac_count=4
mac_address=01005E000001
mac_address_type=01
mac_status=00
mac_address=020103143DB1
mac_address_type=00
mac_status=00
mac_ip_version=4
mac_ip_address=172.26.3.11
mac_address=333300000001
mac_address_type=01
mac_status=00
mac_address=3333FF143DB1
mac_address_type=01
mac_status=00
mac_info_end
adapter_info_end
Yes. This is indeed strange. I'm not sure how we could contact SMAPI developers to tell them about the issue.
I understand this is something that prevents you from properly testing with IPv6. Don't hesitate to ask me if you need any IPv6-related tests in the future.
Issue resolved with minimal approach PR. Thanks everyone.
If IPv6 is enabled on the Linux guest, the "Get guest adapters info" API call [1] has a tendancy to return a link-local IPv6 address.
This is an address that starts with
fe80:
and that is unusable from any host that is not directly on same (switched) link.=> If there is a router between the client and the guest, the address returned by "get guest adapters info" is unusable.
The problem is even deeper: a host adapter can have several IP addresses; several IPv4 and several IPv6. The current API method assumes each adapter is identified by only one address.
Typical output is:
but the last fields should be a list of addresses, ideally.
How to fix it?
SMAPI call
Virtual_Network_Adapter_Query_Extended
returns something like:The current code in
smtclient.py
overwrites every IP address in this output with the next one :crying_cat_face: .Solution 1 (breaks compatibility):
return a full list with all this information
[ {mac1, ip1, iptype1}, {mac2, ip2, iptype2} ...]
; this is the best solution as it matches both SMAPI and network reality.Solution 2: (keeps compatibility):
refrain from returning a link-local address for example by always stopping at first valid IP address (seems to be the IPv4).
I can provide a PR for whatever solution you prefer (including not listed).
[1] https://cloudlib4zvm.readthedocs.io/en/latest/restapi.html#get-guest-adapters-info