"Get Guest Adapters Info" returns unusable IP address if IPv6 is enabled

Bischoff commented 10 months ago

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:

    "output":
    {
        u'adapters': [{u'lan_owner': u'SYSTEM',
                       u'adapter_address': u'1000',
                       u'lan_name': u'VSC11590',
                       u'adapter_status': u'02',
                       u'mac_address': u'02:55:36:5D:48:57',
                       u'mac_ip_version': u'4',
                       u'mac_ip_address': u'9.152.85.152'}]
    }

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:

mac_count=7 

mac_address=01005E000001
mac_address_type=01
mac_status=00

mac_address=023AFC42002A
mac_address_type=00
mac_status=00
mac_ip_version=4
mac_ip_address=10.145.214.42

mac_address=023AFC42002A
mac_address_type=00
mac_status=00
mac_ip_version=6
mac_ip_address=2a07:de40:b208:2:3a:fcff:fe42:2a

mac_address=023AFC42002A
mac_address_type=00
mac_status=00
mac_ip_version=6
mac_ip_address=fe80::3a:fcff:fe42:2a

mac_address=333300000001
mac_address_type=01
mac_status=00

mac_address=3333FF42002A
mac_address_type=01
mac_status=00

mac_address=3333FFC48072
mac_address_type=01
mac_status=00

mac_info_end

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

zhshuj commented 9 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

Bischoff commented 9 months ago

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:

either Virtual_Network_Adapter_Query_Extended intentionally refrains from returning any IPv6 address if there is only the link-local
some obscure setting at your place that tells to ignore link-local addresses ?
or a simple bug ?

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.

zhshuj commented 9 months ago

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.

Bischoff commented 9 months ago

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.

zhshuj commented 9 months ago

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

Bischoff commented 9 months ago

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.

Bischoff commented 9 months ago

Issue resolved with minimal approach PR. Thanks everyone.

openmainframeproject / feilong

"Get Guest Adapters Info" returns unusable IP address if IPv6 is enabled #805

How to fix it?