Bug 1763062 - device reapply when connection is not fully up does not work
Summary: device reapply when connection is not fully up does not work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-18 07:52 UTC by Filip Pokryvka
Modified: 2020-04-28 16:53 UTC (History)
9 users (show)

Fixed In Version: NetworkManager-1.22.0-0.2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:53:15 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1847 0 None None None 2020-04-28 16:53:41 UTC

Description Filip Pokryvka 2019-10-18 07:52:22 UTC
Description of problem:
device reapply when connection is not fully up does not work

Version-Release number of selected component (if applicable):
1.20.0-3.el8

How reproducible:
slow/no dhcp on eth4

Steps to Reproduce:
1. nmcli connection add type ethernet ifname eth4 con-name test
2. nmcli con mod id test ipv4.method manual ipv4.addresses 192.168.8.5/24
3. nmcli device reapply eth4

Actual results:
if DHCP server is slow enough and in step 3. eth4 is still getting IP configuration, then eth4 does not have static address:

Connection 'test' (83f86191-35dd-479d-b939-9d825ab70ba6) successfully added.
Error: Reapplying connection to device 'eth4' (/org/freedesktop/NetworkManager/Devices/8) failed: Device is not activated

Comment 4 Vladimir Benes 2020-02-11 10:12:43 UTC
to get proper DHCP reply I need sometimes to wait more than 60 seconds. Is that something we would like to solve here or should I file yet another bug?

so far test looks like this:
    @rhbz1763062
    @ver+=1.22
    @con_general_remove @teardown_testveth @dhcpd
    @device_reapply_routes
    Scenario: NM - device - reapply just routes
    * Prepare simulated test "testG" device
    * Execute "ip netns exec testG_ns kill -SIGSTOP $(cat /tmp/testG_ns.pid)"
    * Add a new connection of type "ethernet" and options "ifname testG con-name con_general"
    * Modify connection "con_general" changing options "ipv4.routes '192.168.5.0/24 192.168.99.111 1' ipv4.route-metric 21 ipv6.method static ipv6.addresses 2000::2/126 ipv6.routes '1010::1/128 2000::1 1'"
    * "Error.*" is not visible with command "nmcli device reapply testG" in "1" seconds
    * Execute "ip netns exec testG_ns kill -SIGCONT $(cat /tmp/testG_ns.pid)"
    When "connected" is visible with command "nmcli -g GENERAL.STATE dev show testG" in "25" seconds
    Then "1010::1 via 2000::1 dev testG\s+proto static\s+metric 1" is visible with command "ip -6 route" in "5" seconds
    And "2000::/126 dev testG\s+proto kernel\s+metric 1" is visible with command "ip -6 route"
    And "192.168.5.0/24 via 192.168.99.111 dev testG\s+proto static\s+metric" is visible with command "ip route"
    And "routers = 192.168.99.1" is visible with command "nmcli con show con_general" in "70" seconds
^^ here we have the long waiting period
    And "default via 192.168.99.1 dev testG\s+proto dhcp\s+metric 21" is visible with command "ip r"

test passes like this.

Comment 5 Beniamino Galvani 2020-02-11 17:04:44 UTC
The long timeout doesn't seem related to this bz. From the log the you provided:

 <info>  [1581414454.0367] audit: op="device-reapply" interface="testG" ifindex=93 args="ipv6.method,ipv6.routes,ipv6.addresses,ipv4.route-metric,ipv4.routes" pid=26382 uid=0 result="success"
 <info>  [1581414455.5971] device (testG): Activation: successful, device activated.
 <debug> [1581414455.6737] dhcp4 (testG): sent DISCOVER to 255.255.255.255
 <debug> [1581414459.9469] dhcp4 (testG): sent DISCOVER to 255.255.255.255
 <debug> [1581414468.7730] dhcp4 (testG): sent DISCOVER to 255.255.255.255
 ...
 <info>  [1581414481.5651] audit: op="connection-delete" uuid="06a90131-43ad-4529-913b-fefd0ca85ae1" name="con_general" pid=26537 uid=0 result="success"

So for some reason the server is not replying, or takes long time to respond. Maybe there are issues in the setup. I tried in a F30 VM and it succeeds immediately:

Scenario: NM - device - reapply just routes
    * Prepare simulated test "testG" device ... passed in 3.150s
    * Execute "ip netns exec testG_ns kill -SIGSTOP $(cat /tmp/testG_ns.pid)" ... passed in 0.306s
    * Add a new connection of type "ethernet" and options "ifname testG con-name con_general" ... passed in 0.157s
    * Modify connection "con_general" changing options "ipv4.routes '192.168.5.0/24 192.168.99.111 1' ipv4.route-metric 21 ipv6.method static ipv6.addresses 2000::2/126 ipv6.routes '1010::1/128 2000::1 1'" ... passed in 0.048s
    * "Error.*" is not visible with command "nmcli device reapply testG" in "1" seconds ... passed in 0.166s
    * Execute "ip netns exec testG_ns kill -SIGCONT $(cat /tmp/testG_ns.pid)" ... passed in 0.305s
    When "connected" is visible with command "nmcli -g GENERAL.STATE dev show testG" in "25" seconds ... passed in 2.372s
    Then "1010::1 via 2000::1 dev testG\s+proto static\s+metric 1" is visible with command "ip -6 route" in "5" seconds ... passed in 0.119s
    And "2000::/126 dev testG\s+proto kernel\s+metric 1" is visible with command "ip -6 route" ... passed in 0.118s
    And "192.168.5.0/24 via 192.168.99.111 dev testG\s+proto static\s+metric" is visible with command "ip route" ... passed in 0.123s
    And "routers = 192.168.99.1" is visible with command "nmcli con show con_general" in "70" seconds ... passed in 0.152s
    And "default via 192.168.99.1 dev testG\s+proto dhcp\s+metric 21" is visible with command "ip r" ... passed in 0.119s

Do you have a machine where the problem can be reproduced?

Comment 6 Vladimir Benes 2020-02-12 17:06:31 UTC
device_reapply_routes test altered to do reapply when the DHCP request is not yet done. This showed the bug and also shows the bug fix now.

Comment 8 errata-xmlrpc 2020-04-28 16:53:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1847


Note You need to log in before you can comment on or make changes to this bug.