Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

Bug #1794478 reported by bugproxy
22
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Fix Released
Undecided
Canonical Foundations Team
network-manager (Ubuntu)
Fix Released
High
Unassigned
Bionic
Fix Released
High
Seyeong Kim

Bug Description

[Impact]

In case creating bond interface, IPv4 address is not automatically assigned when IPv6 has manual setting.

[Test Case]

1. create 18.04.4 instance, network-manager version is 1.10.6-2ubuntu.1.2 as original description.
2. ipv6 manual, ipv4 auto
##################################
sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, updelay=0";
sudo nmcli con mod bond0 ipv6.method manual ipv6.addresses fe81::ff:fe97:a27f/64;
sudo nmcli con mod bond0 ipv4.method auto;
sudo nmcli con add type bond-slave ifname ens34 master bond0;
sudo nmcli con add type bond-slave ifname ens35 master bond0;
sudo nmcli con mod bond0 +bond.options mii=100

sleep 5

sudo nmcli con up bond-slave-ens34
sudo nmcli con up bond-slave-ens35
sudo nmcli con up bond0;

sleep 5;
sudo nmcli c s bond0
##################################
3. ipv6 auto, ipv4 auto
##################################
sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, updelay=0";
sudo nmcli con mod bond0 ipv6.method auto;
sudo nmcli con mod bond0 ipv4.method auto;
sudo nmcli con add type bond-slave ifname ens34 master bond0;
sudo nmcli con add type bond-slave ifname ens35 master bond0;
sudo nmcli con mod bond0 +bond.options mii=100

sleep 5

sudo nmcli con up bond-slave-ens34
sudo nmcli con up bond-slave-ens35
sudo nmcli con up bond0;

sleep 5

sudo nmcli c s bond0
##################################

when run #3, it is working, but with #2, it is not working.

[Potential Regression]

Actually nothing special. fix just remove if statement. but it needs Network Manager restarted.

[Other informations]

After upstream fix, it is working fine with #2 and #3 above.

* Upstream bug and fix:

https://bugzilla.redhat.com/show_bug.cgi?id=1575944
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35

* Only affecting Bionic:

$ git describe --contains f03ae35
1.10.8~2

$ rmadison network-manager
==> network-manager | 1.10.6-2ubuntu1.2 | bionic-updates
    network-manager | 1.20.4-2ubuntu2.2 | eoan-updates
    network-manager | 1.22.4-1ubuntu2 | focal

[Original description]

---Problem Description---
Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get automatic ipv4 assigned from dhcp server.

---uname output---
Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 s390x s390x s390x GNU/Linux

Machine Type = s390x

---Debugger---
A debugger is not configured

---Steps to Reproduce---
 When user configures ipv4 as automatic and ipv6 as manual for bond interface automatic ipv4 is not getting assigned.
Looks like dhcp client request for ipv4 is not done to dhcp server after maunal ipv6 is assigned quickly to bond interface

This issue will not happen in below cases:
1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan interface.
2)with ipv4 automatic and ipv6 automatic configuration for bond interface
3)with ipv4 automatic and ipv6 disabled configuration for bond interface

Configuration:
Bond interface, ipv4 automatic mode and ipv6 automatic mode

root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
[connection]
id=test_bond
uuid=63e54542-5135-47ac-a954-b861c3937be2
type=bond
interface-name=test_bond
permissions=
timestamp=1537944121

[ethernet]
mac-address-blacklist=

[bond]
downdelay=0
fail_over_mac=none
miimon=100
mode=active-backup
num_grat_arp=0
primary_reselect=always
updelay=0

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

From /var/log/syslog, we can see ip got assigned:

Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 10.2.3.1
Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1

root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
28: test_bond: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
    inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute test_bond
       valid_lft 353sec preferred_lft 353sec
    inet6 fe80::ff:feb3:b522/64 scope link
       valid_lft forever preferred_lft forever

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Bond interface, ipv4 automatic mode and ipv6 manual mode

root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
[connection]
id=test_bond
uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab
type=bond
interface-name=test_bond
permissions=
timestamp=1537943300

[ethernet]
mac-address-blacklist=

[bond]
downdelay=0
fail_over_mac=none
miimon=100
mode=active-backup
num_grat_arp=0
primary_reselect=always
updelay=0

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
address1=fe81::32a5:bc5f:287f:8db8/64
dns-search=
method=manual

No automatic ip assigned to ipv4 and no requests to dhcp server seen in /var/log/syslog
root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
29: test_bond: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
    inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

==> Correct LP-Package need to be assigned...!

bugproxy (bugproxy)
tags: added: architecture-s39064 bugnameltc-171765 severity-high targetmilestone-inin---
Changed in ubuntu:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
affects: ubuntu → linux (Ubuntu)
bugproxy (bugproxy)
tags: added: targetmilestone-inin1804
removed: targetmilestone-inin---
Revision history for this message
Frank Heimes (fheimes) wrote :

Which dhcp client is used? (affected package)
Notice that network-manager is not supported on Ubuntu Server 18.04,
please consider to move to netplan and networkd.
For now assuming that this is related to DHCP rather than nw mgr.

affects: linux (Ubuntu) → dhcpcd (Ubuntu)
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
assignee: nobody → Canonical Foundations Team (canonical-foundations)
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2018-10-01 04:59 EDT-------
dhcp client package details:

root@NetworkTest:~# dpkg -l | grep dhcp-client
ii isc-dhcp-client 4.3.5-3ubuntu7 s390x DHCP client for automatically obtaining an IP address

Revision history for this message
Steve Langasek (vorlon) wrote :

This is not reproducible with netplan in an Ubuntu 18.04 container (on an Ubuntu cosmic host). With the following netplan config:

$ cat /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        eth0:
            dhcp4: false
    bridges:
      br0:
          interfaces: [eth0]
          dhcp4: true
          addresses: ["fe81::32a5:bc5f:287f:8db8/64"]
$

The container network comes up with:

$ ip addr show dev br0
2: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether da:af:7e:76:48:8a brd ff:ff:ff:ff:ff:ff
    inet 10.141.225.180/24 brd 10.141.225.255 scope global dynamic br0
       valid_lft 3341sec preferred_lft 3341sec
    inet6 fd42:c560:e275:f583:d8af:7eff:fe76:488a/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 3340sec preferred_lft 3340sec
    inet6 fe81::32a5:bc5f:287f:8db8/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::d8af:7eff:fe76:488a/64 scope link
       valid_lft forever preferred_lft forever
$

As NetworkManager is not the supported network renderer for Ubuntu Server, please provide a reproducer for this using netplan and systemd-networkd.

affects: dhcpcd (Ubuntu) → network-manager (Ubuntu)
Changed in network-manager (Ubuntu):
status: New → Incomplete
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: New → Incomplete
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2018-10-04 05:03 EDT-------
Vorlon,

Yes i agree that nmcli is being used by me for managing the interfaces.
The issue is not seen with ETHERNET and VLAN type of interfaces.
This is happening only with BOND interfaces (auto ipv4 and manual ipv6 assigned.) Is is possible for you to try with this configuration and check? If its not happening then probably its a nmcli bug?

I have to yet work on netplan tool and see if i can reproduce.

Revision history for this message
Steve Langasek (vorlon) wrote :

Indeed, sorry about that, I overlooked that this was on a bond and tested with a bridge instead.

Here are the results with a bond:

$ cat /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        eth0:
            dhcp4: false
    bonds:
        bond0:
            interfaces: [eth0]
            dhcp4: yes
            addresses: ["fe81::32a5:bc5f:287f:8db8/64"]
$ ip addr show dev bond0
2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a2:83:94:5d:cc:de brd ff:ff:ff:ff:ff:ff
    inet 10.141.225.183/24 brd 10.141.225.255 scope global dynamic bond0
       valid_lft 3540sec preferred_lft 3540sec
    inet6 fe81::32a5:bc5f:287f:8db8/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::a083:94ff:fe5d:ccde/64 scope link
       valid_lft forever preferred_lft forever
$

Again, the dhcp4 address and the static ipv6 address are both present.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The issue looks like it could be what is fixed by https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/34ca1680 (the change is included in 1.10.8 which is currently not yet in bionic but being SRUed)

Revision history for this message
Eric Desrochers (slashd) wrote :

The new stable version indicate the fix mentioned by seb128 is there but no indication has been made in the debian/changelog to automatically change the status, which breaks the SRU machinery for this particular bug.

--- network-manager-1.10.6/src/nm-manager.c 2018-03-12 08:59:48.000000000 -0400
+++ network-manager-1.10.14/src/nm-manager.c 2018-11-20 05:23:31.000000000 -0500

+ if ( old_state == NM_DEVICE_STATE_UNMANAGED
+ && new_state > NM_DEVICE_STATE_UNMANAGED)
+ retry_connections_for_parent_device (self, device);
+

I'll change the bug status from "Incomplete" to "Fix Committed" as the package is now found in bionic-proposed.

- Eric

Changed in network-manager (Ubuntu):
status: Incomplete → Fix Committed
assignee: Skipper Bug Screeners (skipper-screen-team) → Olivier Tilloy (osomon)
tags: added: verification-needed verification-needed-bionic
Eric Desrochers (slashd)
Changed in network-manager (Ubuntu Bionic):
status: New → Fix Committed
Changed in network-manager (Ubuntu):
status: Fix Committed → Fix Released
Changed in network-manager (Ubuntu Bionic):
assignee: nobody → Olivier Tilloy (osomon)
Changed in network-manager (Ubuntu):
assignee: Olivier Tilloy (osomon) → nobody
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: Incomplete → Fix Committed
Revision history for this message
Sebastien Bacher (seb128) wrote :

> The new stable version indicate the fix mentioned by seb128 is there but no indication has been made in
> the debian/changelog to automatically change the status, which breaks the SRU machinery for this
> particular bug.

@Eric, I didn't handle it ine SRU because I don't understand the issue enough to be confident it's fixed in that update, I was just adding a side comment because the change looks like it could impact on the behaviour described there. Did you confirm the SRU does address the problem and that it's indeed fix commited? (and that it's really resolved in newer series)

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2019-04-04 09:01 EDT-------
Basic testing is done on the image and it looks good.

Will be doing more testing and get back if any issues.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2019-04-23 04:08 EDT-------
The fix has worked , tested and we did not notice any other issues during the test.

Revision history for this message
Frank Heimes (fheimes) wrote :

Adjusting tags according to comments #9 and #10.

tags: added: verification-done verification-done-bionic
removed: verification-needed verification-needed-bionic
Changed in network-manager (Ubuntu Bionic):
status: Fix Committed → Fix Released
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: Fix Committed → Fix Released
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2019-05-14 11:09 EDT-------
IBM bugzilla status -> closed, Fix Released with Bionic..

Revision history for this message
Pedro Principeza (pprincipeza) wrote :

Hi, all. I'm afraid I'll need to reopen this bug.

I was able to reproduce the issue on Bionic, using network-manager 1.10.6-2ubuntu1.2. However, when testing this on Eoan, using network-manager 1.20.4-2ubuntu2, I didn't reproduce the behaviour.

The steps one takes to reproduce the issue, either on a s390 system or x86 (the issue is reproducible regardless of the platform) is:

1.) Create the bond interface with:
nmcli conn add type bond con-name <name> ifname <device> ipv4.method disabled ipv6.method ignore

2.) Modify it to so set a manual IPv6 Address and auto-assign IPv4:
nmcli c m <uuid> bond.options " mode=active-backup, downdelay=0 , miimon=100 , updelay=0 , fail_over_mac=none , num_grat_arp=0 , primary_reselect=always " connection.interface-name <device name> ipv4.method auto ipv4.gateway "" ipv6.method manual 802-3-ethernet.mac-address "" ipv4.routes "" connection.id <connection name> ipv6.never-default no ipv4.addresses "" ipv6.addresses <provide manual ipv6>

3.) Add the two slave ethernet devices, and change them with:

nmcli c m <uuid> connection.id <ethernet device id> connection.interface-name <ethernet connection name> 802-3-ethernet.s390-subchannels <device subchannels> 802-3-ethernet.s390-nettype qeth connection.autoconnect yes 802-3-ethernet.mac-address "" ipv4.method disabled ipv6.method ignore 802-3-ethernet.s390-options portno=<valid portno>

^ For repro steps on amd64 or ppc64, the s390-* parameters can be removed from the command.

4.) Add the two slave ethernet devices to the bond:

nmcli c m <slave uuid> 802-3-ethernet.mac-address "" connection.master <master uuid> connection.slave-type bond

[ . . . ]

You'll see that, on Bionic, the bond interface isn't assigned an IPv4 address. On Eoan, an IPv4 address is assigned as expected.

I have reviewed network-manager's changelog [1], but I didn't find any smoking guns that could've solved the issue, hence the re-opening of the bug.

Let me know if further evidence is needed to proceed. Thanks!

[1] https://changelogs.ubuntu.com/changelogs/pool/main/n/network-manager/network-manager_1.20.4-2ubuntu2/changelog

Revision history for this message
Pedro Principeza (pprincipeza) wrote :

Changed the status to New, since I was still able to reproduce the issue on Bionic, using the "patched" network-manager version.

Changed in network-manager (Ubuntu):
status: Fix Released → New
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2019-12-10 10:31 EDT-------
Re-opened bugzilla, problem still not fixed

Eric Desrochers (slashd)
Changed in network-manager (Ubuntu Bionic):
status: Fix Released → Confirmed
Changed in network-manager (Ubuntu):
status: New → Fix Released
Revision history for this message
Eric Desrochers (slashd) wrote :

Setting 'bionic' from "Fix Released" to "Confirmed" since 2 different persons stated the problem still exist (supported with reproducer testing)

Olivier Tilloy (osomon)
Changed in network-manager (Ubuntu Bionic):
assignee: Olivier Tilloy (osomon) → Till Kamppeter (till-kamppeter)
Eric Desrochers (slashd)
Changed in network-manager (Ubuntu Bionic):
importance: Undecided → High
Changed in network-manager (Ubuntu Bionic):
assignee: Till Kamppeter (till-kamppeter) → nobody
Revision history for this message
Eric Desrochers (slashd) wrote :

This look like a similar issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1575944
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35

A test package (including the above fix) is available on my PPA:
sudo add-apt-repository ppa:slashd/lp1794478
sudo apt-get update

Please let me know the outcome.

- Eric

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-02-14 12:51 EDT-------
Eric,

network-manager 1.10.6-2ubuntu1.3+testpkg20201202b1 fix provided is Working good.

Network connection with auto ipv4 mode and manual ipv6 mode is NOW rightly setting ipv4 from server and manual ipv6.

Deactivated and Activated the network connection to see both ips are still retained. No issues seen here.

restart of network manager also the ips are retained.

------- Comment From <email address hidden> 2020-02-14 12:59 EDT-------
nmcli c s for bond device , the output parameters being watched are now as expected

ipv4.method: auto
ipv6.method: manual
ipv6.addresses: fe81::ff:fe97:a27f/64
GENERAL.STATE: activated
IP4.ADDRESS[1]: 10.2.3.60/24
IP6.ADDRESS[1]: fe81::ff:fe97:a27f/64

Revision history for this message
Eric Desrochers (slashd) wrote :

Thanks for reporting the outcome of your test.

We will start the SRU process in order to update network-manager package next week.

Regards,

Eric

Eric Desrochers (slashd)
description: updated
description: updated
description: updated
Revision history for this message
Seyeong Kim (seyeongkim) wrote :

I uploaded patch for bionic sru. but I didn't subscribe sru-sponsors yet because I'm still confirming reproducer.

I'll update description after reproducing this issue in my local.

Thanks.

tags: added: sts
Changed in network-manager (Ubuntu Bionic):
assignee: nobody → Seyeong Kim (xtrusia)
Revision history for this message
Seyeong Kim (seyeongkim) wrote :
Revision history for this message
bugproxy (bugproxy) wrote : lp1794478_bionic.debdiff

Default Comment by Bridge

Seyeong Kim (seyeongkim)
description: updated
Revision history for this message
bugproxy (bugproxy) wrote :

Default Comment by Bridge

Revision history for this message
Seyeong Kim (seyeongkim) wrote :

why bugproxy keep attaching old debdiff I've changed

Mathew Hodson (mhodson)
Changed in network-manager (Ubuntu):
importance: Undecided → High
Revision history for this message
Eric Desrochers (slashd) wrote :

@xtrusia,

Is this ready for sponsorship ?

I'll have a look when ready.

- Eric

Eric Desrochers (slashd)
Changed in network-manager (Ubuntu Bionic):
status: Confirmed → In Progress
tags: added: sts-sponsor-dgadomski
Revision history for this message
Eric Desrochers (slashd) wrote :

Sponsored by dgadomski. Unsubscribing sts-sponsor team.

Thanks for your contribution Seyeong.
Thanks for the sponsoring Dariusz.

- Eric

Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello bugproxy, or anyone else affected,

Accepted network-manager into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/network-manager/1.10.6-2ubuntu1.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in network-manager (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-bionic
removed: verification-done verification-done-bionic
Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (network-manager/1.10.6-2ubuntu1.4)

All autopkgtests for the newly accepted network-manager (1.10.6-2ubuntu1.4) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/237-3ubuntu10.39 (i386)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#network-manager

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message
Seyeong Kim (seyeongkim) wrote :

Hello

I've verified this -proposed pkg on my local.

#2 on description working fine.

xtrusia@ubuntu:~$ dpkg -l | grep network-manager
ii network-manager 1.10.6-2ubuntu1.4 amd64 network management framework (daemon and userspace tools)
ii network-manager-config-connectivity-ubuntu 1.10.6-2ubuntu1.2 all NetworkManager configuration to enable connectivity checking
ii network-manager-gnome 1.8.10-2ubuntu3 amd64 network management framework (GNOME frontend)
ii network-manager-pptp 1.2.6-1 amd64 network management framework (PPTP plugin core)
ii network-manager-pptp-gnome 1.2.6-1 amd64 network management framework (PPTP plugin GNOME GUI)

tags: added: verification-done-bionic
removed: verification-needed-bionic
Frank Heimes (fheimes)
tags: added: verification-done
removed: verification-needed
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2020-03-04 08:55 EDT-------
The network manager fix provided is working fine.

The version on the tested machine is as below:
root@NetworkTest:/usr/local/zACI/test/suites/net/web# dpkg -l | grep 1.10.6-2ubuntu1.4
ii libnm0:s390x 1.10.6-2ubuntu1.4 s390x GObject-based client library for NetworkManager
ii network-manager 1.10.6-2ubuntu1.4 s390x network management framework (daemon and userspace tools)
root@ABHIRAM:/usr/local/zACI/test/suites/net/web#

Ok with changing the tag from verification-needed-bionic to verification-done-bionic

Revision history for this message
Frank Heimes (fheimes) wrote :

Thx '<email address hidden>' for verification - the tags are set to done.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 1.10.6-2ubuntu1.4

---------------
network-manager (1.10.6-2ubuntu1.4) bionic; urgency=medium

  * d/p/start-ip-conf-when-master-carrier-goes-up.patch: device: start IP
    configuration when master carrier goes up (LP: #1794478)

network-manager (1.10.6-2ubuntu1.3) bionic; urgency=medium

  * d/t/control: nm test requires dnsmasq-base (LP: #1850267)
  * d/t/killswitches-no-urfkill, d/t/urfkill-integration,
    d/t/wpa-dhclient, d/t/nm, d/t/control:
    - skip tests on s390 due to missing wireless kernel support
      (LP: #1855009)

 -- Seyeong Kim <email address hidden> Wed, 19 Feb 2020 14:59:10 +0900

Changed in network-manager (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for network-manager has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2020-03-12 06:07 EDT-------
IBM Bugzilla status-> closed, delivered by the distro

Frank Heimes (fheimes)
tags: added: ssc
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.