Bug 377867

Summary: avahi creates new connection that doesn't exist
Product: [Applications] systemsettings Reporter: Paul <Paul.Hancock.17041993>
Component: kcm_networkmanagementAssignee: Jan Grulich <jgrulich>
Status: RESOLVED MOVED    
Severity: normal CC: jgrulich
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Paul 2017-03-21 03:40:13 UTC
avahi appears to have a tendancy to create a new network connection for an existing ethernet adapter while the adapter is inactive/asleep/disconnected. This resulting adapter shows up in the network manager and can conflict with other connections, including the wifi card (removing or editing the ethernet connections can cause the wifi to fail for unknown reasons).


ifconfig
enp1s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 70:5a:0f:85:fb:b2  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp1s0:avahi: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 169.254.10.110  netmask 255.255.0.0  broadcast 169.254.255.255
        ether 70:5a:0f:85:fb:b2  txqueuelen 1000  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 36833  bytes 3321005 (3.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 36833  bytes 3321005 (3.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vpn_vectrobevpn: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::2ac:ffff:fefc:4d2d  prefixlen 64  scopeid 0x20<link>
        ether 00:ac:ff:fc:4d:2d  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 2660 overruns 0  carrier 0  collisions 0

wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.15.238.196  netmask 255.0.0.0  broadcast 10.255.255.255
        inet6 fe80::94fd:274a:5138:7532  prefixlen 64  scopeid 0x20<link>
        ether 08:d4:0c:ef:9b:4c  txqueuelen 1000  (Ethernet)
        RX packets 560696  bytes 599284948 (599.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 620583  bytes 107201838 (107.2 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Comment 1 Jan Grulich 2017-03-21 07:37:33 UTC
This unfortunately looks like a NetworkManager problem rather then an issue on
our side. Could you please report this bug to NetworkManager instead?

NM bugzilla:
https://bugzilla.gnome.org/page.cgi?id=browse.html&product=NetworkManager
Comment 2 Paul 2017-03-21 07:47:32 UTC
(In reply to Jan Grulich from comment #1)
> This unfortunately looks like a NetworkManager problem rather then an issue
> on
> our side. Could you please report this bug to NetworkManager instead?
> 
> NM bugzilla:
> https://bugzilla.gnome.org/page.cgi?id=browse.html&product=NetworkManager

I thought that was the whole idea of having plasma-nm and having it link to it...?