Notifications not showing, when applet is disabled
Hi everyone, I noticed, that no notification is displayed, if the applet is disabled by the gsettings. How to reproduce: 1. Start nm-applet, if it isn't already 2. Make sure, that you get a notification, when interacting with NetworkManager (e.g. connecting to a network) 3. Execute gsettings set org.gnome.nm-applet show-applet 'false' 4. Interact with NetworkManager (e.g. through nmtui) to repeat the steps in 1. 5. Notice, that there is no notification shown What I expected: As the option only says show-applet, we should still see the notifications. Solution? I had a look at the source and with this diff I could produce the expected behavior: diff --git a/src/applet.c b/src/applet.c index 81e2ac5..7d411c7 100644 --- a/src/applet.c +++ b/src/applet.c @@ -884,9 +884,6 @@ applet_do_notify (NMApplet *applet, g_return_if_fail (summary != NULL); g_return_if_fail (message != NULL); - if (!gtk_status_icon_is_embedded (applet-status_icon)) - return; - /* if we're not acting as a secret agent, don't notify either */ if (!applet-agent) return; It is running on my system right now, but I don't know if this breaks anything else. The originating commit b74deac92d8192591ddbb62f2e2b1b7101a5e95d doesn't say why the notification shouldn't be shown, if the applet isn't visible. But in my opinion it doesn't make sense to not show the notification, only because the applet isn't shown. Additionally we now have the gsettings to control what should be shown, which wasn't the case when this commit was made, as far as I can tell. Please excuse any formal mistakes I made, as it is my first time using a mailing list. Hendrik smime.p7s Description: S/MIME Cryptographic Signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager master builds for Fedora in COPR
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
Re: VPN + dnsmasq = split dns?
On Fri, 2014-10-10 at 21:17 +0200, Olav Morken wrote: Hi, I am trying to set up Network Manager to connect to an OpenVPN server, and have trouble understanding how it applies the DNS settings it receives from the server. Sorry for the late reply... Which version of NM do you have, and what distro? Basically, as far as I can tell, it automatically assumes that I want to use split dns, and limits the DNS servers it receives from the OpenVPN servers to the domains it assumes belongs to this configuration. However, it also ignores the existing DNS servers it has configured. By default, NM will not do split DNS, which means when the VPN is connected, the VPN nameservers replace the existing nameservers. This is required to ensure that if for some reason the VPN nameservers cannot be contacted, that your queries don't fall back to the non-VPN nameservers and return bogus (and potentially malicious) results. But, if you add dns=dnsmasq to the /etc/NetworkManager/NetworkManager.conf file and install 'dnsmasq', then NM will run in split DNS mode. Here, NM will spawn a private copy of dnsmasq and send it configuration to direct any queries ending in the domain passed back from the openvpn server (or entered into the NM configuration for that VPN connection) to the VPN nameservers, and everything else to the non-VPN nameservers. That leaves us with a dnsmasq configured with two nameservers it will query for two specific subdomains, and no nameservers it will use for other domains. The result is that dnsmasq is only willing to respond to DNS queries for those subdomains, and respond with REFUSED for every other domain. I assume that this is not the way it is supposed to work, since that would mean that everyone connecting to a VPN would be unable to access most of the Internet. I therefore assume that there is something wrong with my configuration. That sounds like a bug; do you know if you have any custom dnsmasq configuration on that system? Also check two thigns: 1) /etc/resolv.conf should have 127.0.0.1 as the only namesever 2) Look in /var/run/NetworkManager (or /run/NetworkManager) for the 'dnsmasq.conf' file which is what NM sends to dnsmasq (the only caveat here is that if you run Ubuntu, this procedure may not apply as the info is sent to dnsmasq over D-Bus) Let us know what the results are! Dan I am however unable to tell what makes it choose this behavior. I tried to look at the code, and found the location where it adds the domains[1], but I was unable to find a way to override this behavior. Does anyone have any suggestions for what may trigger this behavior, and what I can do to avoid it? (Configuration details and logs from network manager included below.) Best regards, Olav Morken [1] http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns-manager/nm-dns-dnsmasq.c?id=60cce4004284242f0891160e21979a3027da6e0e#n234 Configuration: Both the client and server have IPv6 enabled. The VPN configuration on the client side doesn't contain anything too exiting. It uses a TCP connection to port 443, a TUN device, and username+password authentication. Both the IPv4 and the IPv6 settings are set to Automatic(VPN) The OpenVPN server is configured with a TUN device and topology subnet. It pushes the following (slightly anonymized) options to the client: push dhcp-option DNS 198.51.100.57 push dhcp-option DNS 198.51.100.168 push dhcp-option DOMAIN example.org push redirect-gateway def1 bypass-dhcp push route-ipv6 2000::/3 Software versions: XUbuntu 14.04 network-manager 0.9.8.8-0ubuntu7 network-manager-openvpn 0.9.8.2-1ubuntu4 openvpn 2.3.2-7ubuntu3 Log from connection: NetworkManager[924]: info IPv4 configuration: NetworkManager[924]: info Internal Gateway: 192.0.2.1 NetworkManager[924]: info Internal Address: 192.0.2.2 NetworkManager[924]: info Internal Prefix: 25 NetworkManager[924]: info Internal Point-to-Point Address: 0.0.0.0 NetworkManager[924]: info Maximum Segment Size (MSS): 0 NetworkManager[924]: info Forbid Default Route: no NetworkManager[924]: info Internal DNS: 198.51.100.57 NetworkManager[924]: info Internal DNS: 198.51.100.168 NetworkManager[924]: info DNS Domain: 'example.org' NetworkManager[924]: info IPv6 configuration: NetworkManager[924]: info Internal Address: 2001:db81:4561::1000 NetworkManager[924]: info Internal Prefix: 64 NetworkManager[924]: info Internal Point-to-Point Address: 2001:db81:4561::1 NetworkManager[924]: info Maximum Segment Size (MSS): 0 NetworkManager[924]: info Static Route: 2000::/3 Next Hop: 2000:: NetworkManager[924]: info Forbid Default Route: no NetworkManager[924]: info DNS Domain: 'example.org' NetworkManager[924]: info VPN connection 'example-openvpn-config' (IP Config Get) complete. NetworkManager[924]: info Policy set
Re: Notifications not showing, when applet is disabled
On Sat, 2014-10-18 at 17:43 +0200, Hendrik Rosendahl wrote: Hi everyone, I noticed, that no notification is displayed, if the applet is disabled by the gsettings. How to reproduce: 1. Start nm-applet, if it isn't already 2. Make sure, that you get a notification, when interacting with NetworkManager (e.g. connecting to a network) 3. Execute gsettings set org.gnome.nm-applet show-applet 'false' 4. Interact with NetworkManager (e.g. through nmtui) to repeat the steps in 1. 5. Notice, that there is no notification shown What I expected: As the option only says show-applet, we should still see the notifications. Solution? I had a look at the source and with this diff I could produce the expected behavior: diff --git a/src/applet.c b/src/applet.c index 81e2ac5..7d411c7 100644 --- a/src/applet.c +++ b/src/applet.c @@ -884,9 +884,6 @@ applet_do_notify (NMApplet *applet, g_return_if_fail (summary != NULL); g_return_if_fail (message != NULL); - if (!gtk_status_icon_is_embedded (applet-status_icon)) - return; - /* if we're not acting as a secret agent, don't notify either */ if (!applet-agent) return; It is running on my system right now, but I don't know if this breaks anything else. The originating commit b74deac92d8192591ddbb62f2e2b1b7101a5e95d doesn't say why the notification shouldn't be shown, if the applet isn't visible. But in my opinion it doesn't make sense to not show the notification, only because the applet isn't shown. Additionally we now have the gsettings to control what should be shown, which wasn't the case when this commit was made, as far as I can tell. Please excuse any formal mistakes I made, as it is my first time using a mailing list. Thanks for the report and investigation. I believe the original intent was that when nm-applet wasn't being shown it shouldn't provide any user interaction other than it's secret agent, because if it's not being shown, whatever other UI *is* shown should be providing those notifications. I'm not sure we ever thought about running the applet hidden, but only providing notifications. If that's useful to you, I'd be happy to take a patch that adds a new GSetting called notify-when-hidden that turns the notifications back on in this case. Would you be able to work on a patch for that? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN + dnsmasq = split dns?
On Mon, Oct 20, 2014 at 16:20:03 -0500, Dan Williams wrote: On Fri, 2014-10-10 at 21:17 +0200, Olav Morken wrote: Hi, I am trying to set up Network Manager to connect to an OpenVPN server, and have trouble understanding how it applies the DNS settings it receives from the server. Sorry for the late reply... Which version of NM do you have, and what distro? It's XUbuntu 14.04 with network-manager 0.9.8.8-0ubuntu7 (I guess I should have been clearer about it being included at the end of my original message :) ) Basically, as far as I can tell, it automatically assumes that I want to use split dns, and limits the DNS servers it receives from the OpenVPN servers to the domains it assumes belongs to this configuration. However, it also ignores the existing DNS servers it has configured. By default, NM will not do split DNS, which means when the VPN is connected, the VPN nameservers replace the existing nameservers. This is required to ensure that if for some reason the VPN nameservers cannot be contacted, that your queries don't fall back to the non-VPN nameservers and return bogus (and potentially malicious) results. But, if you add dns=dnsmasq to the /etc/NetworkManager/NetworkManager.conf file and install 'dnsmasq', then NM will run in split DNS mode. Here, NM will spawn a private copy of dnsmasq and send it configuration to direct any queries ending in the domain passed back from the openvpn server (or entered into the NM configuration for that VPN connection) to the VPN nameservers, and everything else to the non-VPN nameservers. That is quite a large change in behavior for someone running with dnsmasq. I also think it is the wrong behavior when we are pushing a default route over the VPN. With a default route over the VPN it is likely that we would want all traffic, including DNS traffic over the VPN. It is also likely that the user would end up trying to contact the local DNS servers over the VPN, which would break. That leaves us with a dnsmasq configured with two nameservers it will query for two specific subdomains, and no nameservers it will use for other domains. The result is that dnsmasq is only willing to respond to DNS queries for those subdomains, and respond with REFUSED for every other domain. I assume that this is not the way it is supposed to work, since that would mean that everyone connecting to a VPN would be unable to access most of the Internet. I therefore assume that there is something wrong with my configuration. That sounds like a bug; do you know if you have any custom dnsmasq configuration on that system? Also check two thigns: 1) /etc/resolv.conf should have 127.0.0.1 as the only namesever 2) Look in /var/run/NetworkManager (or /run/NetworkManager) for the 'dnsmasq.conf' file which is what NM sends to dnsmasq (the only caveat here is that if you run Ubuntu, this procedure may not apply as the info is sent to dnsmasq over D-Bus) I wasn't aware the Ubuntu had such significant changes to Network Manager. In that case, I think the behavior we am seeing is Ubuntu-specific. There is no customization of the dnsmasq settings on this system. (In fact the behavior has been observed on several different Ubuntu installations.) From the logs (included at the end of my original message): dnsmasq[1464]: setting upstream servers from DBus dnsmasq[1464]: using nameserver 198.51.100.168#53 for domain 0.192.in-addr.arpa dnsmasq[1464]: using nameserver 198.51.100.168#53 for domain example.org dnsmasq[1464]: using nameserver 198.51.100.57#53 for domain 0.192.in-addr.arpa dnsmasq[1464]: using nameserver 198.51.100.57#53 for domain example.org Nothing in the log about the original (non-VPN) DNS servers, so I am guessing they were removed. Let us know what the results are! For what it is worth, after futher testing we have determined that it is the IPv6 configuration that breaks the DNS config. We have seen three different behaviors, depending on the VPN config: 1. VPN with only IPv4 address and default route: The DNS servers are added as global DNS servers. 2. VPN with both IPv4 and IPV6 addresses and default routes, but only IPv4 DNS servers pushed through VPN configuration: The DNS servers are added as local DNS servers, with no global DNS servers. 3. VPN with both IPv4 and IPV6 addresses and default routes, and both IPv4 and IPv6 DNS servers pushed through VPN configuration: The IPv4 DNS servers are added as local DNS servers, and one of the IPv6 DNS servers are added as a global DNS server. It was scenario 2 that was the original problem. For now, it looks like we have a workaround in scenario 3, since in that case we are left with a IPv6 DNS server that can be used for global queries. A wild guess from me is that the Ubuntu devlopers noticed the broken VPN DNS behavior with dnsmasq (since dnsmasq is the default on Ubuntu), and fixed it for the
