[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work
Hey folks, previously, people suggested completely disabling ipv6 as a workaround (or at least debugging tool). This, combined with the previous analysis made me realize another workaround: Just disable ipv6 autoconf by the kernel. I dropped these two lines in my sysctl.conf: net.ipv6.conf.eth0.autoconf=0 net.ipv6.conf.eth0.accept_ra=0 Now, this bug seems to be gone (even with the 5-second sleep, tried twice so far). From my logs, I see that a link-local ipv6 address is still assigned, but apparently that does not trigger the broken behaviour. Also, this only prevents ipv6 configuration during the initial boot, when the boot is complete, eth0 has a complete set of ipv6 addresses as well (presumably because NetworkManager handles this). Gr. Matthijs signature.asc Description: PGP signature ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work
Package: network-manager Version: 1.10.4-1+b1 Followup-For: Bug #755202 Hi folks, I've also been seeing this bug on my system for quite some while now, and decided to investigate today. I haven't quite figured it out, but I'll share my findings here. >From the previous discussion on this bug, most notably the IRC log posted, I understand that the problem is somewhat like this: - On boot, something brings up the ethernet interface (or are network interfaces up by default?) - The interface gets a link-local ipv6 and/or statelessly autoconfigured global ipv6 address (handled by the kernel, I believe?). - NetworkManager starts, and finds a (partially configured interface). - NetworkManager starts managing the interface (with reason 'connection-assumed') and creates a new (temporary) connection profile called 'eth0' that copies the current settings from the interface. - NetworkManager does *not* activate the normal default connection profile for the interface. I haven't been able to confirm the above is exactly what happens, but my observations do seem to match the above theory. I have been trying to pinpoint the code path that handles it, without much succes. I enabled trace logging (see NetworkManager.conf below) and that caused debug and trace log entries to appear, but nothing I could completely correlate with the source. Here's the relevant bit of the log, where it apparently decides to create a new connection. This is from 1.6.2, but with the output is pretty much the same with 1.10.4. device (eth0): link connected manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2) manager: (eth0.10): new VLAN device (/org/freedesktop/NetworkManager/Devices/3) manager: (eth0.253): new VLAN device (/org/freedesktop/NetworkManager/Devices/4) keyfile: add connection in-memory (056caea2-6833-42cc-bdc5-bd8c5744c8a9,"eth0") device (eth0): state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41] device (eth0): state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41] device (eth0): Activation: starting connection 'eth0' (056caea2-6833-42cc-bdc5-bd8c5744c8a9) Looking at the source, I would expect these lines to come from: keyfile: add connection in-memory (056caea2-6833-42cc-bdc5-bd8c5744c8a9,"eth0") https://github.com/NetworkManager/NetworkManager/blob/1.6.2/src/nm-manager.c#L1846 https://github.com/NetworkManager/NetworkManager/blob/1.6.2/src/nm-manager.c#L1762 device (eth0): state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41] https://github.com/NetworkManager/NetworkManager/blob/1.6.2/src/nm-manager.c#L1853-L1860 device (eth0): state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41] https://github.com/NetworkManager/NetworkManager/blob/1.6.2/src/nm-manager.c#L1860 https://github.com/NetworkManager/NetworkManager/blob/1.6.2/src/nm-manager.c#L1793-L1797 However, in that case I would also expect to see these messages: https://github.com/NetworkManager/NetworkManager/blob/1.6.2/src/nm-manager.c#L1758-L1760 https://github.com/NetworkManager/NetworkManager/blob/1.6.2/src/nm-manager.c#L1789-L1791 I've looked at other code paths that could lead to these connection-assumed state changes, but each path I could find would also log additional messages that I'm not seeing here. It doesn't seem that debug messages for the device domain, or nm-manager.c are broken, since I *do* see this message: manager: setup NMManager singleton (0x559e10330041) https://github.com/NetworkManager/NetworkManager/blob/1.6.2/src/nm-manager.c#L5688 All this looks at 1.6.2, but I've had a similar (but not as thorough) look at 1.10.4 which looks pretty much the same. Another observation I made is that: - With 1.6.2, if I set two (out of two) VLAN connections I had to autostart=false, the problem would disappear. - With 1.10.4, if I set both VLAN connections to autostart=false, the problem would remain. Also if I completely removed them. - With 1.6.2, if I removed the VLAN connections, but added `ExecStartPre=/bin/sh -c "sleep 5"` to the systemd service file, the problem would appear again. Given that, the link-up message from the kernel in my log is only shortly before NM starts (within the same second), I suspect that there is a race condition with NM looking at the interface and the kernel configuring it, and the VLAN connections I have subtly influence the timing. I've also disabled avahi, which does not seem to influence the problem at all (with avahi enabled, it generates log output about registering addresses, but I believe it does this *in response to* the addresses being added by the kernel, not the other way around. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work
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 Description: OpenPGP digital signature ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection "eth0" that does not work
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 Description: OpenPGP digital signature ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection eth0 that does not work
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. ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection eth0 that does not work
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? mbiebl dcbw: this bug report is a mess: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755202 mbiebl do you have any idea what this could be about? dcbw mbiebl: what creates eth0:avahi? dcbw mbiebl: and why does it not just add the address as a secondary... dcbw mbiebl: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755202#136 looks like an accurate description of the problem dcbw mbiebl: something is assigning an address to the interface before NM starts up (possibly the kernel with IPv6LL) and NM respects that configuration on boot dcbw mbiebl: it will name that generated+assumed connection the same as the interface name, so I guess everyone on the bug isn't using systemd/udev network renaming becuase they all talk about 'eth0' mbiebl dcbw: the new udev persistent network interface naming is opt-in in Debian mbiebl eth0:avahi is a link-local fallback created by avahi-autopid mbiebl if e.g. dhclient times out mbiebl dcbw: but I have no idea really what's going on there dcbw mbiebl: the question is, why is it using address labels and not just adding it to the interface, but that's not your problem dcbw mbiebl: I think that #136 is the basic issue dcbw mbiebl: the eth0 things are in-memory connections generated from the existing interface state when NM starts, so that it doesn't disrupt the existing interface configuration dcbw mbiebl: and it won't work, because it's link-local so you don't get anywhere mbiebl apparently this is not debian specific mbiebl but I wasn't able yet, to distill the exact reproducer dcbw no, it's not debian specific dcbw mbiebl: it will only occur if (a) something brings the interface up before NetworkManager starts, and (b) the kernel has had enough time to run DAD on the IPv6LL address that it adds because the interface is IFF_UP already dcbw mbiebl: a reproducer would be something like dcbw 1) stop NM dcbw 2) ip addr flush all dcbw 3) ifconfig eth0 down dcbw 4) ifconfig eth0 up dcbw 5) wait until the kernel has assigned an IPv6LL address dcbw 6) start NetworkManager dcbw and you'll see NM assume the connection on eth0 that is ipv4.method=disabled, ipv6.method=link-local dcbw that's essentially intended but sub-optimal behavior, as a side-effect of NM attempting not to touch already configured interfacs mbiebl so if the user has a valid connection config for eth0 this is not applied? dcbw in the case of IPv6LL-only, it's less than helpful dcbw mbiebl: existing interface configuration trumps *all*, because if the configuration already exists on the interface, something put it there, and NM tries not to interfere dcbw mbiebl: int he case of IPv6LL, well, that is usually not intended by the user dcbw so we probably do want to adjust NM behavior in the IPv6LL-only case mbiebl same for an avahi created IPv4LL dcbw well, that's intended because somebody installed the dhclient script or whatever dcbw plus, avahi-autoipd is going do to die pretty soon, according to upstream dcbw I have no idea why that avahi behavior is useful mbiebl will that be folded into networkd? dcbw there's already replacement code in networkd, and NM does IPv4LL itself too, and so does connman dcbw so basically, since it's a network management daemon task and not really a standalone thing, I guess they decided it should be done in management daemons mbiebl yeah, it was probably just useful for basic tools like ifupdown mbiebl (it's hooked into it via if-up.d hooks and a dhclient hook) dcbw mbiebl: for the IPv4LL side of things, if the user wants IPv4LL, then they can (a) create a config in NM for it that they can use when they want, and/or (b) we can explore ways to achieve whatever behavior they want within NM, like potential fallback to IPv4LL when DHCP fails or whatever dcbw mbiebl: so two results from that thread; #1 NM's IPv6LL-only assume behavior should be changed, and #2 avahi-autoipd probably shouldn't be called from the hooks to add an address dcbw at least when NM is being used... mbiebl oh, I still have an avahi-autoipd suggests in the NM package mbiebl probably from old times... mbiebl suggests don't pull in the package automatically thankfully dcbw mbiebl: well, complicated dcbw mbiebl: it's required currently for NM's IPv4LL behavior, but NM spawns it manually dcbw mbiebl: we're going to remove that dependency soon thouh mbiebl or, well, it actually still has code for IPv4LL using avahi dcbw mbiebl: so you would still want avahi-autoipd, but you don't want the hooks running when NM is running dcbw at least the ones that add addresses mbiebl the if-up.d hooks (which are called by the NM dispatcher) mbiebl only add routes mbiebl it's the dhclient hook, which adds the avahi interface mbiebl since we don't call the dhclient hook scripts mbiebl this probably only happens if the user manages
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection eth0 that does not work
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 . . . . . . . z...@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 Description: Digital signature ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection eth0 that does not work
control: tags -1 moreinfo unreproducible On Fri, 18 Jul 2014 21:35:52 +0200 Felix C. Stegerman f...@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 Description: OpenPGP digital signature ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection eth0 that does not work
Hi! I just came across this bug after reading the latest status report: https://lists.debian.org/debian-devel-announce/2015/03/msg2.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. ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection eth0 that does not work
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 Holmgrenholmg...@debian.org Debian Developer ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection eth0 that does not work
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. ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection eth0 that does not work
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 . . . . . . . z...@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 Description: Digital signature ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
[Pkg-utopia-maintainers] Bug#755202: network-manager: keeps creating and using new connection eth0 that does not work
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 adduser3.113+nmu3 ii dbus 1.8.6-1 ii init-system-helpers1.19 ii isc-dhcp-client4.3.0+dfsg-1 ii libc6 2.19-7 ii libdbus-1-31.8.6-1 ii libdbus-glib-1-2 0.102-1 ii libgcrypt111.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-glib01.2.0-1 ii libndp01.3-1 ii libnewt0.520.52.17-1 ii libnl-3-2003.2.24-2 ii libnl-genl-3-200 3.2.24-2 ii libnl-route-3-200 3.2.24-2 ii libnm-glib40.9.10.0-1 ii libnm-util20.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-10.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 ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
