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 1442361

Summary: Guest network can't resume after link down/up the backend device
Product: Red Hat Enterprise Linux 7 Reporter: Zhengtong <zhengtli>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: atragler, bgalvani, fgiudici, lrintel, rkhan, sukulkar, thaller, vbenes, yilzhang, yiwei
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 13:22:08 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: 1470965    
Attachments:
Description Flags
Log of running "journalctl -u NetworkManager -b"
none
[PATCH] device: don't release external slaves on state change
none
RHEL7.3_networkmanager log
none
[PATCH v2] device: don't release external slaves on state change none

Description Zhengtong 2017-04-14 10:08:50 UTC 
Description of problem:
Refer to BZ1357738 , I set down the backend device(tap0) and set up again. the device still can't attach to the target bridge.

Version-Release number of selected component (if applicable):
Tried with both 
NetworkManager-1.4.0-3.el7.ppc64le and NetworkManager-1.8.0-0.4.rc1.el7.ppc64le

How reproducible:
3/3

Steps to Reproduce:
1.Boot up guest with the nic device.
2.Keep pinging guest from host until the end of step 5.
3.Set down the backend device
# ifconfig tap0 down
4.Set up the backend again
#ifconfig tap0 up
5. check the pinging output

Actual results:
ping process can't resume
and tap0 didn't attached back to switch automatively.
[root@ibm-p8-rhevm-17 ~]# brctl show
bridge name	bridge id		STP enabled	interfaces
switch		8000.98be9400a118	no		enP3p9s0f0
virbr0		8000.525400d7ee9c	yes		virbr0-nic

Expected results:
The device can attached back to switch automatively and the guest can be pinged through.

Additional info:

Guest bootcmd:
/usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -sandbox off  \
    -machine pseries  \
    -nodefaults  \
    -vga std  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/avocado_Dvh43d/monitor-qmpmonitor1-20170413-105600-LcVC8bYm,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/avocado_Dvh43d/monitor-catch_monitor-20170413-105600-LcVC8bYm,server,nowait \
    -mon chardev=qmp_id_catch_monitor,mode=control  \
    -chardev socket,id=serial_id_serial0,path=/var/tmp/avocado_Dvh43d/serial-serial0-20170413-105600-LcVC8bYm,server,nowait \
    -device spapr-vty,reg=0x30000000,chardev=serial_id_serial0 \
    -device nec-usb-xhci,id=usb1,bus=pci.0,addr=03 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=04 \
    -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/test/manual/rhel69-ppc64-virtio-scsi.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1 \
    -device virtio-net-pci,mac=9a:a5:a6:a7:a8:a9,id=idc9Q5Es,vectors=4,netdev=idsDEfU4,bus=pci.0,addr=05  \
    -netdev tap,id=idsDEfU4,vhost=on \
    -m 8192  \
    -smp 4,cores=2,threads=1,sockets=2 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -device usb-mouse \
    -device usb-kbd \
    -vnc :0  \
    -rtc base=utc,clock=host  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -monitor stdio \
    -enable-kvm
Comment 2 Zhengtong 2017-04-14 10:09:39 UTC 
Only happens on ppc64le platform
Comment 3 Beniamino Galvani 2017-04-21 07:39:59 UTC 
Hi,

can you please:

 1. run 'nmcli general logging level trace'
 2. attach the output of 'ip a' before setting tap0 down
 3. set tap0 down and up again
 4. verify that the bug is reproduced, i.e. you can't ping the VM
 5. attach again the output of 'ip a'
 6. also attach the output of 'journalctl -u NetworkManager -b'

? Thanks!
Comment 4 Zhengtong 2017-04-24 02:21:52 UTC 
(In reply to Beniamino Galvani from comment #3)
> Hi,
> 
> can you please:
> 
>  1. run 'nmcli general logging level trace'
>  2. attach the output of 'ip a' before setting tap0 down
>  3. set tap0 down and up again
>  4. verify that the bug is reproduced, i.e. you can't ping the VM
>  5. attach again the output of 'ip a'
>  6. also attach the output of 'journalctl -u NetworkManager -b'
> 
> ? 
Will update the info after testing ASAIC
Comment 5 Zhengtong 2017-04-24 03:28:07 UTC 
Hi Beniamino, My original testing machine has been returned to beaker, So the environment was lost. I tried again with the latest qemu-kvm-rhev package(qemu-kvm-rhev-2.9.0-1) and  NetworkManager-1.8.0-0.4.rc1.el7.ppc64le, failed to reproduce the problem.I tried switching NeworkManager package, still failed to reproduce. So I think you can close this bug now. I will keep the environment if I hit the issue again, thanks.
Comment 6 yilzhang 2017-06-19 07:51:55 UTC 
Created attachment 1289031 [details]
Log of running "journalctl -u NetworkManager -b"
Comment 7 yilzhang 2017-06-19 08:21:24 UTC 
This bug is hit again on the following version of conponents:
qemu-kvm-rhev-2.9.0-10.el7.ppc64le
NetworkManager-1.8.0-9.el7.ppc64le



(In reply to Beniamino Galvani from comment #3)
> Hi,
> 
> can you please:
> 
>  1. run 'nmcli general logging level trace'
>  2. attach the output of 'ip a' before setting tap0 down
[root@ibm-p8-08 yilzhang]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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: enP5p1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be945cfdb4 state DOWN qlen 1000
    link/ether 98:be:94:5c:fd:b4 brd ff:ff:ff:ff:ff:ff
3: enP5p1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be945cfdb5 state DOWN qlen 1000
    link/ether 98:be:94:5c:fd:b5 brd ff:ff:ff:ff:ff:ff
4: enP5p1s0f2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be945cfdb6 state DOWN qlen 1000
    link/ether 98:be:94:5c:fd:b6 brd ff:ff:ff:ff:ff:ff
5: enP5p1s0f3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be945cfdb7 state DOWN qlen 1000
    link/ether 98:be:94:5c:fd:b7 brd ff:ff:ff:ff:ff:ff
6: enP6p1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be9459ee34 state DOWN qlen 1000
    link/ether 98:be:94:59:ee:34 brd ff:ff:ff:ff:ff:ff
7: enP6p1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be9459ee35 state DOWN qlen 1000
    link/ether 98:be:94:59:ee:35 brd ff:ff:ff:ff:ff:ff
8: enP6p1s0f2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be9459ee36 state DOWN qlen 1000
    link/ether 98:be:94:59:ee:36 brd ff:ff:ff:ff:ff:ff
9: enP6p1s0f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master switch portid 98be9459ee37 state UP qlen 1000
    link/ether 98:be:94:59:ee:37 brd ff:ff:ff:ff:ff:ff
11: switch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 98:be:94:59:ee:37 brd ff:ff:ff:ff:ff:ff
    inet 10.16.42.52/21 brd 10.16.47.255 scope global dynamic switch
       valid_lft 79834sec preferred_lft 79834sec
    inet6 2620:52:0:102f:8f5:e2ff:fec3:8dd5/64 scope global mngtmpaddr dynamic 
       valid_lft 2591235sec preferred_lft 604035sec
    inet6 2620:52:0:102f:887f:c9ff:fe4f:88c8/64 scope global mngtmpaddr dynamic 
       valid_lft 2588808sec preferred_lft 601608sec
    inet6 2620:52:0:102f:9abe:94ff:fe59:ee37/64 scope global mngtmpaddr dynamic 
       valid_lft 2591931sec preferred_lft 604731sec
    inet6 fe80::d893:1eff:febb:c29/64 scope link 
       valid_lft forever preferred_lft forever
20: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master switch state UNKNOWN qlen 1000
    link/ether fa:49:c6:71:98:7c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f849:c6ff:fe71:987c/64 scope link 
       valid_lft forever preferred_lft forever



>  3. set tap0 down and up again
>  4. verify that the bug is reproduced, i.e. you can't ping the VM
>  5. attach again the output of 'ip a'
[root@ibm-p8-08 yilzhang]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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: enP5p1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be945cfdb4 state DOWN qlen 1000
    link/ether 98:be:94:5c:fd:b4 brd ff:ff:ff:ff:ff:ff
3: enP5p1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be945cfdb5 state DOWN qlen 1000
    link/ether 98:be:94:5c:fd:b5 brd ff:ff:ff:ff:ff:ff
4: enP5p1s0f2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be945cfdb6 state DOWN qlen 1000
    link/ether 98:be:94:5c:fd:b6 brd ff:ff:ff:ff:ff:ff
5: enP5p1s0f3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be945cfdb7 state DOWN qlen 1000
    link/ether 98:be:94:5c:fd:b7 brd ff:ff:ff:ff:ff:ff
6: enP6p1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be9459ee34 state DOWN qlen 1000
    link/ether 98:be:94:59:ee:34 brd ff:ff:ff:ff:ff:ff
7: enP6p1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be9459ee35 state DOWN qlen 1000
    link/ether 98:be:94:59:ee:35 brd ff:ff:ff:ff:ff:ff
8: enP6p1s0f2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq portid 98be9459ee36 state DOWN qlen 1000
    link/ether 98:be:94:59:ee:36 brd ff:ff:ff:ff:ff:ff
9: enP6p1s0f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master switch portid 98be9459ee37 state UP qlen 1000
    link/ether 98:be:94:59:ee:37 brd ff:ff:ff:ff:ff:ff
11: switch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 98:be:94:59:ee:37 brd ff:ff:ff:ff:ff:ff
    inet 10.16.42.52/21 brd 10.16.47.255 scope global dynamic switch
       valid_lft 79638sec preferred_lft 79638sec
    inet6 2620:52:0:102f:8f5:e2ff:fec3:8dd5/64 scope global mngtmpaddr dynamic 
       valid_lft 2591040sec preferred_lft 603840sec
    inet6 2620:52:0:102f:887f:c9ff:fe4f:88c8/64 scope global mngtmpaddr dynamic 
       valid_lft 2588612sec preferred_lft 601412sec
    inet6 2620:52:0:102f:9abe:94ff:fe59:ee37/64 scope global mngtmpaddr dynamic 
       valid_lft 2591826sec preferred_lft 604626sec
    inet6 fe80::d893:1eff:febb:c29/64 scope link 
       valid_lft forever preferred_lft forever
20: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether fa:49:c6:71:98:7c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f849:c6ff:fe71:987c/64 scope link 
       valid_lft forever preferred_lft forever


>  6. also attach the output of 'journalctl -u NetworkManager -b'
The output is in the attachment (see Comment 6)
> 
> ? Thanks!
Comment 8 Beniamino Galvani 2017-07-05 16:24:55 UTC 
Hi,

thanks for providing logs. the following script:

  nmcli connection add type bridge ifname br1 con-name br1+ ipv4.method disabled ipv6.method ignore autoconnect no
  nmcli connection up br1+
  ip tuntap add mode tap tap0
  ip l set tap0 up
  ip l set tap0 master br1
  sleep 1
  ip l set tap0 down
  sleep 1
  ip l show tap0
  # tap0 should be still enslaved to br1

should reproduce the issue you are seeing. The script fails on RHEL
7.4 (NM 1.8) as the tap interface is wrongly released from the
bridge. The attached patch fixes this.

On RHEL 7.3 (NM 1.4) the issue doesn't seem to be reproducible. Would
you mind attaching a log for this version, captured as per comment 3?
Comment 9 Beniamino Galvani 2017-07-05 16:26:51 UTC 
Created attachment 1294666 [details]
[PATCH] device: don't release external slaves on state change
Comment 10 Zhengtong 2017-07-06 05:48:05 UTC 
(In reply to Beniamino Galvani from comment #3)
> Hi,
> 
> can you please:
> 
>  1. run 'nmcli general logging level trace'
[root@ibm-p8-09 home]# nmcli general logging level trace
[root@ibm-p8-09 home]#

>  2. attach the output of 'ip a' before setting tap0 down
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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: enP5p1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f0:64 brd ff:ff:ff:ff:ff:ff
3: enP5p1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f0:65 brd ff:ff:ff:ff:ff:ff
4: enP5p1s0f2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f0:66 brd ff:ff:ff:ff:ff:ff
5: enP5p1s0f3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f0:67 brd ff:ff:ff:ff:ff:ff
6: enP6p1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f1:bc brd ff:ff:ff:ff:ff:ff
7: enP6p1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f1:bd brd ff:ff:ff:ff:ff:ff
8: enP6p1s0f2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f1:be brd ff:ff:ff:ff:ff:ff
9: enP6p1s0f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master switch state UP qlen 1000
    link/ether 98:be:94:59:f1:bf brd ff:ff:ff:ff:ff:ff
10: switch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 22:91:58:5f:59:02 brd ff:ff:ff:ff:ff:ff
    inet 10.16.42.53/21 brd 10.16.47.255 scope global dynamic switch
       valid_lft 85334sec preferred_lft 85334sec
    inet6 2620:52:0:102f:2091:58ff:fe5f:5902/64 scope global mngtmpaddr dynamic 
       valid_lft 2591961sec preferred_lft 604761sec
    inet6 2620:52:0:102f:9abe:94ff:fe59:f1bf/64 scope global mngtmpaddr dynamic 
       valid_lft 2591907sec preferred_lft 604707sec
    inet6 fe80::1c7a:59ff:fed0:2c30/64 scope link 
       valid_lft forever preferred_lft forever
12: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master switch state UNKNOWN qlen 1000
    link/ether 22:91:58:5f:59:02 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2091:58ff:fe5f:5902/64 scope link 
       valid_lft forever preferred_lft forever

>  3. set tap0 down and up again
[root@ibm-p8-09 ~]# ifconfig tap0 down
[root@ibm-p8-09 ~]# ifconfig tap0 up
[root@ibm-p8-09 ~]# 


>  4. verify that the bug is reproduced, i.e. you can't ping the VM
guest network recovered on HREL7.3

>  5. attach again the output of 'ip a'
[root@ibm-p8-09 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    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: enP5p1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f0:64 brd ff:ff:ff:ff:ff:ff
3: enP5p1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f0:65 brd ff:ff:ff:ff:ff:ff
4: enP5p1s0f2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f0:66 brd ff:ff:ff:ff:ff:ff
5: enP5p1s0f3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f0:67 brd ff:ff:ff:ff:ff:ff
6: enP6p1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f1:bc brd ff:ff:ff:ff:ff:ff
7: enP6p1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f1:bd brd ff:ff:ff:ff:ff:ff
8: enP6p1s0f2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 98:be:94:59:f1:be brd ff:ff:ff:ff:ff:ff
9: enP6p1s0f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master switch state UP qlen 1000
    link/ether 98:be:94:59:f1:bf brd ff:ff:ff:ff:ff:ff
10: switch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 22:91:58:5f:59:02 brd ff:ff:ff:ff:ff:ff
    inet 10.16.42.53/21 brd 10.16.47.255 scope global dynamic switch
       valid_lft 85174sec preferred_lft 85174sec
    inet6 2620:52:0:102f:2091:58ff:fe5f:5902/64 scope global mngtmpaddr dynamic 
       valid_lft 2591920sec preferred_lft 604720sec
    inet6 2620:52:0:102f:9abe:94ff:fe59:f1bf/64 scope global mngtmpaddr dynamic 
       valid_lft 2591747sec preferred_lft 604547sec
    inet6 fe80::1c7a:59ff:fed0:2c30/64 scope link 
       valid_lft forever preferred_lft forever
12: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master switch state UNKNOWN qlen 1000
    link/ether 22:91:58:5f:59:02 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2091:58ff:fe5f:5902/64 scope link 
       valid_lft forever preferred_lft forever

>  6. also attach the output of 'journalctl -u NetworkManager -b'
Attached
> 
> ? Thanks!
Comment 11 Zhengtong 2017-07-06 05:49:04 UTC 
Created attachment 1294821 [details]
RHEL7.3_networkmanager log
Comment 12 tiama 2017-07-06 07:11:27 UTC 
x86_64 hit the same issue.

version:
3.10.0-691.rt56.615.el7.x86_64
qemu-kvm-rhev-2.9.0-14.el7.x86_64
NetworkManager-1.8.0-8.el7.x86_64
Comment 13 Beniamino Galvani 2017-07-06 07:51:42 UTC 
(In reply to Zhengtong from comment #10)

> >  4. verify that the bug is reproduced, i.e. you can't ping the VM
> guest network recovered on HREL7.3

> >  5. attach again the output of 'ip a'
> 12: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master switch
                                                                ^^^^^^^^^^^^^

Thanks, this confirms my observation that the problem does not happen on RHEL 7.3.
Comment 14 Thomas Haller 2017-07-07 13:58:01 UTC 
(In reply to Beniamino Galvani from comment #9)
> Created attachment 1294666 [details]
> [PATCH] device: don't release external slaves on state change

+    gboolean configure = FALSE;
                          ^^ TRUE


anyway, I removed many places where we look at the state reason. It is very ugly to do so, because it's hard to follow how the reason is passed on.

The decision what to do should be done based on the device's state, most notably the "state" and "sys-iface-state".

Why is the "release" variable not FALSE, if master shouldn't un-enslave?
Comment 15 Beniamino Galvani 2017-07-19 08:51:16 UTC 
(In reply to Thomas Haller from comment #14)
> (In reply to Beniamino Galvani from comment #9)
> > Created attachment 1294666 [details]
> > [PATCH] device: don't release external slaves on state change
>
> +    gboolean configure = FALSE;
>                           ^^ TRUE

Oops, fixed.

> anyway, I removed many places where we look at the state reason. It is very
> ugly to do so, because it's hard to follow how the reason is passed on.
>
> The decision what to do should be done based on the device's state, most
> notably the "state" and "sys-iface-state".

We need to detach the slave only for assumed connections; neither the
state nor the sys-iface-state are useful to determine the assumed
condition.

For sys-iface-state, one could think that EXTERNAL means an assumed
connection, however we currently change the sys-iface-state to MANAGED
after the assumed connection becomes active. This should be probably
changed, but I think the change has a larger scope and shouldn't be done
as part of this bz.

> Why is the "release" variable not FALSE, if master shouldn't un-enslave?

"release" means that the slave must be removed from the master's list
of slaves. "configure" tells whether this must also be done at the
platform level.
Comment 16 Beniamino Galvani 2017-07-19 08:53:27 UTC 
Created attachment 1300926 [details]
[PATCH v2] device: don't release external slaves on state change
Comment 17 Thomas Haller 2017-08-18 17:14:20 UTC 
(In reply to Beniamino Galvani from comment #15)
> (In reply to Thomas Haller from comment #14)
> > (In reply to Beniamino Galvani from comment #9)
> >
> > anyway, I removed many places where we look at the state reason. It is very
> > ugly to do so, because it's hard to follow how the reason is passed on.
> >
> > The decision what to do should be done based on the device's state, most
> > notably the "state" and "sys-iface-state".
> 
> We need to detach the slave only for assumed connections; neither the
> state nor the sys-iface-state are useful to determine the assumed
> condition.
> 
> For sys-iface-state, one could think that EXTERNAL means an assumed
> connection, however we currently change the sys-iface-state to MANAGED
> after the assumed connection becomes active. This should be probably
> changed, but I think the change has a larger scope and shouldn't be done
> as part of this bz.

I disagree.

The coined new terms for 1.8. "assume" now means "gracefully take over". If you mean "should not touch", it's called "external".
 
sys-iface-state should correspond to that. Yes, activating an assumed connection will indeed switch to managed after activation completes. That's the point: after the interface is gracefully taken over, it's managed like a regular activation.

When activating an "external" connection, sys-iface-state stays as "external".


If "sys-iface-state" is wrong/not-useful, the state should be fixed.
Comment 18 Beniamino Galvani 2017-09-01 11:29:36 UTC 
(In reply to Thomas Haller from comment #17)
> 
> If "sys-iface-state" is wrong/not-useful, the state should be fixed.

How about branch bg/external-slaves-rh1442361 ?
Comment 19 Thomas Haller 2017-09-01 11:45:41 UTC 
               if (   NM_IN_SET_TYPED (NMDeviceSysIfaceState,
                                       priv->sys_iface_state,
-                                      NM_DEVICE_SYS_IFACE_STATE_EXTERNAL,
                                       NM_DEVICE_SYS_IFACE_STATE_ASSUME)
                   && nm_device_sys_iface_state_get (priv->master) == NM_DEVICE_SYS_IFACE_STATE_MANAGED)
                    nm_device_sys_iface_state_set (self, NM_DEVICE_SYS_IFACE_STATE_MANAGED);


Now we only set the state MANAGED, if the state is ASSUMED previously. I wonder, if that is necessary, because the idea is, once activation completes, to anyway promote ASSUMED to MANAGED. The state is only ASSUMED, if it's still activating. In this case, I think the state should stay.  Can you add a follow-up patch, to drop this "if" entirely? (or what's your opinion?)


Otherwise, the 2 patches look right to me!! I am not sure this is 100% correct, but it seems the right approach to me.
Comment 20 Beniamino Galvani 2017-09-02 09:04:45 UTC 
(In reply to Thomas Haller from comment #19)

> Now we only set the state MANAGED, if the state is ASSUMED previously. I
> wonder, if that is necessary, because the idea is, once activation
> completes, to anyway promote ASSUMED to MANAGED. The state is only ASSUMED,
> if it's still activating. In this case, I think the state should stay.  Can
> you add a follow-up patch, to drop this "if" entirely? (or what's your
> opinion?)

I dropped the 'if' entirely and merged to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6a740fa247fefc8cc5c0b50458108e654db91dc5

nm-1-8:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-8&id=6bc73f15906502cebdadeda70466640f792982ae

CI test:

https://github.com/NetworkManager/NetworkManager-ci/pull/20
Comment 21 Yiqian Wei 2017-09-22 06:18:07 UTC 
Hi Zhengtong,

  I hit same issue on x86_64 platform.Should you change the hardware status to all ?
Comment 22 Zhengtong 2017-09-22 06:28:18 UTC 
(In reply to Yiqian Wei from comment #21)
> Hi Zhengtong,
> 
>   I hit same issue on x86_64 platform.Should you change the hardware status
> to all ?

While I hit this issue. I tried on x86_64, It passed  then.  If you hit it on x86_64 now, I think that may be a regression of x86_64. I am not sure if this could be the same issue. Leave the decision to bgalvani.
Comment 24 Beniamino Galvani 2017-09-22 12:29:32 UTC 
(In reply to Yiqian Wei from comment #21)
> Hi Zhengtong,
> 
>   I hit same issue on x86_64 platform.Should you change the hardware status
> to all ?

Yes, the bug is present on all architectures.
Comment 25 Vladimir Benes 2018-01-22 10:52:25 UTC 
Automated here:
https://github.com/NetworkManager/NetworkManager-ci/blob/master/nmcli/features/general.feature#L1564

Executed on daily basis in CI on devel branches and working well on 7.5's candidate too.
Comment 28 errata-xmlrpc 2018-04-10 13:22:08 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-2018:0778