Debian Bug report logs - #755202
network-manager: keeps creating and using new connection "eth0" that does not work

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Felix C. Stegerman" <flx@obfusk.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Fri, 18 Jul 2014 21:35:52 +0200

Package: network-manager
Version: 0.9.10.0-1
Severity: normal

Dear Maintainer,

NetworkManager has started creating a new wired connection "eth0"
after/during boot; this connection has ipv4 (and ipv6) disabled, and
thus provides no connectivity.  I can manually select my original
wired connection (standard dhcp) in gnome3 (or using nmcli), but it
keeps creating the "eth0" interface and using it after restarting.

* Purging and re-installing NM does not help.
* Modifying the "eth0" connection to enable ipv4 or creating a new
  connection named "eth0" that has ipv4 enabled does not help -- NM
  will simply create another connection named "eth0" and use that.
* /var/log/syslog did not seem to include anything useful.

I really have no idea what's going on here.  I hope someone else does.
Thanks.

- Felix


-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages network-manager depends on:
ii  adduser                3.113+nmu3
ii  dbus                   1.8.6-1
ii  init-system-helpers    1.19
ii  isc-dhcp-client        4.3.0+dfsg-1
ii  libc6                  2.19-7
ii  libdbus-1-3            1.8.6-1
ii  libdbus-glib-1-2       0.102-1
ii  libgcrypt11            1.5.3-4
ii  libglib2.0-0           2.40.0-3
ii  libgnutls-deb0-28      3.2.15-3
ii  libgudev-1.0-0         208-6
ii  libmm-glib0            1.2.0-1
ii  libndp0                1.3-1
ii  libnewt0.52            0.52.17-1
ii  libnl-3-200            3.2.24-2
ii  libnl-genl-3-200       3.2.24-2
ii  libnl-route-3-200      3.2.24-2
ii  libnm-glib4            0.9.10.0-1
ii  libnm-util2            0.9.10.0-1
ii  libpam-systemd         208-6
ii  libpolkit-gobject-1-0  0.105-6
ii  libreadline6           6.3-6
ii  libsoup2.4-1           2.46.0-2
ii  libsystemd-daemon0     208-6
ii  libsystemd-login0      208-6
ii  libuuid1               2.20.1-5.8
ii  lsb-base               4.1+Debian13
ii  policykit-1            0.105-6
ii  udev                   208-6
ii  wpasupplicant          1.1-1

Versions of packages network-manager recommends:
ii  crda          1.1.2-1
ii  dnsmasq-base  2.71-1
ii  iptables      1.4.21-2
ii  modemmanager  1.2.0-1
ii  ppp           2.4.6-2

Versions of packages network-manager suggests:
pn  avahi-autoipd  <none>

-- no debconf information

Message #10 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: 755202@bugs.debian.org

Cc: "Felix C. Stegerman" <flx@obfusk.net>

Subject: Re: Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Sun, 20 Jul 2014 09:58:50 +0200

[Message part 1 (text/plain, inline)]

severity: important
thanks

Dear network-manager maintainers,

On Fri, Jul 18, 2014 at 09:35:52PM +0200, Felix C. Stegerman wrote:
> NetworkManager has started creating a new wired connection "eth0"
> after/during boot; this connection has ipv4 (and ipv6) disabled, and
> thus provides no connectivity.  I can manually select my original
> wired connection (standard dhcp) in gnome3 (or using nmcli), but it
> keeps creating the "eth0" interface and using it after restarting.

I'm seeing this as well. Furthermore, it seems to get in the way of
other interfaces such as wifi, meaning that if you're regularly using a
wifi, every time a new "eth0" interface kicks in you lose connectivity.

To give in idea, currently my laptop has 9 bogus "eth0" interfaces, in
addition to the "right" one (i.e., "ifupdown (eth0)" and another static
one I've configured).

I haven't yet understood when exactly network-manager adds a new one,
but at each resume for suspend I lose connectivity, but not only. For
instance, since the last resume (~1 hour ago) I had to manually disable
a bogus eth0 interface at least 3 times.  As you can imagine, this is
really getting in the way of using my computer productively --- hence my
severity tweaking.

If you've ideas on how I can help you debug the problem, let me know.
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Stefano Zacchiroli <zack@debian.org>

Cc: 755202@bugs.debian.org, "Felix C. Stegerman" <flx@obfusk.net>

Subject: Re: [Pkg-utopia-maintainers] Processed: severity of 755202 is important

Date: Sun, 20 Jul 2014 11:53:15 +0200

[Message part 1 (text/plain, inline)]

Are you using managed=true mode in /etc/NetworkManager/NetworkManager.conf?

A debug log might be helpful, run

service network-manager stop && NetworkManager --no-daemon --debug
--log-level=debug

Are those duplicated interfaces happening whenever networkmanager is
restarted?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #22 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Frederik Himpe <fhimpe@telenet.be>

To: 755202@bugs.debian.org

Subject: NetworkManager creates broken eth0 connection while booting

Date: Mon, 21 Jul 2014 17:59:30 +0200

I'm seeing the same problem: every time I boot my system, a network
called "eth0" with disabled IPv4 and IPv6 is selected.

My NetworkManager.conf looks like this:

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

/etc/network/interfaces looks like this:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
#NetworkManager#iface eth0 inet dhcp


I have removed the broken eth0 connection in NM, leaving only the
working "Auto Ethernet" connection. Then I ran 

# service network-manager stop && NetworkManager --no-daemon --debug
NetworkManager[3056]: <info> NetworkManager (version 0.9.10.0) is starting...
NetworkManager[3056]: <info> Read config: /etc/NetworkManager/NetworkManager.conf
NetworkManager[3056]: <info> WEXT support is enabled
NetworkManager[3056]: <info> init!
NetworkManager[3056]: <info> update_system_hostname
NetworkManager[3056]: <info>       interface-parser: parsing file /etc/network/interfaces
NetworkManager[3056]: <info>       interface-parser: finished parsing file /etc/network/interfaces
NetworkManager[3056]: <info> management mode: unmanaged
NetworkManager[3056]: <info> devices added (path: /sys/devices/pci0000:00/0000:00:1c.5/0000:05:00.0/net/eth0, iface: eth0)
NetworkManager[3056]: <info> device added (path: /sys/devices/pci0000:00/0000:00:1c.5/0000:05:00.0/net/eth0, iface: eth0): no ifupdown configuration found.
NetworkManager[3056]: <info> devices added (path: /sys/devices/virtual/net/lo, iface: lo)
NetworkManager[3056]: <info> device added (path: /sys/devices/virtual/net/lo, iface: lo): no ifupdown configuration found.
NetworkManager[3056]: <info> devices added (path: /sys/devices/virtual/net/virbr0, iface: virbr0)
NetworkManager[3056]: <info> device added (path: /sys/devices/virtual/net/virbr0, iface: virbr0): no ifupdown configuration found.
NetworkManager[3056]: <info> end _init.
NetworkManager[3056]: <info> Loaded plugin ifupdown: (C) 2008 Canonical Ltd.  To report bugs please use the NetworkManager mailing list.
NetworkManager[3056]: <info> Loaded plugin keyfile: (c) 2007 - 2013 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
NetworkManager[3056]: <info> (35128128) ... get_connections.
NetworkManager[3056]: <info> (35128128) ... get_connections (managed=false): return empty list.
NetworkManager[3056]: <info> new connection /etc/NetworkManager/system-connections/Auto Ethernet
NetworkManager[3056]: <info> get unmanaged devices count: 0
NetworkManager[3056]: <info> monitoring kernel firmware directory '/lib/firmware'.
NetworkManager[3056]: <info> monitoring ifupdown state file '/run/network/ifstate'.
NetworkManager[3056]: <info> WiFi hardware radio set enabled
NetworkManager[3056]: <info> WWAN hardware radio set enabled
NetworkManager[3056]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-wwan.so
NetworkManager[3056]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-adsl.so
NetworkManager[3056]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-bluetooth.so
NetworkManager[3056]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-wifi.so
NetworkManager[3056]: <info> WiFi enabled by radio killswitch; enabled by state file
NetworkManager[3056]: <info> WWAN enabled by radio killswitch; enabled by state file
NetworkManager[3056]: <info> WiMAX enabled by radio killswitch; enabled by state file
NetworkManager[3056]: <info> Networking is enabled by state file
NetworkManager[3056]: <info> (lo): link connected
NetworkManager[3056]: <info> (lo): carrier is ON
NetworkManager[3056]: <info> (lo): new Generic device (driver: 'unknown' ifindex: 1)
NetworkManager[3056]: <info> (lo): exported as /org/freedesktop/NetworkManager/Devices/0
NetworkManager[3056]: <info> (eth0): link connected
NetworkManager[3056]: <info> (eth0): carrier is ON
NetworkManager[3056]: <info> (eth0): new Ethernet device (driver: 'r8169' ifindex: 2)
NetworkManager[3056]: <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
NetworkManager[3056]: <info> (eth0): found matching connection 'Auto Ethernet'
NetworkManager[3056]: <info> (eth0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
NetworkManager[3056]: <info> (eth0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
NetworkManager[3056]: <info> Activation (eth0) starting connection 'Auto Ethernet'
NetworkManager[3056]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[3056]: <info> (virbr0): carrier is OFF
NetworkManager[3056]: <info> (virbr0): new Bridge device (driver: 'bridge' ifindex: 3)
NetworkManager[3056]: <info> (virbr0): exported as /org/freedesktop/NetworkManager/Devices/2
NetworkManager[3056]: <info> (virbr0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
NetworkManager[3056]: <info> (virbr0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
NetworkManager[3056]: <info> Activation (virbr0) starting connection 'virbr0'
NetworkManager[3056]: <info> Activation (virbr0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[3056]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
NetworkManager[3056]: <info> (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[3056]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager[3056]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager[3056]: <info> Activation (virbr0) Stage 1 of 5 (Device Prepare) started...
NetworkManager[3056]: <info> (virbr0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[3056]: <info> Activation (virbr0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager[3056]: <info> Activation (virbr0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager[3056]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
NetworkManager[3056]: <info> (eth0): device state change: prepare -> config (reason 'none') [40 50 0]
NetworkManager[3056]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
NetworkManager[3056]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager[3056]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
NetworkManager[3056]: <info> Activation (virbr0) Stage 2 of 5 (Device Configure) starting...
NetworkManager[3056]: <info> (virbr0): device state change: prepare -> config (reason 'none') [40 50 0]
NetworkManager[3056]: <info> Activation (virbr0) Stage 2 of 5 (Device Configure) successful.
NetworkManager[3056]: <info> Activation (virbr0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager[3056]: <info> Activation (virbr0) Stage 2 of 5 (Device Configure) complete.
NetworkManager[3056]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager[3056]: <info> (eth0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[3056]: <info> Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds)
NetworkManager[3056]: <info> dhclient started with pid 3063
NetworkManager[3056]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
NetworkManager[3056]: <info> Activation (virbr0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager[3056]: <info> (virbr0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[3056]: <info> Activation (virbr0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
NetworkManager[3056]: <info> (virbr0): IPv6 config waiting until carrier is on
NetworkManager[3056]: <info> Activation (virbr0) Stage 3 of 5 (IP Configure Start) complete.
NetworkManager[3056]: <info> ModemManager available in the bus
Internet Systems Consortium DHCP Client 4.3.0
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

NetworkManager[3056]: <info> (eth0): DHCPv4 state changed nbi -> preinit
Listening on LPF/eth0/bc:5f:f4:38:be:84
Sending on   LPF/eth0/bc:5f:f4:38:be:84
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPNAK from 192.168.5.1
NetworkManager[3056]: <info> Activation (virbr0) Stage 5 of 5 (IPv4 Commit) started...
NetworkManager[3056]: <warn> Could not send ARP for local address 192.168.122.1: Failed to execute child process "/sbin/arping" (No such file or directory)
NetworkManager[3056]: <info> (virbr0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
NetworkManager[3056]: <info> Activation (virbr0) Stage 5 of 5 (IPv4 Commit) complete.
NetworkManager[3056]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) starting DHCPv6 as requested by IPv6 router...
NetworkManager[3056]: <info> Activation (eth0) Beginning DHCPv6 transaction (timeout in 45 seconds)
NetworkManager[3056]: <info> dhclient started with pid 3069
Internet Systems Consortium DHCP Client 4.3.0
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on Socket/eth0
Sending on   Socket/eth0
PRC: Requesting information (INIT).
NetworkManager[3056]: <info> (eth0): DHCPv4 state changed preinit -> expire
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
NetworkManager[3056]: <info> (eth0): DHCPv4 state changed expire -> preinit
NetworkManager[3056]: <info> (virbr0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
NetworkManager[3056]: <info> (virbr0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[3056]: <info> NetworkManager state is now CONNECTED_LOCAL
NetworkManager[3056]: <info> Activation (virbr0) successful, device activated.
XMT: Forming Info-Request, 0 ms elapsed.
XMT: Info-Request on eth0, interval 1020ms.
XMT: Forming Info-Request, 1020 ms elapsed.
XMT: Info-Request on eth0, interval 2050ms.
NetworkManager[3056]: <warn> Could not send ARP for local address 192.168.122.1: Failed to execute child process "/sbin/arping" (No such file or directory)
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.5.1
DHCPACK from 192.168.5.1
NetworkManager[3056]: <info> (eth0): DHCPv4 state changed preinit -> bound
bound to 192.168.5.206 -- renewal in 1548 seconds.
NetworkManager[3056]: <info>   address 192.168.5.206
NetworkManager[3056]: <info>   plen 24 (255.255.255.0)
NetworkManager[3056]: <info>   gateway 192.168.5.1
NetworkManager[3056]: <info>   server identifier 192.168.5.1
NetworkManager[3056]: <info>   lease time 3600
NetworkManager[3056]: <info>   hostname 'piranha'
NetworkManager[3056]: <info>   nameserver '195.130.131.2'
NetworkManager[3056]: <info>   nameserver '195.130.130.130'
NetworkManager[3056]: <info>   domain name 'home'
NetworkManager[3056]: <info> Activation (eth0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
NetworkManager[3056]: <info> Activation (eth0) Stage 5 of 5 (IPv4 Commit) started...
NetworkManager[3056]: <info> (eth0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
NetworkManager[3056]: <info> Activation (eth0) Stage 5 of 5 (IPv4 Commit) complete.
NetworkManager[3056]: <info> (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
NetworkManager[3056]: <info> (eth0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[3056]: <info> NetworkManager state is now CONNECTED_GLOBAL
NetworkManager[3056]: <info> Policy set 'Auto Ethernet' (eth0) as default for IPv4 routing and DNS.
NetworkManager[3056]: <info> Policy set 'Auto Ethernet' (eth0) as default for IPv6 routing and DNS.
NetworkManager[3056]: <info> Activation (eth0) successful, device activated.
XMT: Forming Info-Request, 3070 ms elapsed.
XMT: Info-Request on eth0, interval 4260ms.
NetworkManager[3056]: <info> startup complete
XMT: Forming Info-Request, 7330 ms elapsed.
XMT: Info-Request on eth0, interval 8810ms.
XMT: Forming Info-Request, 16150 ms elapsed.
XMT: Info-Request on eth0, interval 17160ms.
XMT: Forming Info-Request, 33330 ms elapsed.
XMT: Info-Request on eth0, interval 34570ms.

This did not create the broken eth0 connection:
# nmcli c show
NAME           UUID                                  TYPE            DEVICE 
virbr0         6d2ae2dd-cbfa-4ce6-aba4-9d558364851f  bridge          virbr0 
Auto Ethernet  3927fb7b-c9e3-4d47-8ba2-91aa4c1f36c2  802-3-ethernet  eth0   


Suspending/resuming my system did not create this connection either.

However, after a reboot, the broken eth0 connection was there again.
This is the complete NetworkManager log when booting the system:

Jul 21 17:53:31 piranha NetworkManager[1347]: <info> NetworkManager (version 0.9.10.0) is starting...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Read config: /etc/NetworkManager/NetworkManager.conf
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> WEXT support is enabled
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> init!
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> update_system_hostname
Jul 21 17:53:31 piranha NetworkManager[1347]: <info>       interface-parser: parsing file /etc/network/interfaces
Jul 21 17:53:31 piranha NetworkManager[1347]: <info>       interface-parser: finished parsing file /etc/network/interfaces
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> management mode: unmanaged
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> devices added (path: /sys/devices/pci0000:00/0000:00:1c.5/0000:05:00.0/net/eth0, iface: eth0)
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> device added (path: /sys/devices/pci0000:00/0000:00:1c.5/0000:05:00.0/net/eth0, iface: eth0): no ifupdown configuration found.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> devices added (path: /sys/devices/virtual/net/lo, iface: lo)
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> device added (path: /sys/devices/virtual/net/lo, iface: lo): no ifupdown configuration found.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> end _init.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Loaded plugin ifupdown: (C) 2008 Canonical Ltd.  To report bugs please use the NetworkManager mailing list.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Loaded plugin keyfile: (c) 2007 - 2013 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (10853184) ... get_connections.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (10853184) ... get_connections (managed=false): return empty list.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> new connection /etc/NetworkManager/system-connections/Auto Ethernet
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> get unmanaged devices count: 0
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> monitoring kernel firmware directory '/lib/firmware'.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> monitoring ifupdown state file '/run/network/ifstate'.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> WiFi hardware radio set enabled
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> WWAN hardware radio set enabled
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-adsl.so
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-bluetooth.so
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-wifi.so
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> WiFi enabled by radio killswitch; enabled by state file
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> WWAN enabled by radio killswitch; enabled by state file
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> WiMAX enabled by radio killswitch; enabled by state file
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Networking is enabled by state file
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (lo): link connected
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (lo): carrier is ON
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (lo): new Generic device (driver: 'unknown' ifindex: 1)
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (lo): exported as /org/freedesktop/NetworkManager/Devices/0
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (eth0): link connected
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (eth0): carrier is ON
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (eth0): new Ethernet device (driver: 'r8169' ifindex: 2)
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (eth0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (eth0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) starting connection 'eth0'
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (eth0): device state change: prepare -> config (reason 'none') [40 50 0]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (eth0): device state change: config -> ip-config (reason 'none') [50 70 0]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) starting DHCPv6 as requested by IPv6 router...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (eth0) Beginning DHCPv6 transaction (timeout in 45 seconds)
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> dhclient started with pid 1828
Jul 21 17:53:31 piranha NetworkManager[1347]: Internet Systems Consortium DHCP Client 4.3.0
Jul 21 17:53:31 piranha NetworkManager[1347]: Copyright 2004-2014 Internet Systems Consortium.
Jul 21 17:53:31 piranha NetworkManager[1347]: All rights reserved.
Jul 21 17:53:31 piranha NetworkManager[1347]: For info, please visit https://www.isc.org/software/dhcp/
Jul 21 17:53:31 piranha NetworkManager[1347]: Listening on Socket/eth0
Jul 21 17:53:31 piranha NetworkManager[1347]: Sending on   Socket/eth0
Jul 21 17:53:31 piranha NetworkManager[1347]: PRC: Requesting information (INIT).
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> ModemManager disappeared from bus
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> ModemManager available in the bus
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): carrier is OFF
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): new Bridge device (driver: 'bridge' ifindex: 3)
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): exported as /org/freedesktop/NetworkManager/Devices/2
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): preparing device
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): device state change: unavailable -> disconnected (reason 'none') [20 30 0]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> devices added (path: /sys/devices/virtual/net/virbr0, iface: virbr0)
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> device added (path: /sys/devices/virtual/net/virbr0, iface: virbr0): no ifupdown configuration found.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) starting connection 'virbr0'
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 1 of 5 (Device Prepare) scheduled...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 1 of 5 (Device Prepare) started...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 2 of 5 (Device Configure) scheduled...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 1 of 5 (Device Prepare) complete.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 2 of 5 (Device Configure) starting...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): device state change: prepare -> config (reason 'none') [40 50 0]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 2 of 5 (Device Configure) successful.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 3 of 5 (IP Configure Start) scheduled.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 2 of 5 (Device Configure) complete.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 3 of 5 (IP Configure Start) started...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): device state change: config -> ip-config (reason 'none') [50 70 0]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): IPv6 config waiting until carrier is on
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 3 of 5 (IP Configure Start) complete.
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) Stage 5 of 5 (IPv4 Commit) started...
Jul 21 17:53:31 piranha NetworkManager[1347]: <warn> Could not send ARP for local address 192.168.122.1: Failed to execute child process "/sbin/arping" (No such file or directory)
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> (virbr0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Jul 21 17:53:31 piranha NetworkManager[1347]: <info> Activation (virbr0) successful, device activated.
Jul 21 17:53:31 piranha NetworkManager[1347]: XMT: Forming Info-Request, 0 ms elapsed.
Jul 21 17:53:31 piranha NetworkManager[1347]: XMT: Info-Request on eth0, interval 1060ms.
Jul 21 17:53:33 piranha NetworkManager[1347]: XMT: Forming Info-Request, 1060 ms elapsed.
Jul 21 17:53:33 piranha NetworkManager[1347]: XMT: Info-Request on eth0, interval 2070ms.
Jul 21 17:53:34 piranha NetworkManager[1347]: <warn> Could not send ARP for local address 192.168.122.1: Failed to execute child process "/sbin/arping" (No such file or directory)
Jul 21 17:53:35 piranha NetworkManager[1347]: XMT: Forming Info-Request, 3130 ms elapsed.
Jul 21 17:53:35 piranha NetworkManager[1347]: XMT: Info-Request on eth0, interval 4110ms.
Jul 21 17:53:37 piranha NetworkManager[1347]: <info> startup complete
Jul 21 17:53:39 piranha NetworkManager[1347]: XMT: Forming Info-Request, 7240 ms elapsed.
Jul 21 17:53:39 piranha NetworkManager[1347]: XMT: Info-Request on eth0, interval 8310ms.
Jul 21 17:53:47 piranha NetworkManager[1347]: XMT: Forming Info-Request, 15560 ms elapsed.
Jul 21 17:53:47 piranha NetworkManager[1347]: XMT: Info-Request on eth0, interval 17200ms.

Message #27 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: Frederik Himpe <fhimpe@telenet.be>, 755202@bugs.debian.org

Subject: Re: Bug#755202: NetworkManager creates broken eth0 connection while booting

Date: Mon, 21 Jul 2014 21:39:31 +0200

On Mon, Jul 21, 2014 at 05:59:30PM +0200, Frederik Himpe wrote:
> My NetworkManager.conf looks like this:
> 
> [main]
> plugins=ifupdown,keyfile
> 
> [ifupdown]
> managed=false

FWIW, I've managed=true (everything else is the same), and I'm seeing
the problem nonetheless.

-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Message #32 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Vladimir K <pzs-fs@yandex.ru>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Thu, 31 Jul 2014 00:38:11 +0400

I can assume NM creates virtual 'eth0' profile when it sees that interface is already brought up and configured.
This profile does not exist as a file in /etc/NetworkManager/system-connections.

I'm using several named connection profiles with associated dispatcher scripts. If there is a need for NM to be restarted, usually correct profile is restored. But if interface configuration was somehow altered by something other than NM, then after restart it uses this dynamic 'eth0' profile instead of correct one. Annoying. I hope there is or will be a way to disable this feature, as it is clearly misfires sometimes.

Message #37 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Pat Hooper <wphooper@gmail.com>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: NetworkManager creates broken eth0 connection while booting

Date: Wed, 17 Sep 2014 15:00:50 -0400

Hi all,

I've been having this problem with two laptops, and continue to have
the problem.

I don't know much about networking, but I managed to "fix" the problem
by editting "/etc/default/avahi-daemon" so that it reads:
AVAHI_DAEMON_DETECT_LOCAL=0
(originally it had a 1 rather than a 0). Then I restarted my computer
(though maybe restarting networking is sufficent). Note: I am not sure
what damage I am doing, since I haven't tested eth0 since doing this.
I have only been using wifi.

I stumbled on this because when I am having the problem with extra
non-working wired interfaces, my output of "ifconfig" read:

eth0      Link encap:Ethernet  HWaddr dc:0e:a1:cd:b7:52
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0:avahi Link encap:Ethernet  HWaddr dc:0e:a1:cd:b7:52
          inet addr:169.254.9.46  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:6129 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6129 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:569470 (556.1 KiB)  TX bytes:569470 (556.1 KiB)

virbr0    Link encap:Ethernet  HWaddr 8e:42:0e:fe:dd:e9
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 9c:b7:0d:98:ac:7f
          inet addr:146.96.26.84  Bcast:146.96.31.255  Mask:255.255.248.0
          inet6 addr: fe80::9eb7:dff:fe98:ac7f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25327 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17675 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:29927588 (28.5 MiB)  TX bytes:4792503 (4.5 MiB)


The lines for eth0:avahi only appear when I am having this problem. I
hope this helps to arrive at a solution.

Best,
Pat

Message #42 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Tobias Hansen <thansen@debian.org>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: NetworkManager creates broken eth0 connection while booting

Date: Sat, 11 Oct 2014 00:48:25 +0200

Control: severity -1 serious

I'm also having this problem and setting AVAHI_DAEMON_DETECT_LOCAL=0
didn't help in my case. I also have this eth0:avahi entry in ifconfig.
Raising severity since we really don't want to have this bug in a release.

Best,
Tobias

On Wed, 17 Sep 2014 15:00:50 -0400 Pat Hooper <wphooper@gmail.com> wrote:
> Hi all,
> 
> I've been having this problem with two laptops, and continue to have
> the problem.
> 
> I don't know much about networking, but I managed to "fix" the problem
> by editting "/etc/default/avahi-daemon" so that it reads:
> AVAHI_DAEMON_DETECT_LOCAL=0
> (originally it had a 1 rather than a 0). Then I restarted my computer
> (though maybe restarting networking is sufficent). Note: I am not sure
> what damage I am doing, since I haven't tested eth0 since doing this.
> I have only been using wifi.
> 
> I stumbled on this because when I am having the problem with extra
> non-working wired interfaces, my output of "ifconfig" read:
> 
> eth0      Link encap:Ethernet  HWaddr dc:0e:a1:cd:b7:52
>           UP BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> 
> eth0:avahi Link encap:Ethernet  HWaddr dc:0e:a1:cd:b7:52
>           inet addr:169.254.9.46  Bcast:169.254.255.255  Mask:255.255.0.0
>           UP BROADCAST MULTICAST  MTU:1500  Metric:1
> 
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:65536  Metric:1
>           RX packets:6129 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:6129 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:569470 (556.1 KiB)  TX bytes:569470 (556.1 KiB)
> 
> virbr0    Link encap:Ethernet  HWaddr 8e:42:0e:fe:dd:e9
>           inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
>           UP BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> 
> wlan0     Link encap:Ethernet  HWaddr 9c:b7:0d:98:ac:7f
>           inet addr:146.96.26.84  Bcast:146.96.31.255  Mask:255.255.248.0
>           inet6 addr: fe80::9eb7:dff:fe98:ac7f/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:25327 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:17675 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:29927588 (28.5 MiB)  TX bytes:4792503 (4.5 MiB)
> 
> 
> The lines for eth0:avahi only appear when I am having this problem. I
> hope this helps to arrive at a solution.
> 
> Best,
> Pat
> 

Message #49 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: Tobias Hansen <thansen@debian.org>, 755202@bugs.debian.org

Subject: Re: Bug#755202: NetworkManager creates broken eth0 connection while booting

Date: Sat, 11 Oct 2014 09:41:39 +0200

[Message part 1 (text/plain, inline)]

On Sat, Oct 11, 2014 at 12:48:25AM +0200, Tobias Hansen wrote:
> Control: severity -1 serious
> 
> I'm also having this problem and setting AVAHI_DAEMON_DETECT_LOCAL=0
> didn't help in my case. I also have this eth0:avahi entry in ifconfig.
> Raising severity since we really don't want to have this bug in a release.

Same here: it is indeed avahi related (I invariably get a 169.254.7.253
address) but AVAHI_DAEMON_DETECT_LOCAL=0 doesn't help. I can now
reproduce it reliably at each suspend/resume cycle of my laptop.
Immediately after resume I connect properly to the local wi-fi then,
after 1-2 minutes, a new eth0 kicks in and kill the network. Opening the
settings panel and switching of the "wired" connection fixes the
problem, until the next suspend/resume cycle.

FWIW, I agree with your severity assessment.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]

Message #54 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Frederik Himpe <fhimpe@telenet.be>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: NetworkManager creates broken eth0 connection while booting

Date: Sat, 11 Oct 2014 10:33:08 +0200

On za, 2014-10-11 at 09:41 +0200, Stefano Zacchiroli wrote:
> On Sat, Oct 11, 2014 at 12:48:25AM +0200, Tobias Hansen wrote:
> > Control: severity -1 serious
> > 
> > I'm also having this problem and setting AVAHI_DAEMON_DETECT_LOCAL=0
> > didn't help in my case. I also have this eth0:avahi entry in ifconfig.
> > Raising severity since we really don't want to have this bug in a release.
> 
> Same here: it is indeed avahi related (I invariably get a 169.254.7.253
> address) but AVAHI_DAEMON_DETECT_LOCAL=0 doesn't help.

On my system it is not avahi related: I do not have this eth0:avahi
address. However, I do get an IPv6 address via SLAAC on the affected
system. My guess is that the fact that the fact that there is already an
IP assigned to eth0 at the networkmanager start up, provokes this bug.
After system start up, I then have an IPv6 address but not an IPv4
address and I have to switch to "Auto Ethernet" network in
networkmanager to get an IPv4 address via DHCP in order to have a fully
working network configuration.

-- 
Frederik Himpe <fhimpe@telenet.be>

Message #59 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Anthony F McInerney <afm404@gmail.com>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: NetworkManager creates broken eth0 connection while booting

Date: Sat, 18 Oct 2014 23:40:01 +0100

[Message part 1 (text/plain, inline)]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756140#10

seems to be related too. simply removing eth0 entries from
/etc/network/interfaces for most people affected with various 'networking'
problems seems to make them magically vanish.

either network-manager is not respecting the rules, or something else is
happening with avahi, or both and then some.

[Message part 2 (text/html, inline)]

Message #64 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Nathaniel Beaver <nathanielmbeaver@gmail.com>

To: Stefano Zacchiroli <zack@debian.org>, 755202@bugs.debian.org

Subject: Re: Bug#755202: NetworkManager creates broken eth0 connection while booting

Date: Mon, 03 Nov 2014 11:01:37 -0600

I'm also able to reliably reproduce this. I always see avahi-autoipd 
processes like these pop up when the problem occurs:

$  ps aux | grep avahi-autoipd
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
avahi-a+ 31710  0.0  0.0   2440   816 ?        S    10:15   0:00 
avahi-autoipd: [eth0] bound 169.254.6.245
root     31711  0.0  0.0   2204   296 ?        S    10:15   0:00 
avahi-autoipd: [eth0] callout dispatcher

They disappear when I restart network manager.

$ sudo /etc/init.d/network-manager restart

But then they come back a few minutes later.

I haven't gotten any of the workarounds to resolve the issue so far.

Cheers,

Nathaniel Beaver

On 10/11/2014 02:41 AM, Stefano Zacchiroli wrote:
> On Sat, Oct 11, 2014 at 12:48:25AM +0200, Tobias Hansen wrote:
>> Control: severity -1 serious
>>
>> I'm also having this problem and setting AVAHI_DAEMON_DETECT_LOCAL=0
>> didn't help in my case. I also have this eth0:avahi entry in ifconfig.
>> Raising severity since we really don't want to have this bug in a release.
>
> Same here: it is indeed avahi related (I invariably get a 169.254.7.253
> address) but AVAHI_DAEMON_DETECT_LOCAL=0 doesn't help. I can now
> reproduce it reliably at each suspend/resume cycle of my laptop.
> Immediately after resume I connect properly to the local wi-fi then,
> after 1-2 minutes, a new eth0 kicks in and kill the network. Opening the
> settings panel and switching of the "wired" connection fixes the
> problem, until the next suspend/resume cycle.
>
> FWIW, I agree with your severity assessment.
>
> Cheers.
>

Message #69 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <Martin@lichtvoll.de>

To: 755202@bugs.debian.org

Subject: Possibly related bug

Date: Sat, 29 Nov 2014 23:29:48 +0100

Hello!

On my laptop I found

Bug#771077: changes mac address of eth0 of every disconnect

maybe what I found there is related to this bug?

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Message #74 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Hubert Chathi <hubert@uhoreg.ca>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: NetworkManager creates broken eth0

Date: Wed, 03 Dec 2014 21:14:28 -0500

Just to add another data point, this bug used to affect me, and then I
rebooted, and the issue seems to have disappeared.

Message #79 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Keivan Moradi <k.moradi@gmail.com>

To: 755202@bugs.debian.org

Subject: My Fix in Gentoo

Date: Tue, 20 Jan 2015 20:27:09 -0500

[Message part 1 (text/plain, inline)]

I had the same problem in Gentoo linux.
I am by no means a network expert.
I had this warning in NM log.

<warn>      error in connection
/etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0:
invalid connection: connection.type: property is missing

So I removed the the following file
/etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0

I also had this file
/etc/NetworkManager/system-connections/eth0

with this content:

[ethernet]
mac-address=10:C3:7B:AC:3B:23

[connection]
id=Wired
uuid=593aa2f2-5673-401a-823b-519d68e4dde2
type=ethernet

[ipv6]
method=ignore

[ipv4]
method=auto
may-fail=false


So I changed its name to "Wired" as it was the id.

The r8169 kernel module was also buggy in my case so that it could not get
an IP address when I was working in my workplace. So I switched to r8168
module.

Everything looks OK now. I hope this info help you also.
-- 
Sincerely,
Keivan

[Message part 2 (text/html, inline)]

Message #84 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <Martin@lichtvoll.de>

To: Keivan Moradi <k.moradi@gmail.com>, 755202@bugs.debian.org

Subject: Re: Bug#755202: My Fix in Gentoo

Date: Wed, 21 Jan 2015 10:13:59 +0100

Am Dienstag, 20. Januar 2015, 20:27:09 schrieb Keivan Moradi:
> I had the same problem in Gentoo linux.
> I am by no means a network expert.
> I had this warning in NM log.
> 
> <warn>      error in connection
> /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0:
> invalid connection: connection.type: property is missing
[…]
> Everything looks OK now. I hope this info help you also.

For me the issue went away after I fixed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755202#69

changes mac address of eth0 of every disconnect
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771077

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Message #89 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Frédéric Lespez <frederic.lespez@free.fr>

To: Keivan Moradi <k.moradi@gmail.com>, 755202@bugs.debian.org

Subject: Re: Bug#755202: My Fix in Gentoo

Date: Wed, 21 Jan 2015 19:57:21 +0100

> I had the same problem in Gentoo linux.
> I am by no means a network expert.
<snipped>
> The r8169 kernel module was also buggy in my case so that it could not
> get an IP address when I was working in my workplace. So I switched
> to r8168 module.
I have 2 PCs running Jessie. One PC was affected by this bug, but not 
the other.
I tried to "diff" the 2 PC configurations with not luck.
I also fiddled with avahi as described above but again with no success.

After seeing Keivan message, I check my network modules. The 2 PCs were 
using the r8169 module but the network card are different :
Affected PC : RTL8168evl/8111evl
Non affected PC : RTL8168g/8111g
So I switch to the r8168 module on the affected PC using sid package and 
the bug is now gone.

Thanks Keivan.

Message #94 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Frédéric Lespez <frederic.lespez@free.fr>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: My Fix in Gentoo

Date: Sun, 25 Jan 2015 09:49:04 +0100

> So I switch to the r8168 module on the affected PC using sid package and
> the bug is now gone.
I spoke too quickly. The bug is still present on a cold boot, but after 
a reboot the bug doesn't appear.
So maybe it is a driver bug in the card initialization.

Message #99 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Das OSi <mrdasosi@gmail.com>

To: 755202@bugs.debian.org

Subject: same here

Date: Sun, 25 Jan 2015 22:43:20 +0100

[Message part 1 (text/plain, inline)]

pinging google's dns (after rebooting):

"64 bytes from 8.8.8.8: icmp_seq=50 ttl=58 time=54.4 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=58 time=76.8 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=58 time=99.0 ms
64 bytes from 8.8.8.8: icmp_seq=53 ttl=58 time=637 ms"

but then suddenly
"eth0:avahi Link encap:Ethernet  HWaddr ec:f4:bb:60:df:ea
          inet addr:169.254.12.153  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          Interrupt:20 Memory:f7c00000-f7c20000"
appears and:

"From 169.254.12.153 icmp_seq=54 Destination Host Unreachable"

strange thing is, that I can still reach all clients in the same subnet
(192.168.2.x).

[Message part 2 (text/html, inline)]

Message #104 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Magnus Holmgren <holmgren@debian.org>

To: 755202@bugs.debian.org

Subject: Re: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Sun, 08 Feb 2015 12:28:58 +0100

fredagen den 18 juli 2014 21.35.52 skrev du:
> NetworkManager has started creating a new wired connection "eth0"
> after/during boot; this connection has ipv4 (and ipv6) disabled, and
> thus provides no connectivity.  I can manually select my original
> wired connection (standard dhcp) in gnome3 (or using nmcli), but it
> keeps creating the "eth0" interface and using it after restarting.

I had the same or similar problem, except that only IPv4 was disabled. It 
seems that the cause in my case was that I tried to load netconsole on the 
kernel command line, which I think worked before I switched to systemd and/or 
stopped using ifupdown. Now when didn't try to load netconsole automatically, 
no automatic connection was created, but the interface was renamed from eth0 
to eth1. systemd still reported that mounting remote file systems failed, but 
the network connection came up and /home was mounted eventually nonetheless.

Strangely enough, checking /etc/udev/rules.d/70-persistent-net.rules (last 
modified in August), there is an eth0 line with a MAC address that doesn't 
match the current address of my NIC, and an eth1 line that does, but I'm 
pretty sure that the actual address hasn't been changing, and it matches 
/etc/NetworkManager/system-connections/eth0, which hasn't been changed since 
before the last boot.

I did also rename the connection in NetworkManager, but that should't have any 
consequences, should it?

I suppose it would have been possible to work around the problem by adding a 
no-auto-default setting to NetworkManager.conf.

I'm not sure what to make of this but it seems that loading netconsole was 
bringing the interface up early (but leaving it unconfigured), which may have 
confused NM. It may also have prevented udev from renaming it, but I don't 
know if these points are related.

-- 
Magnus Holmgren        holmgren@debian.org
Debian Developer 

Message #109 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Frederik Himpe <frederik@frehi.be>

To: 755202@bugs.debian.org

Date: Mon, 02 Mar 2015 22:14:30 +0100

I discussed this problem on the upstream mailing list here:
http://thread.gmane.org/gmane.linux.network.networkmanager.devel/25377

In my case, the problem was indeed that netconsole was loaded.
Netconsole was loaded in the initrd, and brought the network interface
up. As the network interface went up, the kernel would automatically
configure an IPv6 address via SLAAC.

Then when later network-manager starts up, it notices that the network
interface is already brought up, and hence it decides not to touch it
any more: instead of loading the default network configuration for that
device, a (temporary) network connection with the name of the device and
the configuration corresponding to the actual state (in my case: IPv6
activated but no IPv4) is created in NM.

I removed the netconsole stuff, removed the eth0 network connection in
NM, and rebooted the system, and everything was OK again.

Apparently it's only safe to load netconsole after NM has started,
otherwise you get hit by this problem.

-- 
Frederik Himpe <frederik@frehi.be>

Message #114 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Frederik Himpe <frederik@frehi.be>

To: 755202@bugs.debian.org

Subject: Re:

Date: Wed, 04 Mar 2015 17:57:20 +0100

On ma, 2015-03-02 at 22:14 +0100, Frederik Himpe wrote:

> I removed the netconsole stuff, removed the eth0 network connection in
> NM, and rebooted the system, and everything was OK again.

I spoke too soon.

Now I'm again experiencing this problem, even without netconsole.

It looks like there is a race somewhere, causing the network interface
to be brought up before Network Manager is started, and this prevents
correct configuration by NM...

-- 
Frederik Himpe <frederik@frehi.be>

Message #119 received at 755202@bugs.debian.org (full text, mbox, reply):

From: "Joseph Rawson" <joseph.rawson.works@littledebian.org>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Wed, 11 Mar 2015 15:57:22 -0500

Hi!

I just came across this bug after reading the latest status report:
https://lists.debian.org/debian-devel-announce/2015/03/msg00002.html

I have a laptop that has been running jessie for a few months.  I use
NetworkManager to configure the wifi, but use /etc/network/interfaces for
eth0.

I experience a very similar problem when booting at a coffee shop where I
use wifi and ethernet is disconnected.  In this circumstance, eth0 fails
to get a lease (not surprising as there's no wire), but the exit hook
calls avahi-autoipd (/usr/sbin/avahi-autoipd -wD).  This is supposed to
set an ip address for eth0 until it is otherwise assigned, AFAICT.  The
problem seems to occur when setting a route, which seems to be done in
/etc/avahi/avahi-autoipd.action.  This is mentioned in this bug report: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533233 (wishlist bug).

The metric for my wlan0 route was 1024, so I set the base metric to 1025,
instead of 1000, in the autoipd.action file, and my wifi route wasn't
precluded by avahi-autoipd.

I don't know how much help this is, since I'm not really using
NetworkManager for ethernet, and only wifi, but if NetworkManager uses
dhclient, then encounters the avahi-autoipd hooks, the result could be
similar to the situation I described.

Message #124 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 755202@bugs.debian.org, "Felix C. Stegerman" <flx@obfusk.net>, Stefano Zacchiroli <zack@debian.org>

Subject: Re: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Fri, 13 Mar 2015 22:06:42 +0100

[Message part 1 (text/plain, inline)]

control: tags -1 moreinfo unreproducible

On Fri, 18 Jul 2014 21:35:52 +0200 "Felix C. Stegerman" <flx@obfusk.net>
wrote:
> Package: network-manager
> Version: 0.9.10.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> NetworkManager has started creating a new wired connection "eth0"
> after/during boot; this connection has ipv4 (and ipv6) disabled, and
> thus provides no connectivity.  I can manually select my original
> wired connection (standard dhcp) in gnome3 (or using nmcli), but it
> keeps creating the "eth0" interface and using it after restarting.
> 
> * Purging and re-installing NM does not help.
> * Modifying the "eth0" connection to enable ipv4 or creating a new
>   connection named "eth0" that has ipv4 enabled does not help -- NM
>   will simply create another connection named "eth0" and use that.
> * /var/log/syslog did not seem to include anything useful.
> 
> I really have no idea what's going on here.  I hope someone else does.
> Thanks.


Hi Felix, Zack, et al!

I'm not able to reproduce this issue with the information provided so
far or able to conclude what the issue is.. Unfortunately, this bug
report has become a bit of a hodgepodge. I'm not sure if all the me-too
reports are actually the same issue.

So, it would be immensly helpful, if someone can provide me with a
detailed description of his network setup (what interfaces are managed
by NetworkManager, what by ifupdown, what's the individual configuration
and available interfaces, etc.).
Then the exact circumstances, when this happens and if this happens
reliably and how it can be triggered.
Also, I'll need a verbose debug log from NetworkManager [1].

Ideally, someone provides steps how I can reproduce the issue myself
(e.g. by started from a basic/standard Debian Jessie installation).


Thanks,
Michael

[1] That means running NetworkManager (as root) with the following
command line arguments:
NetworkManager --no-daemon --log-level=DEBUG --debug
It's possible, that you need to remove the D-Bus activation symlinks,
i.e. run systemctl disable NetworkManager.service; systemctl stop
NetworkManager.service; <debug>; systemctl enable
NetworkManager.service; systemctl start NetworkManager.service

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #131 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Stefano Zacchiroli <zack@debian.org>

To: Michael Biebl <biebl@debian.org>, 755202@bugs.debian.org

Cc: "Felix C. Stegerman" <flx@obfusk.net>

Subject: Re: Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Fri, 13 Mar 2015 22:18:17 +0100

[Message part 1 (text/plain, inline)]

On Fri, Mar 13, 2015 at 10:06:42PM +0100, Michael Biebl wrote:
> So, it would be immensly helpful, if someone can provide me with a
> detailed description of his network setup (what interfaces are managed
> by NetworkManager, what by ifupdown, what's the individual configuration
> and available interfaces, etc.).
> Then the exact circumstances, when this happens and if this happens
> reliably and how it can be triggered.

Hey Michael, I've since then commented out the following lines in my
/etc/network/interfaces:

  # # The primary network interface
  # allow-hotplug eth0
  # iface eth0 inet dhcp
  # # This is an autoconfigured IPv6 interface
  # iface eth0 inet6 auto

after doing that I've not been able to reproduce this bug.

Not sure if this info helps or not...
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]

Message #136 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Fitzcarraldo <fitzcarraldo1@hotmail.com>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Tue, 17 Mar 2015 04:08:49 +0000

I started experiencing this problem in Gentoo Linux (~amd64 installation
using OpenRC) around 5 months ago. Keivan Moradi's fix (Message #79) did
not cure the problem for me, and, in any case, my wired NIC uses a
different driver (atl1c) which appears to be stable in my installation.
I think an invalid second eth0 connection started occurring after I
upgraded NetworkManager to Version 0.9.10.0, and has continued occurring
up to NM 1.0.0.

NetworkManager.conf contains the following:

[main]
plugins=keyfile
dhcp=dhcpcd
 
[ifnet]
managed=true
auto_refresh=false
 
[keyfile]
hostname=meshedgedx

In my case, NM usually (but not always) creates an invalid second eth0
connection when my laptop boots. The second eth0 connection is shown as
Active in plasma-nm (the KDE front-end for NM) but only has an IPv6
Link-Local connection configured (i.e. IPv4 is disabled). If I click on
Disconnect in plasma-nm then this eth0 connection disappears from
plasma-nm. Sometimes the valid available connection 'eth0' I configured
previously then connects automatically; other times I have to click
Connect. Either way, once the invalid IPv6 Link-Local connection has
been removed, the valid available connection can connect and access the
Internet.

I examined /var/log/messages when the invalid second eth0 connection
occurs and when it doesn't, and the invalid eth0 connection only occurs
when NM appears to have first run earlier than syslog-ng started
logging. When NM first runs after syslog-ng has started logging, I can
see it launches dhcpcd and acquires an IPv4 address. The avahi-daemon
does not seem to be the cause of the problem if I understand the log
file correctly. I could be misinterpreting what is going on, but that's
how it looks to my inexpert eyes.

I tried some experiments:

1. I commented out the entire contents of /etc/conf.d/net (the
configuration file for init scripts /etc/init.d/net.*) -- which I
*think* is analogous to Debian's /etc/network/interfaces -- but it did
not stop the invalid second eth0 connection occurring.

2. I added 'use-ipv6=no' and, later, 'use-ipv4=no' in
/etc/avahi/avahi-daemon.conf but they did not stop the invalid second
eth0 connection occurring.

3. I added 'deny-interfaces=eth0' in /etc/avahi/avahi-daemon.conf but it
did not stop the invalid second eth0 connection occurring.

4. In my installation the 'local' service (launched by initscript
/etc/init.d/local) has always been allocated to two runlevels: 'default'
and 'nonetwork'. I de-allocated the 'local' service from the 'nonetwork'
runlevel but this did not stop the invalid second eth0 connection occurring.

5. The 'net.lo' service (launched by initscript /etc/init.d/net.lo) has
always been allocated to the 'boot' runlevel (the other net.* services
-- such
as 'net.eth0' and 'net.wlan0' -- have never been allocated to a
runlevel). I de-allocated 'net.lo' from the boot runlevel but it did not
stop the invalid eth0 connection occurring.

[As experiments 4 and 5 did not stop the laptop accessing the Internet
once I had deleted the invalid second eth0 connection, I have left the
'local' service in the 'default' runlevel only, and left the 'net.lo'
service unallocated to a runlevel.]

6. Since the invalid eth0 connection gets allocated an IPv6 Link-Local
address rather than an IPv4 address, I tried a work-around: I disabled
IPv6 system-wide by uncommenting the line "alias net-pf-10 off" in the
file /etc/modprobe.d/aliases.conf. Now no invalid second eth0 connection
is created, and the valid eth0 connection I created previously connects
automatically. I have not rebooted many times yet, so I don't know if
this work-around has eliminated the problem for good.

Anyway, I would like to find the root cause of the problem, rather than
settling for a work-around of disabling IPv6 system-wide. The fact that
sometimes a second eth0 connection is not created and the 'good' eth0
connection created previously can connect, hopefully means it should be
possible to have both IPv6 and IPv4 enabled without an invalid eth0
connection ever being created.

Message #141 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Stefano Zacchiroli <zack@debian.org>, 755202@bugs.debian.org

Subject: Re: [Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Tue, 17 Mar 2015 20:16:10 +0100

[Message part 1 (text/plain, inline)]

Am 13.03.2015 um 22:18 schrieb Stefano Zacchiroli:
> On Fri, Mar 13, 2015 at 10:06:42PM +0100, Michael Biebl wrote:
>> So, it would be immensly helpful, if someone can provide me with a
>> detailed description of his network setup (what interfaces are managed
>> by NetworkManager, what by ifupdown, what's the individual configuration
>> and available interfaces, etc.).
>> Then the exact circumstances, when this happens and if this happens
>> reliably and how it can be triggered.
> 
> Hey Michael, I've since then commented out the following lines in my
> /etc/network/interfaces:
> 
>   # # The primary network interface
>   # allow-hotplug eth0
>   # iface eth0 inet dhcp
>   # # This is an autoconfigured IPv6 interface
>   # iface eth0 inet6 auto
> 
> after doing that I've not been able to reproduce this bug.
> 
> Not sure if this info helps or not...
> 

Well, this sounds like you have an eth0 configuration, which is enabled
always, even if there is not link. Eventually, dhclient times out and
you get a link-local address and most likely, the default route is set
via eth0.

I don't see that as a bug in NM, or do you disagree?
On could argue, that this is a misconfiguration and you should use
ifplugd to activate your connection when a link is available, or teach
ifup to fail if there is no link (or simply use NM for eth0 as well).


Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #146 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Fitzcarraldo <fitzcarraldo1@hotmail.com>

To: 755202@bugs.debian.org

Subject: Re: Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Thu, 19 Mar 2015 17:59:49 +0000

I hope you don't mind me commenting again on a Debian bug report, but
this problem occurs across distributions and I think my comments may be
of some relevance to Debian users too.

I'm even more convinced the problem seen by some (not all) of the users
commenting in this thread is due to a bug in NetworkManager. I believe
the issue with Avahi daemon generating an IPv6 Link-Local address is a
consequence of NetworkManager not always activating an interface and
therefore not obtaining an IPv4 address, i.e. the IPv6 Link-Local
address produced by the Avahi daemon is a side effect, not the root cause.

After my previous comment (Message #136) I discovered that adding
"use-ipv6=false" in /etc/avahi/avahi-daemon.conf had not prevented
avahi-daemon using IPv6. However, adding the following lines in
/etc/avahi/avahi-daemon.conf defintely *does* prevent avahi-daemon from
using IPv6 in my installation:

use-ipv4=true
use-ipv6=false
publish-a-on-ipv6=no
publish-aaaa-on-ipv4=no

You can see in the message log output below that the Avahi daemon is no
longer generating an IPv6 Link-Local address. However, even with IPv6
disabled in avahi-daemon, the problem of a second eth0 connection with
an IPv6 Link-Local address still occurs in my installation. This
indicates the problem is not caused by the Avahi daemon.

Mar 18 22:17:31 localhost syslog-ng[8316]: syslog-ng starting up;
version='3.6.2'
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  NetworkManager
(version 1.0.0) is starting...
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  Read config:
/etc/NetworkManager/NetworkManager.conf
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  WEXT support is
enabled
Mar 18 22:17:34 localhost kernel: fglrx_pci 0000:01:00.0: irq 34 for
MSI/MSI-X
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8351
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8352
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8353
Mar 18 22:17:34 localhost kernel: <6>[fglrx] IRQ 34 Enabled
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Shared
offset:0, size:1000000
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared
offset:f7e2000, size:4000
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared
offset:f7e6000, size:51a000
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared
offset:3fff3000, size:d000
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded plugin
keyfile: (c) 2007 - 2013 Red Hat, Inc.  To report bugs please use the
NetworkManager mailing list.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection
/etc/NetworkManager/system-connections/Cisco00497
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection
/etc/NetworkManager/system-connections/eth0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection
/etc/NetworkManager/system-connections/DIRECT-HeC460 Series
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  monitoring
kernel firmware directory '/lib/firmware'.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  rfkill0: found
WiFi radio killswitch (at
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill0) (driver
iwlwifi)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi hardware
radio set enabled
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN hardware
radio set enabled
Mar 18 22:17:33 localhost /etc/init.d/NetworkManager[8326]: WARNING:
NetworkManager has started, but is inactive
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device
plugin: /usr/lib64/NetworkManager/libnm-device-plugin-bluetooth.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device
plugin: /usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device
plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wwan.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device
plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi disabled by
radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN enabled by
radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiMAX enabled by
radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Networking is
enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): link connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): carrier is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): new
Generic device (driver: 'unknown' ifindex: 1)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): exported
as /org/freedesktop/NetworkManager/Devices/0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): link
connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): carrier
is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): new
Ethernet device (driver: 'atl1c' ifindex: 2)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): exported
as /org/freedesktop/NetworkManager/Devices/1
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device
state change: unmanaged -> unavailable (reason 'connection-assumed') [10
20 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device
state change: unavailable -> disconnected (reason 'connection-assumed')
[20 30 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  startup complete
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: starting connection 'eth0'
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 1 of 5 (Device Prepare) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): using
nl80211 for WiFi device control
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): new
802.11 WiFi device (driver: 'iwlwifi' ifindex: 3)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0):
exported as /org/freedesktop/NetworkManager/Devices/2
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): device
state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0):
preparing device
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 1 of 5 (Device Prepare) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device
state change: disconnected -> prepare (reason 'none') [30 40 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 2 of 5 (Device Configure) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 1 of 5 (Device Prepare) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 2 of 5 (Device Configure) starting...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device
state change: prepare -> config (reason 'none') [40 50 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 2 of 5 (Device Configure) successful.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 3 of 5 (IP Configure Start) scheduled.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 2 of 5 (Device Configure) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 3 of 5 (IP Configure Start) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device
state change: config -> ip-config (reason 'none') [50 70 0]
Mar 18 22:17:33 localhost dbus[7763]: [system] Activating service
name='org.freedesktop.ModemManager1' (using servicehelper)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 5 of 5 (IPv6 Commit) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 3 of 5 (IP Configure Start) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 5 of 5 (IPv6 Commit) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device
state change: ip-config -> ip-check (reason 'none') [70 80 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0):
Activation: Stage 5 of 5 (IPv6 Commit) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device
state change: ip-check -> secondaries (reason 'none') [80 90 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device
state change: secondaries -> activated (reason 'none') [90 100 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  NetworkManager
state is now CONNECTED_LOCAL
Mar 18 22:17:33 localhost acpid[8386]: starting up with netlink and the
input layer
Mar 18 22:17:33 localhost acpid[8386]: 6 rules loaded
Mar 18 22:17:33 localhost acpid[8386]: waiting for events: event logging
is off
Mar 18 22:17:34 localhost ModemManager[8385]: <info>  ModemManager
(version 1.4.2) starting in system bus...
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  (eth0):
Activation: successful, device activated.
Mar 18 22:17:34 localhost dbus[7763]: [system] Activating service
name='org.freedesktop.nm_dispatcher' (using servicehelper)
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated
service 'org.freedesktop.nm_dispatcher'
Mar 18 22:17:34 localhost nm-dispatcher[8435]: Dispatching action 'up'
for eth0
Mar 18 22:17:34 localhost rpc.statd[8451]: Version 1.3.2 starting
Mar 18 22:17:34 localhost rpc.statd[8451]: Flags: TI-RPC
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8457]: status: inactive
Mar 18 22:17:34 localhost rpc.statd[8451]: Running as root.  chown
/var/lib/nfs to choose different user
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8469]: status: inactive
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated
service 'org.freedesktop.ModemManager1'
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager
disappeared from bus
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager
available in the bus
Mar 18 22:17:35 localhost sm-notify[8556]: Version 1.3.2 starting
Mar 18 22:17:35 localhost avahi-daemon[8585]: Found user 'avahi' (UID
108) and group 'avahi' (GID 444).
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped root
privileges.
Mar 18 22:17:35 localhost avahi-daemon[8585]: avahi-daemon 0.6.31
starting up.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully called chroot().
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped
remaining capabilities.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file
/services/sftp-ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file
/services/ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Network interface
enumeration completed.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Registering HINFO record
with values 'X86_64'/'LINUX'.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Server startup complete.
Host name is meshedgedx.local. Local service cookie is 3778762828.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx"
(/services/ssh.service) successfully established.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx"
(/services/sftp-ssh.service) successfully established.
Mar 18 22:17:35 localhost ntpd[8645]: ntpd 4.2.8@1.3265-o Wed  4 Mar
02:23:30 UTC 2015 (1): Starting
Mar 18 22:17:35 localhost ntpd[8645]: Command line: ntpd -g -q
Mar 18 22:17:35 localhost ntpd[8645]: proto: precision = 0.061 usec (-24)
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 0 v6wildcard
[::]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 1 v4wildcard
0.0.0.0:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 2 lo 127.0.0.1:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 3 lo [::1]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 4 eth0
[fe80::725a:b6ff:fe3e:c18a%2]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listening on routing socket on fd
#21 for interface updates
Mar 18 22:17:36 localhost kernel: fbcondecor: console 1 using theme
'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to
'on' on console 1
Mar 18 22:17:37 localhost kernel: fbcondecor: console 2 using theme
'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to
'on' on console 2
Mar 18 22:17:37 localhost kernel: fbcondecor: console 3 using theme
'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to
'on' on console 3
Mar 18 22:17:37 localhost kernel: fbcondecor: console 4 using theme
'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to
'on' on console 4
Mar 18 22:17:37 localhost kernel: fbcondecor: console 5 using theme
'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to
'on' on console 5
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth daemon 5.28
Mar 18 22:17:36 localhost bluetoothd[8787]: Starting SDP server
Mar 18 22:17:37 localhost kernel: Bluetooth: Core ver 2.19
Mar 18 22:17:37 localhost kernel: NET: Registered protocol family 31
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI device and connection
manager initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: L2CAP socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: SCO socket layer initialized
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP (Ethernet Emulation)
ver 1.3
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP filters: protocol
multicast
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP socket layer initialized
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth management
interface 1.7 initialized
Mar 18 22:17:36 localhost NetworkManager[8346]: <info>  use BlueZ version 5
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find
support for device at
'/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0': not supported by
any plugin
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find
support for device at
'/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by
any plugin
Mar 18 22:17:39 localhost dbus[7763]: [system] Activating service
name='org.freedesktop.ColorManager' (using servicehelper)
Mar 18 22:17:39 localhost dbus[7763]: [system] Successfully activated
service 'org.freedesktop.ColorManager'
Mar 18 22:17:41 localhost kernel: nf_conntrack: automatic helper
assignment is deprecated and it will be removed soon. Use the iptables
CT target to attach helpers instead.
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC=
SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a
DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1
FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC=
SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a
DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1
FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24
Mar 18 22:17:43 localhost laptop-mode[8947]: Laptop mode
Mar 18 22:17:43 localhost laptop-mode[8948]: enabled, not active
Mar 18 22:17:58 localhost kernel: Installing knfsd (copyright (C) 1996
okir@monad.swb.de).
Mar 18 22:17:58 localhost rpc.mountd[9741]: Version 1.3.2 starting
Mar 18 22:17:59 localhost kernel: NFSD: Using /var/lib/nfs/v4recovery as
the NFSv4 state recovery directory
Mar 18 22:17:59 localhost kernel: NFSD: starting 90-second grace period
(net ffffffff81c3d580)
Mar 18 22:17:58 localhost sm-notify[9760]: Version 1.3.2 starting
Mar 18 22:17:58 localhost sm-notify[9760]: Already notifying clients;
Exiting!
Mar 18 22:18:00 localhost sshd[9816]: Server listening on 0.0.0.0 port 22.
Mar 18 22:18:00 localhost sshd[9816]: Server listening on :: port 22.
Mar 18 22:18:00 localhost cron[9870]: (CRON) STARTUP (V5.0)
Mar 18 22:18:00 localhost su[9899]: Successful su for fitzcarraldo by root
Mar 18 22:18:00 localhost su[9899]: + /dev/console root:fitzcarraldo
Mar 18 22:18:00 localhost su[9899]: pam_unix(su:session): session opened
for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost dbus[7763]: [system] Activating service
name='org.freedesktop.RealtimeKit1' (using servicehelper)
Mar 18 22:18:01 localhost dbus[7763]: [system] Successfully activated
service 'org.freedesktop.RealtimeKit1'
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully called chroot.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully dropped
privileges.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully limited
resources.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Watchdog thread running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Canary thread running.
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]: pam_unix(kde:session):
session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]:
pam_ck_connector(kde:session): nox11 mode, ignoring PAM_TTY :0
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] sink.c: Default
and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] source.c:
Default and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0
processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio]
module-jackdbus-detect.c: Unable to contact D-Bus session bus:
org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a
dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] module.c:
Failed to load module "module-jackdbus-detect" (argument: "channels=2"):
initialization failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Module
load failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio]
server-lookup.c: Unable to contact D-Bus:
org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a
dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Unable
to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to
autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost su[9899]: pam_unix(su:session): session closed
for user fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9964]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session opened
for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session closed
for user fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9966]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session opened
for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session closed
for user fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9968]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session opened
for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session closed
for user fitzcarraldo
Mar 18 22:18:15 localhost dbus[7763]: [system] Activating service
name='org.freedesktop.UPower' (using servicehelper)
Mar 18 22:18:15 localhost dbus[7763]: [system] Successfully activated
service 'org.freedesktop.UPower'
Mar 18 22:18:17 localhost dbus[7763]: [system] Activating service
name='org.freedesktop.UDisks2' (using servicehelper)
Mar 18 22:18:17 localhost udisksd[10120]: udisks daemon version 2.1.4
starting
Mar 18 22:18:17 localhost dbus[7763]: [system] Successfully activated
service 'org.freedesktop.UDisks2'
Mar 18 22:18:17 localhost udisksd[10120]: Acquired the name
org.freedesktop.UDisks2 on the system message bus
Mar 18 22:18:19 localhost kernel: [UFW BLOCK] IN=eth0 OUT=
MAC=01:00:5e:00:00:01:00:16:fa:25:28:01:08:00 SRC=0.0.0.0 DST=224.0.0.1
LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=0 PROTO=2
Mar 18 22:18:54 localhost hp-systray[10453]: hp-systray[10453]: error:
option -s not recognized
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Successfully made thread
10469 of process 10469 (/usr/bin/pulseaudio) owned by '1000' high
priority at nice level -11.
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Supervising 1 threads of 1
processes of 1 users.
Mar 18 22:18:55 localhost pulseaudio[10469]: [pulseaudio] pid.c: Daemon
already running.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Successfully made thread
10485 of process 10485 (/usr/bin/pulseaudio) owned by '1000' high
priority at nice level -11.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Supervising 1 threads of 1
processes of 1 users.
Mar 18 22:18:56 localhost pulseaudio[10485]: [pulseaudio] pid.c: Daemon
already running.
Mar 18 22:19:04 localhost polkitd[7911]: Registered Authentication Agent
for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name
:1.52 [/usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1],
object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8)
Mar 18 22:19:10 localhost su[10569]: Successful su for root by fitzcarraldo
Mar 18 22:19:10 localhost su[10569]: + /dev/pts/0 fitzcarraldo:root
Mar 18 22:19:10 localhost su[10569]: pam_unix(su:session): session
opened for user root by fitzcarraldo(uid=1000)
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog]
alsa-sink.c: ALSA woke us up to write new data to the device, but there
was actually nothing to write!
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog]
alsa-sink.c: Most likely this is a bug in the ALSA driver
'snd_hda_intel'. Please report this issue to the ALSA developers.
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog]
alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent
snd_pcm_avail() returned 0 or another value < min_avail.
Mar 18 22:20:01 localhost cron[10670]: (root) CMD (test -x
/usr/sbin/run-crons && /usr/sbin/run-crons)

In the cases when NetworkManager activates a connection correctly and
there is no invalid second eth0 connection, the log contains a message
like the following:

Mar 16 22:23:47 localhost NetworkManager[6688]: <info>  Auto-activating
connection 'eth0'.

Notice there is no such message in the message log output listed above.

The only way I can be sure of preventing NetworkManager creating an
invalid second eth0 connection is to disable IPv6 system-wide by
uncommenting the line "alias net-pf-10 off" in the file
/etc/modprobe.d/aliases.conf.

So, to me, this looks like a bug in NetworkManager.

By the way, in my previous comment (Message #136) I quoted the wrong
contents of my NetworkManager.conf file. In fact the contents are as
follows:

[main]
plugins=keyfile
dhcp=dhcpcd
no-auto-default=eth0

[keyfile]
hostname=meshedgedx

Message #151 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Fitzcarraldo <fitzcarraldo1@hotmail.com>, 755202@bugs.debian.org

Subject: Re: [Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Tue, 31 Mar 2015 08:49:06 +0200

[Message part 1 (text/plain, inline)]

Am 19.03.2015 um 18:59 schrieb Fitzcarraldo:
> Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection
> /etc/NetworkManager/system-connections/eth0

Can you attach this file /etc/NetworkManager/system-connections/eth0?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #156 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 755202@bugs.debian.org

Subject: Re: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Tue, 31 Mar 2015 19:00:31 +0200

[Message part 1 (text/plain, inline)]

Talked to upstream about this problem.
Attached is the IRC log.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[irc-log.txt (text/plain, attachment)]

[signature.asc (application/pgp-signature, attachment)]

Message #161 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Fitzcarraldo <fitzcarraldo1@hotmail.com>

To: Michael Biebl <biebl@debian.org>

Cc: 755202@bugs.debian.org

Subject: Re: [Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Tue, 31 Mar 2015 21:27:08 +0100

[Message part 1 (text/plain, inline)]

-------- Original Message --------
*Subject: *Re: [Pkg-utopia-maintainers] Bug#755202: network-manager:
keeps creating and using new connection "eth0" that does not work
*From: *Michael Biebl <biebl@debian.org>
*To: *Fitzcarraldo <fitzcarraldo1@hotmail.com>, 755202@bugs.debian.org
*Date: *31/03/15 07:49
> Am 19.03.2015 um 18:59 schrieb Fitzcarraldo:
>> Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection
>> /etc/NetworkManager/system-connections/eth0
> Can you attach this file /etc/NetworkManager/system-connections/eth0?
>

As requested, I attach the file
/etc/NetworkManager/system-connections/eth0. Its contents are also
listed below:

[ethernet]
mac-address=70:5A:B6:3E:C1:8A
mac-address-blacklist=

[connection]
id=eth0
uuid=cb3d5786-f947-44b8-92f7-8471fc94c568
type=ethernet
permissions=user:fitzcarraldo:;
secondaries=

[ipv6]
method=ignore
dns-search=

[ipv4]
method=auto
dns-search=
may-fail=false

My current situation is as follows, and no invalid second eth0
connection is created:

IPv6 is enabled in aliases.conf
IPv6 is disabled in avahi-daemon.conf
[ipv6] method=ignore
[ipv4] method=auto
[ipv4] may-fail=false

If I make the situation as follows, no invalid second eth0 connection is
created either (which is not surprising given that IPv6 is disabled
system-wide):

IPv6 is disabled in aliases.conf
IPv6 is enabled in avahi-daemon.conf
[ipv6] method=ignore
[ipv4] method=auto
[ipv4] may-fail=true

When the situation is as follows an invalid second eth0 connection is
usually (i.e. more often than not) created:

IPv6 is enabled in aliases.conf
IPv6 is enabled in avahi-daemon.conf
[ipv6] method=ignore
[ipv4] method=auto
[ipv4] may-fail=true

Message #166 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Fitz carraldo <fitzcarraldo1@hotmail.com>

To: "755202@bugs.debian.org" <755202@bugs.debian.org>

Subject: Re: Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Wed, 15 Apr 2015 11:45:01 +0100

[Message part 1 (text/plain, inline)]

Actually, since my last message (#161) I 
have found that, very, very occasionally, an invalid second eth0 
connection is created even in the following situation:



IPv6 enabled in aliases.conf: yes

IPv6 enabled in avahi-daemon.conf: no

[ipv6] method=ignore

[ipv4] method=auto

[ipv4] may-fail=false



So it seems the only sure-fire way of stopping NetworkManager from 
creating an invalid second eth0 connection (IPv6 Link-Local connection) is to disable IPv6 
system-wide.



 		 	   		  

[Message part 2 (text/html, inline)]

Message #169 received at 755202@bugs.debian.org (full text, mbox, reply):

From: "County Court" <neil.ross@m2.sandu.beget.ru>

To: 755202@bugs.debian.org

Subject: Notice to Appear in Court

Date: Wed, 24 Jun 2015 09:14:33 +0300

[Message part 1 (text/plain, inline)]

Notice to Appear,

This is to inform you to appear in the Court on the June 30 for your case hearing.
Please, do not forget to bring all the documents related to the case.
Note: If you do not come, the case will be heard in your absence.

The copy of Court Notice is attached to this email.

Kind regards,
Neil Ross,
Clerk of Court.

[00000791952.zip (application/zip, attachment)]

Message #179 received at 755202@bugs.debian.org (full text, mbox, reply):

From: "M. Buecher" <maddes+debian@maddes.net>

To: <755202@bugs.debian.org>

Subject: Re: network-manager: keeps creating and using new connection "eth0"

Date: Fri, 10 Jul 2015 12:10:22 +0200

Hello Michael,

to reproduce this behaviour is quite easy.
During Debian installation create an encrypted root fs, then 
additionally install dropbear.
Due to Dropbear the network will be configured in initramfs with the 
current ip data.

This will cause an already configured eth0 at the time when Network 
Manager gets started.

Kind regards
Maddese

Message #184 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Matthias Buecher / Germany <maddes@maddes.net>

To: 755202@bugs.debian.org

Subject: Re: Workaround - network-manager: keeps creating and using new connection "eth0"

Date: Tue, 14 Jul 2015 15:04:25 +0200

To avoid this issue for now I defined eth0 as wanted in
/etc/network/interfaces and have "managed=false" in
/etc/NetworkManager/NetworkManager.conf
See [1]

[1] https://wiki.debian.org/NetworkManager#Wired_Networks_are_Unmanaged

Message #189 received at 755202@bugs.debian.org (full text, mbox, reply):

From: support@radiovybe.com

To: 755202@bugs.debian.org

Subject: 755202@bugs.debian.org let your ideas and broadcast go further. ir

Date: Thu, 01 Oct 2015 14:57:31 +0200

Hey Good day,

Give your your station more exposure, let your ideas and broadcast reach new frontiers, make it more exciting and interactive.  Freely signup online on www.radiovybe.com to register your station and interact globally with listeners.

www.radiovybe.com

Message #194 received at 755202@bugs.debian.org (full text, mbox, reply):

From: support@radiovybe.com

To: 755202@bugs.debian.org

Subject: 755202@bugs.debian.org let your ideas and broadcast go further.

Date: Thu, 01 Oct 2015 15:14:02 +0200

Hi Good day,

Give your your station more exposure, let your ideas and broadcast reach new frontiers, make it more exciting and interactive.  Freely signup online on www.radiovybe.com to register your station and interact globally with listeners.

www.radiovybe.com

Message #199 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Aspire Money Loan® <ra79461@uem.br>

To: undisclosed-recipients:;

Subject: dringende reactie

Date: Tue, 13 Oct 2015 22:25:53 -0200 (BRST)

groeten,
          Ik ben mevrouw Annie Ethan uit een particuliere kredietverlening bedrijf dat bekend staat als Aspire Money Loan®. Wij bieden alle soorten lening tegen 3% rente. Als u behoefte van de lening zo vriendelijk contact met ons op met de onderstaande informatie.
Volledige naam:
Geslacht:
land:
adres:
Leenbedrag:
duur:
tel:
Wij wachten uw reactie als je geïnteresseerd bent
Dankjewel,
Annie Ethan

-- 
Esta mensagem foi verificada pelo sistema de antivirus e
 acredita-se estar livre de perigo.

Message #204 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Jan Heitkoetter <jan@heitkoetter.net>

To: Debian Bug Tracking System <755202@bugs.debian.org>

Subject: network-manager: Bug also present in Raspbian Jessie

Date: Tue, 26 Jan 2016 23:17:33 +0100

Package: network-manager
Version: 0.9.10.0-7
Followup-For: Bug #755202

Dear Maintainer,

It occours to me that this bug is still present in Raspbian Jessie.

I'm trying to set up eth0 with static IP.

/etc/network/interfaces:
# Please note that this file is written to be used with dhcpcd.
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'.

auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet dhcp

#auto wlan0
#allow-hotplug wlan0
#iface wlan0 inet dhcp
#wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

#iface default inet dhcp


Rebooting after installing network-manager, network-manager has automatically created a connection 16a3... using device eth0 and DHCP:
root@himbeere2:/home/jan# nmcli c s
NAME  UUID                                  TYP             GERÄT 
eth0  16a38f40-3cd1-4794-a7b3-e86c318546ca  802-3-ethernet  eth0  


Now editing this connection:
root@himbeere2:/home/jan# nmcli c e eth0

===| nmcli interaktiver Verbindungs-Editor |===

Bestehende Verbindung »802-3-ethernet« wird bearbeitet: »eth0«

[setting static IP etc.]

nmcli> save
Saving the connection with 'autoconnect=yes'. That might result in an immediate activation of the connection.
Do you still want to save? (ja/nein) [ja] 
Verbindung »eth0« (16a38f40-3cd1-4794-a7b3-e86c318546ca) erfolgreich aktualisiert.
nmcli> quit


Reboot and see what happens:
root@himbeere2:/home/jan# reboot

[...]

jan@himbeere2:~$ sudo nmcli c s
[sudo] password for jan: 
NAME  UUID                                  TYP             GERÄT 
eth0  84150a4e-91b0-446d-b324-4298ff3b1d77  802-3-ethernet  eth0  
eth0  16a38f40-3cd1-4794-a7b3-e86c318546ca  802-3-ethernet  --    

network-manager has created another connection 8415... claiming device eth0 and using DHCP. It does so after each reboot. I would expect network-manager to use the existing connection 16a3...


No conffile for 8415...:
jan@himbeere2:~$ ls -l /etc/NetworkManager/system-connections/
insgesamt 4
-rw------- 1 root root 267 Jan 26 22:52 eth0


Conffile for 16a3... is there (contents OK):
jan@himbeere2:~$ sudo grep uuid /etc/NetworkManager/system-connections/eth0
uuid=16a38f40-3cd1-4794-a7b3-e86c318546ca


/etc/NetworkManager/NetworkManager.conf:
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

Regards

Jan

P.S. Does nobody take care about all those spam replies?

-- System Information:
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 8.0 (jessie)
Release:	8.0
Codename:	jessie
Architecture: armv7l

Kernel: Linux 4.1.15-v7+ (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser                3.113+nmu3
ii  dbus                   1.8.20-0+deb8u1
ii  init-system-helpers    1.22
ii  isc-dhcp-client        4.3.1-6+deb8u2
ii  libc6                  2.19-18+deb8u2
ii  libdbus-1-3            1.8.20-0+deb8u1
ii  libdbus-glib-1-2       0.102-1
ii  libgcrypt20            1.6.3-2
ii  libglib2.0-0           2.42.1-1
ii  libgnutls-deb0-28      3.3.8-6+deb8u3
ii  libgudev-1.0-0         215-17+deb8u3
ii  libmm-glib0            1.4.0-1
ii  libndp0                1.4-2
ii  libnewt0.52            0.52.17-1
ii  libnl-3-200            3.2.24-2
ii  libnl-genl-3-200       3.2.24-2
ii  libnl-route-3-200      3.2.24-2
ii  libnm-glib4            0.9.10.0-7
ii  libnm-util2            0.9.10.0-7
ii  libpam-systemd         215-17+deb8u3
ii  libpolkit-gobject-1-0  0.105-8
ii  libreadline6           6.3-8
ii  libsoup2.4-1           2.48.0-1
ii  libsystemd0            215-17+deb8u3
ii  libteamdctl0           1.12-2
ii  libuuid1               2.25.2-6
ii  lsb-base               4.1+Debian13+rpi1+nmu1
ii  policykit-1            0.105-8
ii  udev                   215-17+deb8u3
ii  wpasupplicant          2.3-1+deb8u3

Versions of packages network-manager recommends:
ii  crda            3.13-1
ii  dnsmasq-base    2.72-3+deb8u1
ii  iptables        1.4.21-2
ii  iputils-arping  3:20121221-5
ii  modemmanager    1.4.0-1
ii  ppp             2.4.6-3.1

Versions of packages network-manager suggests:
pn  avahi-autoipd  <none>
pn  libteam-utils  <none>

-- no debconf information

Message #209 received at 755202@bugs.debian.org (full text, mbox, reply):

From: "Healey, Martha E" <HealeyM@mustangps.org>

To: "info@gmail.com" <info@gmail.com>

Subject: fcs76754@gmail.com

Date: Fri, 11 Mar 2016 20:11:48 +0000

Need Loan? Contact Us Via Email: fcs76754@gmail.com


The information contained in this e-mail message, and any files transmitted with it, is confidential and may be legally privileged. It is intended only for the use of the individuals or entities named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or forwarding of this e-mail message is strictly prohibited. If you have received this e-mail message in error, please notify the sender from Mustang Public Schools and delete the material from any computer. Thank you for your cooperation.

Message #216 received at 755202@bugs.debian.org (full text, mbox, reply):

From: titkarsag@ceglediszc.hu

To: Recipients <titkarsag@ceglediszc.hu>

Subject: lening bieden

Date: Wed, 10 Aug 2016 04:17:02 +0300

[Message part 1 (text/plain, inline)]

Dit is de UniCredit Group leningen, bieden wij een 3% zakelijke kredieten en persoonlijke leningen.
 Vul het formulier in als je geïnteresseerd bent
 Naam en achternaam:
seksuele:
land:
Het benodigde bedrag van de lening:
duur:
 Victoria Nicole

[Message part 2 (text/html, inline)]

Message #221 received at 755202@bugs.debian.org (full text, mbox, reply):

From: FROM MRS LINAH MOHOHLO <linahmohohlo214@gmail.com>

Subject: THIS IS FOR HUMANITY PLEASE VIEW THE ATTACHED FILE AND GET BACK TO ME

Date: Mon, 15 Aug 2016 15:52:47 +0000 (UTC)

[Message part 1 (text/plain, inline)]

THIS IS FOR HUMANITY PLEASE VIEW THE ATTACHED FILE AND GET BACK TO ME

[FROM MRS. LINAH MOHOHLO.pdf (application/pdf, attachment)]

Message #266 received at 755202@bugs.debian.org (full text, mbox, reply):

From: <jamesheer@hh.be>

To: Recipients <jamesheer@hh.be>

Subject: Sure Opportunity.

Date: Wed, 28 Sep 2016 20:40:36 +0400

Hello,

My name is James, a Trader, Auditor, Mentor, Investment Manager, Logistics Expert and General Business Man, I stay in London, UK. I contact you in respect of establishing a business relationship with you.

There is a certain amount of money that belongs to me. I intend to take the money out of the Germany to another location and bring back the money on a later date for investment and my own personal use. I made this money in the course of auditing a big Investment Firm in Germany and discovered this money as some excesses. 

When I discovered these funds, I discussed the issue with the Company's accountant General as well as their personal relationship banker/adviser. This company in question is a very huge company and has been doing business for a very long time, since 1950s.

In the course of genuine business over this period, the money described above has been floating in the banking system and was recently made known to the Company's Accountant General by me. The Company's Accountant General has been a close friend of mine over time. I've been one of this company's Official Auditor General for over 25 years. 

You may now understand why we need to take the money safely out of Germany before spending it. Here's our plan, we intend to get a neutral individual who is willing and able to receive this money in form of investment funds to be used by the individual in infrastructural projects, real estate investment or trade etc. 

This is just to get the funds out of The Bank where it is presently, to the receiver's bank only. However, the deal is that the funds would be shared into 4 equal places and each of us would be entitled to equal parts of the funds after you receive. I'm talking about Me, You, The Company's Accountant General and The Senior Officer at The Bank who is the company's personal relationship banker/adviser.

We do not require any complicated paperwork or lawyer agreements etc to get this work done. Our agreement would be between 4 of us only as we require utmost confidentiality in this matter. You do not have to tell your bank the details being given in respect of these funds. All we require from you is your willingness and ability to receive the funds in question.

With all these in place, The Bank will initiate wire transfer of the funds to your account. We expect that we act according to the agreement we shall get to in respect of this. This isn't a risky operation or money laundering. Its just a simple opportunity which we intend to exploit using an absolute stranger.

Let me know if this is something you would like to be a part of. If you have any questions, please ask. We would be very glad to move forward on this immediately but require utmost and absolute confidentiality. I'm very willing to furnish you every information you might require so long you promise not to betray privileged information getting to you as a result of this communication.

Thanks for your time. I await your response.

Regards,
James Heer.

Message #306 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Daniel Reichelt <debian@nachtgeist.net>

To: 755202@bugs.debian.org

Subject: Re: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Fri, 5 May 2017 03:21:45 +0200

[Message part 1 (text/plain, inline)]

Hi folks,

here are some more insights into this mystery:

My "victim" box:

- kvm-guest: jessie, task-xfce-desktop, sysvinit instead of systemd
- running with -net nic,model=rtl8139 -net tap
- connected to br0 of the kvm host which also contains the host's eth0
- the guest's /etc/network/interfaces or NM-config were left unchanged
after jessie-netinstall


In the guest, I did:

# touch /etc/.legacy-bootordering

and tweaked /etc/init.d/rc to display `ip addr list` and a debug login
shell after the execution of every single init script. Now, after
/etc/rcS.d/S03udev got executed, udev modprobe'd 8139too/8139cp for the
virtual Realtec nic.

What *really* surprised me: The output of `ip addr list` after S03udev
finished showed different link states across different boot processes.
AFAICT the Realtek's link state after modprobing is determined by fair
dice roll. I couldn't infer any relation between the link state after
modprobing and

- a freshly invoked kvm guest
- shutdown -r from within the guest
- echo b >/proc/sysrq-trigger from within the guest
- "system_reset" sent to the qemu_system-x86_64 process's control socket

- the link state prior to any of these four variants to reboot



As a consequence I could observe:

- When the link state was DOWN after modprobing, of course no v6 SLAAC
happened and NM configured eth0 just fine with both v4 and v6.

- When the link state was UP after modprobing, SLAAC happened which
triggered NM's "undesired behavior" to "connection-assume" eth0.
(This case then easily becomes a race-condition with concurrent
execution of the init scripts.)



Judging whether this is an error in this specific driver or in the Linux
networking layer goes way over my head. At the very least I can say that
I'm completely baffled by this observation.



Cheers

Daniel

[signature.asc (application/pgp-signature, attachment)]

Message #311 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Daniel Reichelt <debian@nachtgeist.net>

To: 755202@bugs.debian.org

Subject: Re: network-manager: keeps creating and using new connection "eth0" that does not work

Date: Fri, 5 May 2017 03:28:01 +0200

[Message part 1 (text/plain, inline)]

PS: a very crude workaround for this:

# cat /etc/default/NetworkManager
if [ -z "$(ip -4 addr list dev eth0)" ] && [ -n "$(ip -6 addr list dev
eth0)" ]
then
        ip link set down dev eth0
        ip addr flush dev eth0
fi

[signature.asc (application/pgp-signature, attachment)]

Message #316 received at 755202@bugs.debian.org (full text, mbox, reply):

From: PRIVATE LOAN SOLUTIONS LIMITED <info.compensationplc@gmail.com>

To: undisclosed-recipients:;

Subject: Heb je zakelijke of persoonlijke lening nodig,

Date: Wed, 14 Jun 2017 00:28:07 +0530

Heb je zakelijke of persoonlijke lening nodig, mail ons nu
privatelenders87@gmail.com

Message #321 received at 755202@bugs.debian.org (full text, mbox, reply):

From: Josephine Cessario - SVHM <Josephine.CESSARIO@svha.org.au>

To: Info <Info@svha.org.au>

Subject: Help

Date: Thu, 16 Nov 2017 13:15:28 +0000

[Message part 1 (text/plain, inline)]

I have a Business offer if you are interested Please reply me Via email: (sergeant73636@gmail.com) to discuss in details Sgt Bridgett L.

______________________________________________________________________
This email and any attachments to it (the "Email") is confidential and is for the use only of the intended recipient, and may not be duplicated or used by any other party without the express consent of the sender.  If you are not the intended recipient of the Email, please notify the sender immediately by return email, delete the Email, and do not copy, print, retransmit, store or act in reliance on the Email.  St Vincent's Health Australia ("SVHA") does not guarantee that the Email is free from errors, viruses or interference. Emails to and from SVHA or its related entities may be scanned and filtered in locations outside Australia.

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.