Re: networkmanager-applet: menu ist scrolled with gtk+ 3.14
Christian Hesse on Thu, 16 Oct 2014 22:23:16 +0200: > Hello everybody, > > with gtk+ up to version 3.12.x everything was fine. With the update to > version 3.14.x the context menu (what pops up when you click on the > systray icon) is scrolled. Additionally the menu closes immediately > on click, you have to keep the mouse button pressed to avoid this. > > Not sure if this is a regression in gtk+ or networkmanager-applet > needs a fix... Does anybody else see this? It's really annoying. The menu is scrolled only if the panel containing the systray icon is at the top of the screen... Hmm. -- Schoene Gruesse Chris O< ascii ribbon campaign stop html mail - www.asciiribbon.org ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
networkmanager-applet: menu ist scrolled with gtk+ 3.14
Hello everybody,
with gtk+ up to version 3.12.x everything was fine. With the update to
version 3.14.x the context menu (what pops up when you click on the systray
icon) is scrolled. Additionally the menu closes immediately on click, you
have to keep the mouse button pressed to avoid this.
Not sure if this is a regression in gtk+ or networkmanager-applet needs a
fix... Does anybody else see this? It's really annoying.
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);}
signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Mobile broadband on an embedded 3G modem
Hi all, We're trying to get a 3G modem connection going on an embedded device. The modem is a MultiTech SocketModem MTSMC-H5-IP and it appears on /dev/ttyAPP3 (i.e. hardware UART port on the SoC). If I run `screen /dev/ttyAPP3 115200`, I can interact with the modem, it all works. The challenge, is getting NetworkManager 0.9.10.0 to talk to this modem. When I run `nmtui`, no option for adding the mobile broadband connection appears, I suspect because NetworkManager doesn't know the 3G dongle exists. How do I tell it where to look? Regards, -- Stuart Longland Systems Engineer _ ___ \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas StreetF: +61 7 3535 9699 SYSTEMSMilton QLD 4064 http://www.vrt.com.au ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ad-Hoc network creation took too long, failing activation
Dan? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unhandled vpnc request
Christian Hesse on Tue, 2014/10/14 21:24: > Dan Williams on Tue, 2014/10/14 14:11: > > On Tue, 2014-10-14 at 20:54 +0200, Christian Hesse wrote: > > > Hello everybody, > > > > > > with latest networkmanager-vpn (git master, commit 3161854) connection > > > break ever now and then. The log contains these lines: > > > > > > ** (nm-vpnc-service:23836): WARNING **: Unhandled vpnc request 'vpnc: ' > > > vpnc: recvfrom: Message too long > > > VPN plugin failed: login-failed (0) > > > VPN plugin state changed: stopped (6) > > > VPN plugin state change reason: login-failed (10) > > > > It's a bug, and I've pushed a fix to git master. Can you try now? > > Sure. Connection is up, I will keep an eye on it and report back. Looks like this is perfectly stable again. Thanks again! -- Schoene Gruesse Chris O< ascii ribbon campaign stop html mail - www.asciiribbon.org signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wrong NTP servers list is used
Hi Mike, On Wed, 2014-10-15 at 23:36 +, Mike wrote: > I needed to hack /etc/default/ntpdate on a Debian system to contain: > > NTPDATE_USE_NTP_CONF=no > > so that it would use the DHCP-supplied ntp-servers when I "ifup eth0". > > > When I try to use NetworkManager 0.9.4.0 to bring up the interface instead, > it uses a different NTP servers list. I know this from the /var/log/syslog > output, where I find a lot of > > ntpdate[...]: sendto(...): Operation not permitted > > and corresponding netfilter log lines showing the NTP communication blocked > (as desired), with a final > > ntpdate[...]: no server suitable for synchronization found > > The servers listed number in the dozens and appear similar to those chosen > by the "ifup" path when NTPDATE_USE_NTP_CONF=yes, i.e., > > NTPSERVERS="0.debian.pool.ntp.org 1.debian.pool.ntp.org > 2.debian.pool.ntp.org 3.debian.pool.ntp.org" > > seems to be getting used. > > > This is odd, since I thought /etc/default/ntpdate is only used from the > /usr/sbin/ntpdate-debian script, whose logic would choose either the > DHCP-acquired ntp-servers (via /var/lib/ntpdate/default.dhcp), or nothing. > > So, where is NetworkManager getting these NTP servers from? NetworkManager does not do anything with NTP. It's probably the DHCP client shipped with your distribution that invokes ntpdate upon getting the DHCP reply. Look for "script" clause in you dhclient.conf or into dhclient.d, if present. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager master builds for Fedora in COPR
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). Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/2] device: Don't consider device with only LL address configured
LXC domains are given a veth interface that's up and has a LL address upon their creation. --- src/devices/nm-device.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c index d2edef9..4419d90 100644 --- a/src/devices/nm-device.c +++ b/src/devices/nm-device.c @@ -332,6 +332,8 @@ static void _set_state_full (NMDevice *self, static void nm_device_update_hw_address (NMDevice *self); +static gboolean have_ip6_address (const NMIP6Config *ip6_config, gboolean linklocal); + /***/ static GQuark @@ -1676,7 +1678,7 @@ device_has_config (NMDevice *self) /* Check for IP configuration. */ if (priv->ip4_config && nm_ip4_config_get_num_addresses (priv->ip4_config)) return TRUE; - if (priv->ip6_config && nm_ip6_config_get_num_addresses (priv->ip6_config)) + if (have_ip6_address (priv->ip6_config, FALSE)) return TRUE; /* The existence of a software device is good enough. */ -- 1.9.3 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 2/2] device: don't assume connection for veth interfaces
They're supposed to behave as Ethernet. Otherwise the LXC domains won't be able to use their configured connections with the device. --- src/devices/nm-device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c index 4419d90..af9846e 100644 --- a/src/devices/nm-device.c +++ b/src/devices/nm-device.c @@ -1682,7 +1682,8 @@ device_has_config (NMDevice *self) return TRUE; /* The existence of a software device is good enough. */ - if (nm_device_is_software (self)) + if (nm_device_is_software (self) + && nm_platform_link_get_type (priv->ifindex) != NM_LINK_TYPE_VETH) return TRUE; /* Slaves are also configured by definition */ -- 1.9.3 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
veth won't be configured in libvirt managed LXC container
Hi, currently it is impossible to get useful network configuration for LXC containers on boot. (At least if they're managed via libvirt; I have no idea if anything is different with native LXC tooling). They're supposed to obtain their configuration via DHCP, but instead connection is assumed. Firstly because there's an IPv6 local link address that (I think) gets assigned when libvirt ups the interface and secondly because it's a software link. Why do we assume connection on all software links? Virtual ethernet devices are supposed to behave much like ordinary ethernet devices; they have carrier detection, etc. I'm following up with the patches that resolve the problem for me, but I'm not quite sure about the special case for veth. Thoughts? Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
