Re: NetworkManager master builds for Fedora in COPR
On Mon, Oct 20, 2014 at 10:13 PM, Dan Williams d...@redhat.com wrote: On Thu, 2014-10-16 at 13:21 +0200, Lubomir Rintel wrote: Hi, I'm doing regular builds of NetworkManager packages for Fedora for my own testing/development purposes. I made COPR projects recently so that the packages get published and it's easy for me to update my machines; and I thought that someone else might find it useful too: There's two projects, lkundrak/NetworkManager [1], which builds master code and lkundrak/NetworkManager-integration [2] which merges my branches that are pending review. [1] https://copr.fedoraproject.org/coprs/lkundrak/NetworkManager/ [2] https://copr.fedoraproject.org/coprs/lkundrak/NetworkManager-integration/ The builds are triggered manually, around once a day. As usual with COPR repositories, use it at your own risk (i.e. not in production and only if you know how to restore to good package versions if anything breaks). Thanks for doing this! I've wanted to do it for a while but never got around to it... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list Hi , I though do the same for NetworkManager, but https://copr.fedoraproject.org/coprs/lkundrak/NetworkManager/include ModemManager, libmbim and libqmi . I'm using ModemManager-1.2.0 , libmbim-1.8.0 and libqmi-1.8.0 in Fedora 20 and I'm very happy ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Bug in Network-Manager with virtual interfaces / new plugin
Hi there,
Michael asked to forward this to the list, so here it is...
The patch 0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch
(debian Jessie) messes up with my virtual interfaces (vmware
vmnet1/vmnet8).
Even if I set them manually unmanaged (from /etc/network/interfaces or
using keyfile plugin), they finally appear connected and make me lose my
internet connection if my ethernet link is down and I'm using WIFI.
I'm not sure exactly what's going on with the internals of
Network-Manager in this case but setting the default unmanaged flag on
the interfaces seems to have some negative side effects.
However, I think the idea of not managing the virtual interfaces is OK,
in particular for not expert users.
You'll find enclosed a small plugin that detects those virtual
interfaces and adds them to the unmanaged list. This is based on the
keyfile plugin.
Please feel free to use it (or not).
(0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch has to be
reverted for this plugin to work)
Thanks for your work anyway.
Nicolas
From 0fbcb8c9aecd652926c58553f401de2e5be1e785 Mon Sep 17 00:00:00 2001
From: boul bou...@gmail.com
Date: Sun, 12 Oct 2014 23:56:03 +0200
Subject: [PATCH 1/1] Added ifvirt plugin
---
configure.ac| 5 +
src/settings/plugins/Makefile.am| 4 +
src/settings/plugins/ifvirt/Makefile.am | 41 +
src/settings/plugins/ifvirt/plugin.c| 271
src/settings/plugins/ifvirt/plugin.h| 50 ++
5 files changed, 371 insertions(+)
create mode 100644 src/settings/plugins/ifvirt/Makefile.am
create mode 100644 src/settings/plugins/ifvirt/plugin.c
create mode 100644 src/settings/plugins/ifvirt/plugin.h
diff --git a/configure.ac b/configure.ac
index 94b0758..0e1caf7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -95,6 +95,7 @@ AC_ARG_ENABLE(ifcfg-rh, AS_HELP_STRING([--enable-ifcfg-rh], [enable ifcfg-rh con
AC_ARG_ENABLE(ifcfg-suse, AS_HELP_STRING([--enable-ifcfg-suse], [enable ifcfg-suse configuration plugin (SUSE)]))
AC_ARG_ENABLE(ifupdown, AS_HELP_STRING([--enable-ifupdown], [enable ifupdown configuration plugin (Debian/Ubuntu)]))
AC_ARG_ENABLE(ifnet, AS_HELP_STRING([--enable-ifnet], [enable ifnet configuration plugin (Gentoo)]))
+AC_ARG_ENABLE(ifnet, AS_HELP_STRING([--enable-ifvirt], [enable ifvirt configuration plugin]))
# Default alternative plugins by distribution
AS_IF([test -z $enable_ifcfg_rh], AC_CHECK_FILE(/etc/redhat-release, enable_ifcfg_rh=yes))
AS_IF([test -z $enable_ifcfg_rh], AC_CHECK_FILE(/etc/fedora-release, enable_ifcfg_rh=yes))
@@ -107,11 +108,13 @@ AS_IF([test -z $enable_ifcfg_rh], enable_ifcfg_rh=no)
AS_IF([test -z $enable_ifcfg_suse], enable_ifcfg_suse=no)
AS_IF([test -z $enable_ifupdown], enable_ifupdown=no)
AS_IF([test -z $enable_ifnet], enable_ifnet=no)
+AS_IF([test -z $enable_ifvirt], enable_ifvirt=no)
# Create automake conditionals
AM_CONDITIONAL(CONFIG_PLUGIN_IFCFG_RH, test $enable_ifcfg_rh = yes)
AM_CONDITIONAL(CONFIG_PLUGIN_IFCFG_SUSE, test $enable_ifcfg_suse = yes)
AM_CONDITIONAL(CONFIG_PLUGIN_IFUPDOWN, test $enable_ifupdown = yes)
AM_CONDITIONAL(CONFIG_PLUGIN_IFNET, test $enable_ifnet = yes)
+AM_CONDITIONAL(CONFIG_PLUGIN_IFVIRT, test $enable_ifvirt = yes)
if test $enable_ifcfg_rh = yes; then
DISTRO_NETWORK_SERVICE=network.service
@@ -794,6 +797,7 @@ src/settings/plugins/ifcfg-suse/Makefile
src/settings/plugins/keyfile/Makefile
src/settings/plugins/keyfile/tests/Makefile
src/settings/plugins/keyfile/tests/keyfiles/Makefile
+src/settings/plugins/ifvirt/Makefile
src/settings/plugins/example/Makefile
src/settings/tests/Makefile
src/platform/Makefile
@@ -906,6 +910,7 @@ echo ifcfg-rh: ${enable_ifcfg_rh}
echo ifcfg-suse: ${enable_ifcfg_suse}
echo ifupdown: ${enable_ifupdown}
echo ifnet: ${enable_ifnet}
+echo ifvirt: ${enable_ifvirt}
echo
echo Handlers for /etc/resolv.conf:
diff --git a/src/settings/plugins/Makefile.am b/src/settings/plugins/Makefile.am
index 41694e7..2ae7444 100644
--- a/src/settings/plugins/Makefile.am
+++ b/src/settings/plugins/Makefile.am
@@ -17,3 +17,7 @@ endif
if CONFIG_PLUGIN_IFNET
SUBDIRS+=ifnet
endif
+
+if CONFIG_PLUGIN_IFVIRT
+SUBDIRS+=ifvirt
+endif
diff --git a/src/settings/plugins/ifvirt/Makefile.am b/src/settings/plugins/ifvirt/Makefile.am
new file mode 100644
index 000..ab15e55
--- /dev/null
+++ b/src/settings/plugins/ifvirt/Makefile.am
@@ -0,0 +1,41 @@
+SUBDIRS = .
+
+@GNOME_CODE_COVERAGE_RULES@
+
+AM_CPPFLAGS = \
+ -I$(top_srcdir)/src \
+ -I$(top_srcdir)/src/config \
+ -I$(top_srcdir)/src/logging \
+ -I$(top_srcdir)/src/settings \
+ -I$(top_srcdir)/include \
+ -I$(top_builddir)/include \
+ -I$(top_srcdir)/libnm-util \
+ -I$(top_builddir)/libnm-util \
+ -DG_LOG_DOMAIN=\NetworkManager-ifvirt\ \
+ -DNM_VERSION_MAX_ALLOWED=NM_VERSION_NEXT_STABLE \
+ $(GLIB_CFLAGS) \
+ $(DBUS_CFLAGS) \
+ $(POLKIT_CFLAGS) \
+ $(GUDEV_CFLAGS) \
+ -DNMCONFDIR=\$(nmconfdir)\
+
+pkglib_LTLIBRARIES =
Re: Bug in Network-Manager with virtual interfaces / new plugin
On Fri, 2014-10-24 at 19:05 +0200, Nicolas Boulicault wrote: Hi there, Michael asked to forward this to the list, so here it is... The patch 0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch (debian Jessie) messes up with my virtual interfaces (vmware vmnet1/vmnet8). Could you run NM with --log-level=debug and reproduce the issue so that we can get an idea of what NM is doing? The goal is to still recognize these interfaces, but *not* touch them, simply represent their current external state through the NM APIs and command-line tools. So if NM is somehow screwing up those devices by changing their configuration, that would be a bug in NM, and we need to find it and fix it. Thanks! Dan Even if I set them manually unmanaged (from /etc/network/interfaces or using keyfile plugin), they finally appear connected and make me lose my internet connection if my ethernet link is down and I'm using WIFI. I'm not sure exactly what's going on with the internals of Network-Manager in this case but setting the default unmanaged flag on the interfaces seems to have some negative side effects. However, I think the idea of not managing the virtual interfaces is OK, in particular for not expert users. You'll find enclosed a small plugin that detects those virtual interfaces and adds them to the unmanaged list. This is based on the keyfile plugin. Please feel free to use it (or not). (0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch has to be reverted for this plugin to work) Thanks for your work anyway. Nicolas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hitspot automatic connect
On Fri, 2014-10-24 at 11:18 +0200, Andreas Müller wrote: On Fri, Oct 24, 2014 at 10:43 AM, Thomas Haller thal...@redhat.com wrote: On Fri, 2014-10-24 at 10:19 +0200, Andreas Müller wrote: Hi, Now my question: What does it need to start hotspot automatically after boot? If there is no setting available I could create a script/app using Networkmanager's dbus I would be very happy if somebody could help me because for me this is the last part of the puzzle and solving would make me run in happy mode :) you certainly could use the DBUS interface. But maybe it's easier to use nmcli connection up? Thomas Thomas, you are my hero of the day - thanks a lot. If there are no other WiFi connections defined on the system (nmcli con | grep wireless) and the AP connection is the only one, and set autoconnect=true, then NM will always bring that connection up when starting. If you do have other wifi connections that you periodically use, you could set all of them autoconnect=no, and NM will ignore them and always start the AP connection. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Kernel module(r8712u) reload - suspend/resume - systemd
It is tested and works, # systemctl suspend [ 144.218876] PM: Entering mem sleep [ 144.219249] r8712u 2-3:1.0 wlp0s4f1u3: Suspending... [ 144.219255] r8712u 2-3:1.0 wlp0s4f1u3: Unable to suspend RESUME [ 146.844240] r8712u 2-3:1.0 wlp0s4f1u3: Resuming... [ 146.844241] r8712u 2-3:1.0 wlp0s4f1u3: Unable to resume [ 147.015962] PM: Finishing wakeup. [ 154.029573] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 [ 177.489082] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 [ 200.499708] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 [ 233.514654] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 [ 276.498402] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 [ 329.498037] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 [ 392.507363] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 [ 455.559545] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 [ 518.540179] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 [ 581.533404] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1 ~~ # nmcli device DEVICE TYPE STATE CONNECTION wlp0s4f1u3 wifi disconnected -- ~ /etc/systemd/system/r8712u-reload.service [Unit] Description=Reload rtl871x wireless lan driver after system resume After=hibernate.target suspend.target hybrid-sleep.target [Service] Type=oneshot ExecStart=/usr/sbin/modprobe -r r8712u ExecStart=/usr/sbin/modprobe r8712u [Install] WantedBy=hibernate.target suspend.target hybrid-sleep.target # systemctl enable r8712u-reload.service ~~~ # systemctl suspend [ 616.251430] PM: Entering mem sleep [ 616.251962] r8712u 2-3:1.0 wlp0s4f1u3: Suspending... [ 616.251965] r8712u 2-3:1.0 wlp0s4f1u3: Unable to suspend RESUME [ 619.008122] r8712u 2-3:1.0 wlp0s4f1u3: Resuming... [ 619.008124] r8712u 2-3:1.0 wlp0s4f1u3: Unable to resume [ 619.195001] PM: Finishing wakeup. [ 620.073126] usb 2-3: reset high-speed USB device number 3 using ehci-pci [ 620.209187] r8712u: module is from the staging directory, the quality is unknown, you have been warned. [ 620.209785] r8712u: Staging version [ 620.209802] r8712u: register rtl8712_netdev_ops to netdev_ops [ 620.209807] usb 2-3: r8712u: USB_SPEED_HIGH with 4 endpoints [ 620.210253] usb 2-3: r8712u: Boot from EFUSE: Autoload OK [ 620.583476] usb 2-3: r8712u: CustomerID = 0x [ 620.583489] usb 2-3: r8712u: MAC Address from efuse = 00:01:02:03:04:05 [ 620.583498] usb 2-3: r8712u: Loading firmware from rtlwifi/rtl8712u.bin [ 620.584238] usbcore: registered new interface driver r8712u [ 620.589721] r8712u 2-3:1.0 wlp0s4f1u3: renamed from wlan0 [ 627.183840] r8712u 2-3:1.0 wlp0s4f1u3: 1 RCR=0x153f00e [ 627.184345] r8712u 2-3:1.0 wlp0s4f1u3: 2 RCR=0x553f00e [ 627.288231] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready [ 627.592219] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready [ 627.896222] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready [ 628.201217] IPv6: ADDRCONF(NETDEV_UP): wlp0s4f1u3: link is not ready [ 648.740663] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s4f1u3: link becomes ready ~~ # nmcli device DEVICE TYPE STATE CONNECTION wlp0s4f1u3 wifi connected AP but is there a better way to do it? poma ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hitspot automatic connect
On 27.10.2014 15:39, Dan Williams wrote: On Fri, 2014-10-24 at 11:18 +0200, Andreas Müller wrote: On Fri, Oct 24, 2014 at 10:43 AM, Thomas Haller thal...@redhat.com wrote: On Fri, 2014-10-24 at 10:19 +0200, Andreas Müller wrote: Hi, Now my question: What does it need to start hotspot automatically after boot? If there is no setting available I could create a script/app using Networkmanager's dbus I would be very happy if somebody could help me because for me this is the last part of the puzzle and solving would make me run in happy mode :) you certainly could use the DBUS interface. But maybe it's easier to use nmcli connection up? Thomas Thomas, you are my hero of the day - thanks a lot. If there are no other WiFi connections defined on the system (nmcli con | grep wireless) and the AP connection is the only one, and set autoconnect=true, then NM will always bring that connection up when starting. If you do have other wifi connections that you periodically use, you could set all of them autoconnect=no, and NM will ignore them and always start the AP connection. Dan What actually means *Default* *Value* - *TRUE* if this value must be explicitly set? Whether the manual is precise enough. man 5 nm-settings(Table 8. connection setting) poma ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Kernel module(r8712u) reload - suspend/resume - systemd
On 28.10.2014 00:15, Lennart Poettering wrote: On Mon, 27.10.14 23:43, poma (pomidorabelis...@gmail.com) wrote: but is there a better way to do it? This appears to be a kernel driver bug. Please report this issue against the kernel driver in question, systemd is not the right place to work around that. Lennart It's not a bug, it's a feature, just as true for the systemd. :) Given the condition of the entire Linux Wireless LAN stack this can go actually. poma ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Link MTU option ignored in IPv6 router advertisements
On 04/10/2014, at 2:31 AM, Dan Williams wrote:
On Fri, 2014-10-03 at 11:36 -0400, Chuck Anderson wrote:
I'm not sure if this is a kernel thing or a NetworkManager thing. Did
something change in how IPv6 router advertisements are handled by
NetworkManager in Fedora 20?
I think it's a NetworkManager thing. We'll fix it.
Hi Dan,
I've had a lot of trouble in IPv4 with DHCP in hotel systems setting the MTU to
less than the 576 minimum (and sometimes less than the size of the IPv4
header). I believe that this was a misguided effort to implement fair queuing.
It might be worthwhile anticipating such issues for IPv6, roughly:
/* IPv6 minimum link MTU specified on page 24 of RFC 2460. */
#define IPV6_MINIMUM_MTU 1280
unsigned int enforce_link_mtu_bounds(unsigned int offered_link_mtu,
char *interface_name)
{
if (offered_link_mtu IPV6_MINIMUM_MTU) {
syslog(Offered link MTU for %s is %u, increased to IPV6_MINIMUM_MTU \n,
(interface_name) ? interface_name : an interface,
offered_link_mtu);
return IPV6_MINIMUM_MTU;
}
return offered_link_mtu;
}
-glen
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
