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

Bischoff commented 7 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 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

Bischoff commented 5 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 5 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 5 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 5 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 5 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 5 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?