Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1782686

Summary: Cannot disable IP stack when having on-going DHCP client
Product: Red Hat Enterprise Linux 8 Reporter: Gris Ge <fge>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: CLOSED NOTABUG QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 8.2CC: atragler, bgalvani, lrintel, rkhan, sukulkar, thaller
Target Milestone: rc   
Target Release: 8.2   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-12-17 06:45:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1738136, 1782680    
Attachments:
Description Flags
System logs with NM trace enabled
none
Reproduce script none

Description Gris Ge 2019-12-12 06:50:39 UTC 
Description of problem:


When activating a connection with `ipv4.method=disable` while previous DHCP
client does not finish yet, nmcli will got error:

Error: Connection activation failed: The base network connection was interrupted

Version-Release number of selected component (if applicable):
NetworkManager-1.22.0-0.2.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
1. ./nm_bug.sh
2.
3.

Actual results:
Error: Connection activation failed: The base network connection was interrupted

Expected results:

activation finished without error.

Additional info:

This issue is requested by VDSM/RHV, please prioritize.
Comment 1 Gris Ge 2019-12-12 07:04:45 UTC 
Created attachment 1644311 [details]
System logs with NM trace enabled
Comment 2 Gris Ge 2019-12-12 07:12:07 UTC 
Created attachment 1644312 [details]
Reproduce script
Comment 3 Beniamino Galvani 2019-12-16 10:46:40 UTC 
The script starts an activation in background and then a new
activation of the same connection:

 sudo nmcli c up eth1 &
 sleep 1
 sudo nmcli c modify eth1 ipv4.method disabled
 sudo nmcli c up eth1

When the second activation is started, the first one is canceled and
gives error DEVICE_DISCONNECTED (which corresponds to the message "The
base network connection was interrupted" displayed by the first nmcli
instance), while the second activation succeeds.

It seems correct to make the first activation fail when there is a new
one for the same connection. Note that the end of the script, the
interface is properly configured with ipv4.method=disabled, which is
the last configuration requested.

The update of connection with 'ipv4.method=disabled' doesn't seem to
matter, the same behavior is observed without the connection update.
Comment 4 Gris Ge 2019-12-16 11:25:19 UTC 
(In reply to Beniamino Galvani from comment #3)
> The script starts an activation in background and then a new
> activation of the same connection:
> 
>  sudo nmcli c up eth1 &
>  sleep 1
>  sudo nmcli c modify eth1 ipv4.method disabled
>  sudo nmcli c up eth1
> 
> When the second activation is started, the first one is canceled and
> gives error DEVICE_DISCONNECTED (which corresponds to the message "The
> base network connection was interrupted" displayed by the first nmcli
> instance), while the second activation succeeds.

In nmstate, the second activation failed. This bug is just demonstration 
the problem via nmcli.

> 
> It seems correct to make the first activation fail when there is a new
> one for the same connection. Note that the end of the script, the
> interface is properly configured with ipv4.method=disabled, which is
> the last configuration requested.
> 
> The update of connection with 'ipv4.method=disabled' doesn't seem to
> matter, the same behavior is observed without the connection update.
Comment 5 Beniamino Galvani 2019-12-16 12:44:05 UTC 
(In reply to Gris Ge from comment #4)
> In nmstate, the second activation failed. This bug is just demonstration 
> the problem via nmcli.

I don't see anything wrong in the log attached, the first activation
request is canceled and fails, the second activation succeeds.

Can you also share a NM log when using nmstate? Perhaps it is doing
something different from nmcli.
Comment 6 Gris Ge 2019-12-17 06:09:42 UTC 
(In reply to Beniamino Galvani from comment #5)
> (In reply to Gris Ge from comment #4)
> > In nmstate, the second activation failed. This bug is just demonstration 
> > the problem via nmcli.
> 
> I don't see anything wrong in the log attached, the first activation
> request is canceled and fails, the second activation succeeds.
> 
> Can you also share a NM log when using nmstate? Perhaps it is doing
> something different from nmcli.

I believe I found the root cause of it.
When we noticied a on-going activation, we wait on it instead of submit
new activate_async call.

Will work in nmstate and close this bug if works.
Comment 7 Gris Ge 2019-12-17 06:45:54 UTC 
Closing this bug, this is not a issue of NetworkManager and should be fixed by nmstate.