ANN: NetworkManager 1.38.0 released
Ladies and Gentlemen, On behalf of the NetworkManager community, I am happy to announce a new release of NetworkManager: 1.38.0. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/5704730a6c4e6851d4ba5471ea439502f7b72949 Find the tarball at our usual location: https://download.gnome.org/sources/NetworkManager/1.38/ https://download.gnome.org/sources/NetworkManager/1.38/NetworkManager-1.38.0.tar.xz sha256: 82a4cf07ddfeb0816787b67c0f5058ae6c50d6259c0b0541a24e35156062b2ef sha512: 0f1532b4ea1aeb9d5dd922ee005eef325d39ba3526884793aaaed2eae61737f6a6e95644077f2b45ace569df79246d3d6404272cce02ca7e02b3632aee882940 To see what's new check the NEWS file: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.38.0/NEWS or the blog entry: https://networkmanager.dev/blog/networkmanager-1-38/ Thanks to everybody who contributed to this release with patches and translations: Ana Cabral, Bastien Nocera, Beniamino Galvani, Bryan Jacobs, ChristianEggers, Daisuke Matsuda, Emmanuel Grumbach, Fernando Fernandez Mancera, Francisco Blas Izquierdo Riera (klondike), Javier Jardón, Lubomir Rintel, luokai, muzena, Nathan Follens, Sergiu Bivol, Sigurd Rønningen Jenssen, Thomas Haller, Till Maas, Val Och, Vojtech Bubela, Wen Liang, Yi Zhao, Yuri Chornoivan and 谢致邦 (XIE Zhibang). Shout out to the Red Hat Quality Engineers, who have tested the release and therefore it's their fault if anything goes wrong: Vladimír Beneš, Filip Pokryvka, David Jasa and Matej Berezny. Check out NOG’s Keep Ukraine Connected web site to find out about ways to improve network connectivity of those who need it the most: https://nogalliance.org/our-task-forces/keep-ukraine-connected/ ❤ Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.36.0 released
Hello there! On behalf of the NetworkManager community, I am happy to announce a new major release of NetworkManager: 1.36.0. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/tags/1.36.0 Find the tarball at our usual location: https://download.gnome.org/sources/NetworkManager/1.36/ https://download.gnome.org/sources/NetworkManager/1.36/NetworkManager-1.36.0.tar.xz sha256: faa389c9e9ca78243cfab4a8bed6db132f82e5b5e66bb9d44af93379d1348398 sha512: 9cc2f4ca0d4425423b6db75ed6c65f7a51229f7c654ab0b9b07d22c695b292d28768ff56aff6af3d9a2c0bd2b46d25bae015e9edacf766bfb74018b4e5847da8 To see what's new check the NEWS file: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.36.0/NEWS or a short blog entry Thomas has written: https://networkmanager.dev/blog/networkmanager-1-36/ This release was possible thanks to the contributions of: Ana Cabral, Andrew Zaborowski, Beniamino Galvani, Daniele Palmas, Fernando Fernandez Mancera, James Hilliard, Justin Spencer, Lubomir Rintel, Nacho Barrientos, Sam Morris, Thomas Haller, Tomohiro Mayama, Val Och, Wen Liang, xiangnian and 流浪猫. As always we extend our thanks and gratitude to wonderful quality engineers at Red Hat whose enormous effort and test suite makes sure this release works as promised: Vladimír Beneš, Filip Pokryvka, David Jasa, Matej and Vitezslav Humpa. Peace & Love, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Collect agreement/disagreement to Relicense NetworkManager under LGPL-2.1+
On Fri, 2020-01-10 at 10:06 +0100, Francesco Giudici via networkmanager-list wrote: > > On 09/01/20 15:40, Dan Williams via networkmanager-list wrote: > > On Thu, 2020-01-09 at 09:14 -0500, Dan Winship via networkmanager-list > > wrote: > > > Thomas asked me to send email agreeing to the relicensing. I am not > > > the > > > copyright holder of any code in NetworkManager and do not believe > > > that I > > > have any say in this decision, but if it turns out that I do, then, > > > sure, I agree. > > > > I also agree (though like Dan, the copyright on my contributions is > > held by Red Hat any may be relicensed as Thomas requests). > > Same for me: I agree to relicense NetworkManager as suggested by Thomas. +1 here. All my NetworkManager contributions, copyrighted by me or Red Hat can be used and redistributed under the terms of LGPL, v2 or later. Thank you Lubo > > Thanks > > Francesco > > > dan > > > > ___ > > 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 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Collect agreement/disagreement to Relicense NetworkManager under LGPL-2.1+
On Fri, 2020-01-10 at 09:18 +0100, Iñigo Martínez via networkmanager- list wrote: > Hi, > > What about meson build files? Although usually the license is not included, > there are some exceptions that they do[0]. > > If necessary, I also agree with relicensing. It's somewhat unfortunate that the build scripts (and a couple of other files) lack clear licensing information. I believe that they constitute copyrightable work. As far as I'm aware, we don't document any sort of "fallback" for files without explicit licensing terms like e.g. the Linux kernel does. We'll eventually need to clarify licensing of those files. Since you're originally written the meson scripts and have done most work on them, I'm wondering if you could submit a patch to add that would add a SPDX tags to meson.build files? We prefer LGPL-2.1+, but I guess anything more liberal would also work. Thank you Lubo > > BR, > > [0] https://github.com/systemd/systemd/blob/master/meson.build > > El jue., 9 ene. 2020 a las 15:40, Dan Williams via networkmanager-list (< > networkmanager-list@gnome.org>) escribió: > > > On Thu, 2020-01-09 at 09:14 -0500, Dan Winship via networkmanager-list > > wrote: > > > Thomas asked me to send email agreeing to the relicensing. I am not > > > the > > > copyright holder of any code in NetworkManager and do not believe > > > that I > > > have any say in this decision, but if it turns out that I do, then, > > > sure, I agree. > > > > I also agree (though like Dan, the copyright on my contributions is > > held by Red Hat any may be relicensed as Thomas requests). > > > > dan > > > > ___ > > 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 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: automatic APN selection
Ahoj,
On Tue, 2019-02-12 at 11:49 +0100, Belisko Marek via networkmanager-
list wrote:
> Hello,
>
> I posted yesterday question to ModemManger mailing list about implementing
> automatic APN selection (based on mobile broadband database) and it was
> pointed [0] out that this feature should be added to NM. My case is that
> embedded device using GSM modem should connect to internet automatically
> (without user intervention only by plugging SIM card). Isomebody working on
> such solution already? It is right approach? Thanks for replies.
>
> 0 -
> https://lists.freedesktop.org/archives/modemmanager-devel/2019-February/006996.html
I've given this a stab in lr/gsm-default-apn branch. Please take a
look:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/98
Connecting the modem is not entirely automatic; you still need to
connect a device ("nmcli d connect ttyUSB666").
For the device to connect automatically new_default_connection() would
need to be implemented for NMDeviceModem. That would probably involve
factoring out the logic from src/devices/nm-device-ethernet.c's
new_default_connection().
Elsewhere in the thread Aleksander argued that it would be somewhat
risky, but it has been also argued that phones tend to do that and the
world hasn't imploded yet. I tend to think it is in fact a good policy
for most installations and distributors or users who would object this
could do so by dropping a snippet with no-auto-default= setting into
conf.d/.
For now the biggest shortcoming of the branch is that the code is
probably not very beautiful and could use some review or polishing. If
you'd like to pick it up and maybe add the autoconnect functionality,
you're welcome to do so. Feedback is also welcome.
Cheers
Lubo
> BR,
>
> marek
> ___
> 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: NetworkManager for Ubuntu Touch
On Fri, 2018-11-23 at 23:28 +0100, Florian Leeber wrote: > Am 21.11.2018 um 19:18 schrieb Lubomir Rintel: > > NetworkManager is doing captive portal detection for ages, though it > > recently got somewhat better. The notification should be done in the > > desktop shell. > > Hey cool, I just configured it: > > root@ubuntu-phablet:~# tail /var/log/syslog -f | grep connectivity > Nov 23 22:58:03 ubuntu-phablet NetworkManager[1774]: > [1543010283.5003] connectivity: check: send periodic request to > 'http://connectivity-check.ubuntu.com/' > Nov 23 22:58:03 ubuntu-phablet NetworkManager[1774]: > [1543010283.8697] connectivity: check for uri > 'http://connectivity-check.ubuntu.com/' with Status header successful. > Nov 23 23:03:03 ubuntu-phablet NetworkManager[1774]: > [1543010583.4998] connectivity: check: send periodic request to > 'http://connectivity-check.ubuntu.com/' > Nov 23 23:03:03 ubuntu-phablet NetworkManager[1774]: > [1543010583.8536] connectivity: check for uri > 'http://connectivity-check.ubuntu.com/' with Status header successful. > > So we could work with this version already. But a question, can it also > be triggered on any connection going down / being changed? It is supposed to. > If I disable/reenable WiFi the connection check should take place > immediately... It is supposed to. There were significant improvements to the connectivity checking lately. The connectivity checks were previously rather rudimentary, providing a simple connected/disconnected status, completely oblivious to the device that's actually used for the check. With an up-to-date NetworkManager we try to make the connectivity check use a particular device that has came up and then adjust the route metric accordingly. We also expose the result on the D-Bus. For this to work robustly you need to have systemd-resolved available (not necessarily default), otherwise we're not able to resolve names via a particular interface. I'm really really really not going to help you solve eventual problems on a rather old version when we have a new one that is a drop-in replacement. On the other hand I'm happy to help if something doesn't work with an up-to-date version. > > BR Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager for Ubuntu Touch
Hello Florian, thanks for your message. On Tue, 2018-11-20 at 11:23 +0100, Florian Leeber via networkmanager-list wrote: > Greetings, > > my name is Florian Leeber and I am in the BoD of the upcoming UBports > Foundation, which promotes Ubuntu Touch since Canonical has abandoned > it. We have so far achieved a continuation of the project, delivering an > upgrade to Ubuntu 16.04 and so forth. > > When it comes to networking, some things are crucial for a smooth user > experience on a mobile device. Unlike to a desktop or fixed server > device, a mobile device has to tackle a lot of challenges with changing > networks, WiFi connections, loosing contact, constantly changing IP > addresses etc. We're dealing with exact same challenges on machines larger than phones too. > NetworkManager has been patched for that by Canonical and others, but we > still think it could improve a lot. For quite some time I think the Canonical folks have done a good job at upstreaming their changes. E.g. ofono support got in, which I figure was one of the larger patches. Perhaps there wouldn't be too much stuff left if NM gets rebased to something more recent (more on that below). > But we are a small team, and we are > constantly looking for help. So in this context, I am currently looking > for an experienced dev that knows NetworkManager fairly well, in order > to help us test and improve it for the mobile experience we want to > achieve. If necessary he/she can receive a test device with Ubuntu Touch > and the necessary support. However, we cannot pay for the support at > them moment. There's basically four regular contributors to NetworkManager at the moment, all of us happy to improve its usefulness on phones, provided we understand what the deficiencies are. A device could help, but I think even more useful would be an x86 compose of your distribution that could be run in a VM. Do you have such builds? I suppose that would help us understand what are the specifics of the phone setup (I guess you run a different desktop shell, have Android kernel beneath, ofono instead of ModemManager, etc.). > The first goal will be to update/backport things if necessary for the > currently used 16.04 LTS version (1.2.2 I think). I know this is quite > old, but we are bound to what we get from usual Ubuntu sources for the > time being. Backporting can be done by our developers as well, if they > are guided which things to be aware of. We don't break things, including API/ABI and do regularly test our builds on Ubuntu 16.04. The version number in itself doesn't carry much meaning -- an update to 1.14.x at this point should be staightforward and safe. > Another very urgent task is to get connectivity / captive portal > recognition working, so that users can more easily connect to public > networks. This involves signalling from NM to the OS in some way so that > a popup notification with a link to the web browser is being shown. NetworkManager is doing captive portal detection for ages, though it recently got somewhat better. The notification should be done in the desktop shell. For the reference -- GNOME Shell deals with it and should provide a good example. I guess KDE does too. nm-applet does not. > I am looking forward to hearing from anyone who is interested, her eon > the ML or on my email addy. Don't hesitate to ask more, especially when we do something that doesn't make sense on a phone or miss something that would be useful. The more technical context you provide the better. I'm quite certain it's not only me who appreciates that you decided to keep the upstream project in the loop. Take care, Lubo > > BR Florian > ___ > 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: [PATCH] service: Add support for the dynamic challenge response protocol
On Tue, 2017-03-28 at 00:40 +0300, Timo Juhani Lindfors wrote:
> https://bugzilla.gnome.org/show_bug.cgi?id=751842
Thank you.
Applied (with a couple of trivial whitespace adjustments).
> ---
> src/nm-openvpn-service.c | 66
> ++--
> 1 file changed, 64 insertions(+), 2 deletions(-)
>
> diff --git a/src/nm-openvpn-service.c b/src/nm-openvpn-service.c
> index ff9aa70..2d633bc 100644
> --- a/src/nm-openvpn-service.c
> +++ b/src/nm-openvpn-service.c
> @@ -109,6 +109,8 @@ typedef struct {
> char *proxy_username;
> char *proxy_password;
> char *pending_auth;
> + char *challenge_state_id;
> + char *challenge_text;
> GIOChannel *socket_channel;
> guint socket_channel_eventid;
> } NMOpenvpnPluginIOData;
> @@ -585,6 +587,8 @@ nm_openvpn_disconnect_management_socket
> (NMOpenvpnPlugin *plugin)
> if (io_data->proxy_password)
> memset (io_data->proxy_password, 0, strlen (io_data-
> >proxy_password));
> g_free (io_data->proxy_password);
> + g_free (io_data->challenge_state_id);
> + g_free (io_data->challenge_text);
>
> g_free (priv->io_data);
> priv->io_data = NULL;
> @@ -639,6 +643,41 @@ get_detail (const char *input, const char
> *prefix)
> return ret;
> }
>
> +/* Parse challenge response protocol message of the form
> + * >PASSWORD:Verification Failed: 'Auth'
> ['CRV1:flags:state_id:username:text']
> + */
> +static gboolean
> +parse_challenge (const char *input, char **challenge_state_id, char
> **challenge_text) {
> + char *failure_reason, *colon[4];
> + int challenge_len;
> +
> + failure_reason = get_detail (input, ">PASSWORD:Verification
> Failed: 'Auth' ['");
> + if (!(failure_reason && !strncmp(failure_reason, "CRV1:",
> 4)))
> + return FALSE;
> +
> + colon[0] = strchr(failure_reason, ':');
> + if (!colon[0])
> + return FALSE;
> +
> + colon[1] = strchr(colon[0] + 1, ':');
> + if (!colon[1])
> + return FALSE;
> +
> + colon[2] = strchr(colon[1] + 1, ':');
> + if (!colon[2])
> + return FALSE;
> +
> + colon[3] = strchr(colon[2] + 1, ':');
> + if (!colon[3])
> + return FALSE;
> +
> + challenge_len = colon[2] - colon[1] - 1;
> + *challenge_state_id = g_memdup(colon[1] + 1, challenge_len +
> 1);
> + (*challenge_state_id)[challenge_len] = '\0';
> + *challenge_text = g_strdup(colon[3] + 1);
> + return TRUE;
> +}
> +
> static void
> write_user_pass (GIOChannel *channel,
> const char *authtype,
> @@ -687,7 +726,22 @@ handle_auth (NMOpenvpnPluginIOData *io_data,
> if (!username)
> username = io_data->default_username;
>
> - if (username != NULL && io_data->password != NULL) {
> + if (username != NULL && io_data->password != NULL &&
> io_data->challenge_state_id) {
> + char *response = g_strdup_printf
> ("CRV1::%s::%s",
> +
> io_data->challenge_state_id,
> +
> io_data->password);
> + write_user_pass (io_data->socket_channel,
> + requested_auth,
> + username,
> + response);
> + g_free (response);
> +
> + /* Avoid re-using challenge state. */
> + g_free (io_data->challenge_state_id);
> + io_data->challenge_state_id = NULL;
> + g_free (io_data->challenge_text);
> + io_data->challenge_text = NULL;
> + } else if (username != NULL && io_data->password !=
> NULL) {
> write_user_pass (io_data->socket_channel,
> requested_auth,
> username,
> @@ -704,6 +758,8 @@ handle_auth (NMOpenvpnPluginIOData *io_data,
> }
> if (!username && !io_data->password)
> *out_message = _("A username and
> password are required.");
> + if (io_data->challenge_text)
> + *out_message = io_data-
> >challenge_text;
> }
> handled = TRUE;
> } else if (!strcmp (requested_auth, "Private Key")) {
> @@ -817,7 +873,13 @@ handle_management_socket (NMOpenvpnPlugin
> *plugin,
> gboolean fail = TRUE;
>
> if (!strcmp (auth, "Auth")) {
> - _LOGW ("Password verification failed");
> + if (parse_challenge(str, &priv->io_data-
> >challenge_state_id, &priv->io_data->challenge_text)) {
> + _LOGD ("Received challenge '%s' for
> state '%s'",
>
Re: [PATCH] Remove assertion for empty DHCP options
On Mon, 2017-03-27 at 17:18 +0200, Alfonso Sánchez-Beato wrote:
> It turns out that some routers return responses to DHCP6
> Information-request messages that do not contain any of the options
> that we insert in the "options" table. When that happened and the
> info-only flag for DHCP6 was set, the assertion was triggered and
> NetworkManager crashed. We remove the assertion as having empty options
> is a possibility and is harmless anyway. This happened while using the
> internal dhclient.
Thank you. Applied.
> ---
> src/dhcp/nm-dhcp-client.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/dhcp/nm-dhcp-client.c b/src/dhcp/nm-dhcp-client.c
> index 28d6c59..5a465d8 100644
> --- a/src/dhcp/nm-dhcp-client.c
> +++ b/src/dhcp/nm-dhcp-client.c
> @@ -298,7 +298,6 @@ nm_dhcp_client_set_state (NMDhcpClient *self,
> > g_assert ( (priv->ipv6 && NM_IS_IP6_CONFIG (ip_config))
> > || (!priv->ipv6 && NM_IS_IP4_CONFIG (ip_config)));
> > g_assert (options);
> > - g_assert_cmpint (g_hash_table_size (options), >, 0);
> > } else {
> > g_assert (ip_config == NULL);
> > g_assert (options == NULL);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-pptp-service: Attaching specific helpers via CT-based firewall rule.
On Mon, 2017-03-06 at 06:01 +0100, poma wrote: > From d4063d327e10327b71fa11b1b573d037002fbf76 Mon Sep 17 00:00:00 > 2001 > From: poma > Date: Mon, 6 Mar 2017 05:52:55 +0100 > Subject: [PATCH] nm-pptp-service: Attaching specific helpers via CT- > based firewall rule. > Default automatic helper assignment has been turned off for security > reasons. > Generic helper doesn't handle protocol 47. Sorry I can't make sense of any of this. I'm wondering if you could try to clarify what doesn't work without the patch, preferably with error messages and log output? Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-pptp-service: Grant proto GRE by firewalld
Taking this off-list, since it's not constructive.
My actual recomendation is to get Thomas Woerner's opinion; as none of
us seem to be familiar enough with firewalld.
We should eventually fix this; thanks for pointing it out. I just feel
uncomfortable about the current patch and feel that it needs
improvement.
Thanks
Lubo
On Fri, 2017-03-03 at 10:24 +0100, poma wrote:
> On 02.03.2017 20:32, Lubomir Rintel wrote:
> > On Wed, 2017-03-01 at 08:07 +0100, poma wrote:
> > > From 28b7713cda1deba1b54bd9e52b0d62716e356b66 Mon Sep 17 00:00:00
> > > 2001
> > > > From: poma
> > >
> > > Date: Wed, 1 Mar 2017 07:05:40 +0100
> > > Subject: [PATCH] nm-pptp-service: Grant proto GRE by firewalld.
> > >
> > > With recent kernels, the Poptop - The PPTP Server for Linux
> > > (pptpd) requires
> > > explicit load of nf_conntrack_pptp kernel module to achieve the
> > > operating state of the service itself.
> > > However this is not the case with the PPTP Client (pptp) on a
> > > Linux based platform.
> > > What is needed is to apply directly, rule within the firewalld,
> > > to grant proto gre,
> > > to achieve the operating state of the client itself.
> > >
> > > Ref.
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1187328
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1214643
> > > ---
> > > src/nm-pptp-service.c | 16 ++--
> > > 1 file changed, 10 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/src/nm-pptp-service.c b/src/nm-pptp-service.c
> > > index 1710fd9..6a66386 100644
> > > --- a/src/nm-pptp-service.c
> > > +++ b/src/nm-pptp-service.c
> > > @@ -1113,7 +1113,7 @@ main (int argc, char *argv[])
> > > > GMainLoop *main_loop;
> > > > gboolean persist = FALSE;
> > > > GOptionContext *opt_ctx = NULL;
> > > > - char *conntrack_module[] = { "/sbin/modprobe",
> > > > "nf_conntrack_pptp", NULL };
> > > > + char *firewalld_grant_proto_gre[] = { "/bin/firewall-
> > > > cmd", "--direct", "--add-rule", "ipv4", "filter", "INPUT", "0",
> > > > "-p", "gre", "-j", "ACCEPT", NULL };
> > > > ...
> > > > + if (!g_spawn_sync (NULL, firewalld_grant_proto_gre,
> > > > NULL, 0, NULL, NULL, NULL, NULL, NULL, &error)) {
> > > > + _LOGW ("granting proto gre by firewalld
> > > > failed: %s", error->message);
> > > > g_error_free (error);
> > > > }
> >
> > As Thomas Haller already suggested; we probably should not be
> > removing
> > the module load. It doesn't seem to have anything to do with a
> > missing
> > firewall rule.
> >
>
> With only loaded modules it will not work if:
> $ sysctl net.netfilter.nf_conntrack_helper
> net.netfilter.nf_conntrack_helper = 0
> OR
> $ cat /sys/module/nf_conntrack/parameters/nf_conntrack_helper
> N
>
> The correct firewall(s) rule(s) should replace both.
>
> > I'm not sure either whether we should be punching holes in the
> > firewall
> > automatically or if this is the proper way to do that. I'm
> > especially
> > not sure if we should be calling firewall-cmd instead of talking D-
> > Bus
> > and if it's all right that we don't clean up the rule when we tear
> > down
> > all PPTP connections.
> >
> > Adding Thomas Woerner to the loop; hopefully he'll be able to
> > provide
> > some help.
> >
> > Lubo
> >
>
> I wrote about firewalld because I use it.
> No one's stopping NM to talk via D-BUS with any implementation of a
> firewall that is used.
>
> So, what is your actual recommendation, in this particular case?
>
> Ref.
> - Secure use of iptables and connection tracking helpers
> https://home.regit.org/netfilter-en/secure-use-of-helpers
> - iptables connection tracking helpers
> http://www.odi.ch/weblog/posting.php?posting=663
> - Automatic Helper Assignment
> http://www.firewalld.org/2016/10/automatic-helper-assignment
> - Netfilter Helpers
> http://shorewall.org/Helpers.html
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-pptp-service: Grant proto GRE by firewalld
On Wed, 2017-03-01 at 08:07 +0100, poma wrote:
> From 28b7713cda1deba1b54bd9e52b0d62716e356b66 Mon Sep 17 00:00:00 2001
> > From: poma
> Date: Wed, 1 Mar 2017 07:05:40 +0100
> Subject: [PATCH] nm-pptp-service: Grant proto GRE by firewalld.
>
> With recent kernels, the Poptop - The PPTP Server for Linux (pptpd) requires
> explicit load of nf_conntrack_pptp kernel module to achieve the operating
> state of the service itself.
> However this is not the case with the PPTP Client (pptp) on a Linux based
> platform.
> What is needed is to apply directly, rule within the firewalld, to grant
> proto gre,
> to achieve the operating state of the client itself.
>
> Ref.
> https://bugzilla.redhat.com/show_bug.cgi?id=1187328
> https://bugzilla.redhat.com/show_bug.cgi?id=1214643
> ---
> src/nm-pptp-service.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/src/nm-pptp-service.c b/src/nm-pptp-service.c
> index 1710fd9..6a66386 100644
> --- a/src/nm-pptp-service.c
> +++ b/src/nm-pptp-service.c
> @@ -1113,7 +1113,7 @@ main (int argc, char *argv[])
> > GMainLoop *main_loop;
> > gboolean persist = FALSE;
> > GOptionContext *opt_ctx = NULL;
> > - char *conntrack_module[] = { "/sbin/modprobe", "nf_conntrack_pptp",
> > NULL };
> > + char *firewalld_grant_proto_gre[] = { "/bin/firewall-cmd", "--direct",
> > "--add-rule", "ipv4", "filter", "INPUT", "0", "-p", "gre", "-j", "ACCEPT",
> > NULL };
> > ...
> > + if (!g_spawn_sync (NULL, firewalld_grant_proto_gre, NULL, 0, NULL,
> > NULL, NULL, NULL, NULL, &error)) {
> > + _LOGW ("granting proto gre by firewalld failed: %s",
> > error->message);
> > g_error_free (error);
> > }
As Thomas Haller already suggested; we probably should not be removing
the module load. It doesn't seem to have anything to do with a missing
firewall rule.
I'm not sure either whether we should be punching holes in the firewall
automatically or if this is the proper way to do that. I'm especially
not sure if we should be calling firewall-cmd instead of talking D-Bus
and if it's all right that we don't clean up the rule when we tear down
all PPTP connections.
Adding Thomas Woerner to the loop; hopefully he'll be able to provide
some help.
Lubo
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Towards NetworkManager 1.6
Hello everyone! we've decided to release NetworkManager 1.6 rather soon. Among over 1000 commits since NetworkManager 1.4 there are usual bug fixes, improvements, but also a plenty of cool features. It would be a shame if it took too long for them to find their ways into your favorite distributions' package collections. To name a few: * MACsec support (requires a very new wpa_supplicant) * Delegation if IPv6 prefixes to shared connections * Automatic proxy configuration via PacRunner * More flexible MAC address randomization * Initial support for PKCS#11 tokens with 802.1x * libnm Vala bindings A more comprehensive list of changes in the 1.6 series is available here: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=nm-1-6 Yesterday, we've released the first release candidate (1.6-rc1, aka 1.5.90). Available from the usual place: https://download.gnome.org/sources/NetworkManager/1.5/NetworkManager-1.5.90.tar.xz We're not going to release a new major version of the applet or the VPN plugins at this point as they essentially remain compatible with the 1.4 version of NetworkManager. As usual, all the API and ABI changes in the new stable version remain backwards compatible with the previous stable branches. If you spot an incompatibility, we'd like to hear! Everyone is invited to test, test, test. Your feedback is essential in making this release the most solid one we've ever delivered. Thank you! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to avoid using policy kit with openvpn
On Fri, 2016-11-25 at 15:20 +0200, matti kaasinen wrote: > > 2016-11-24 16:03 GMT+02:00 matti kaasinen : > > > To be more exact: service that dos not start anymore after I enable and > > later disable it is avahi-daemon.service. It is told in that unit file that: > > Alias=dbus-org.freedesktop.Avahi.service. > > > > > In fact, it seems that any operations using dbus (NTP, avahi...) have > problems after starting openvpn service and it does not vanish if I stop > it. So, it seems that either openvpn sevice (or possibly NM) creates policy > some policy kit rule that does not vanish when I disable and stop openvpn. That sounds very strange. Please enable eavesdropping on the system bus: https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus And then monitor the actual bus traffic before starting the "openvpn service" (is that the NM VPN plugin?) and after starting it and look out for what changed. You can use "busctl monitor" or "dbus-monitor --system" to do the monitoring. Be sure to disable eavesdropping afterwards. If it won't be obvious what went wrong then please share the logs (preferably via a pastebin and after making sure you're not leaking your passwords). Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Porting dbus-glib code for NM 0.8.6 to NM 1.4.2
Hello, On Tue, 2016-11-22 at 20:52 +0100, W. Martin Borgert wrote: > Hi, > > I need to port old non-GUI C code using the dbus-glib based API of > NM 0.8.6 to whatever is the best option today. According to Dans > blog post¹ some months ago, GDBus is the way to go. > > Is there a porting guide available? Or are there nice examples? Well, the choice of the D-Bus library is not really a NetworkManager issue -- use whichever library works well for you. dbus-glib, while not recommended for new code, might still make sense when porting old code with minimal effort. We chose GDBus because it's readily available in glib's gio and includes a tool that generates C code that interoperates well with GObject. This part of GDBus manual seems like a good place to start. It applies to NetworkManager pretty well; just generate the code from XMLs you find in the introspection/ tree: [1]. [1] https://developer.gnome.org/gio/stable/gdbus-codegen.html If you prefer a minimal library or avoid generating code from the introspection data, sd-bus library might also be a good choice. See [2] and sd-bus(3) manual [2] http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html Another option would be to avoid speaking D-Bus directly and use libnm instead. However, it might be an overkill for a simple project. When it comes to the NetworkManager D-Bus API itself, the 0.9 porting guide might come handy: [3]. Since 0.9 we are careful not to ever do incompatible API changes. The full API reference is at [4]. [3] https://developer.gnome.org/NetworkManager/0.9/ref-migrating.html [4] https://developer.gnome.org/NetworkManager/1.4/ > Many thanks in advance! > > Cheers > > ¹ https://blogs.gnome.org/dcbw/2016/02/19/die-dbus-glib-die/ > Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet: "NetworkManager is not running..."
Hi poma,
please raise the issue with the firewalld developers. It could be that
we indeed have a circular dependency and should break it down.
Related: https://github.com/t-woerner/firewalld/pull/171
On Sat, 2016-11-19 at 15:22 +0100, poma wrote:
> On 17.11.2016 20:01, poma wrote:
> > On 17.11.2016 12:40, poma wrote:
> > > On 16.11.2016 09:51, poma wrote:
> > > > On 15.11.2016 08:59, poma wrote:
> > > > > Cold Boot from Soft Off aka S5, promptly Logged In to X
> > > > > session
> > > > > nm-applet: "NetworkManager is not running..."
> > > > >
> > > > > $ nmcli general status
> > > > > STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
> > > > > connected full enabled enabled enabled enabled
> > > > > $ systemctl is-active NetworkManager
> > > > > active
> > > > > $ systemd-analyze blame | grep Net
> > > > > 427ms NetworkManager.service
> > > > >
> > > > >
> > > > > Subsequently after Reboot aka Warm Boot, likewise
> > > > > nm-applet: "NetworkManager is not running..."
> > > > >
> > > > >
> > > > > To fix this, Re-Log In is required,
> > > > > or wait for a minute before Log In.
> > > > >
> > > > >
> > > >
> > > > [...]
> > > >
> > > > If firewalld isn't involved:
> > > >
> > > > $ systemctl is-enabled firewalld.service
> > > > disabled
> > > > $ systemctl is-active firewalld.service
> > > > inactive
> > > >
> > > > the problem disappears,
> > > > however,
> > > > if firewalld -is- involved
> > > >
> > > > $ systemd-analyze blame | egrep Net\|firewall
> > > > 33.083s firewalld.service
> > > > 340ms NetworkManager.service
> > > >
> > > > the problem appears.
> > > >
> > >
> > > [...]
> > >
> > > NetworkManager-1.5.2-0.5.20161116gitcb61dd1.fc24.x86_64
> > > network-manager-applet-1.4.3-0.12.20161115git137ec04.fc24.x86_64
> > > &
> > > firewalld-0.4.4.1-3.fc24.noarch
> > > - incl. firewall.core.fw_nm: create NMClient lazily
> > > https://github.com/t-woerner/firewalld/commit/52620dd.patch
> > >
> > > $ systemd-analyze blame | egrep two\|ewa
> > > 9.313s firewalld.service
> > > 745ms NetworkManager.service
> > >
> > >
> > > Resolved thanks to Lubo.
> > >
> >
> > Although, there is one side effect;
> >
> > firewall-config Warning:
> > "Failed to get connections from NetworkManager"
> >
>
> Replaces firewall-config Warning:
> "Failed to get connections from NetworkManager"
> for:
> "Trying to connect to firewalld, waiting..."
> A one click less.
>
> ---
> src/firewall-config | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/firewall-config b/src/firewall-config
> index 4d400aa..d4f54f6 100755
> --- a/src/firewall-config
> +++ b/src/firewall-config
> @@ -1552,7 +1552,7 @@ class FirewallConfig(object):
> nm_get_connections(self.connections,
> self.connections_uuid)
> except Exception as msg:
> text = _("Failed to get connections from
> NetworkManager")
> -self._warning(text)
> +#self._warning(text)
>
> iter = self.interfaceStore.get_iter_first()
> while iter:
> ___
> 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: Poisontap security issue of NetworkManager?
Hello Claudius, On Thu, 2016-11-17 at 12:10 +0100, Claudius Heine wrote: > Hi! > > While reading about the poisontap hack by Samy Kamkar > (https://samy.pl/poisontap/), I thought about ideas to prevent that. Too much drama there. Hijacking the internet connection of a box you have physical access to is hardly a security issue. > I think the main issue is, that the network device is automatically > setup via dhcp by tools like NetworkManager & co. That is a feature. You generally want network connectivity when you plugin a network adapter with a cable in it. > So my question is: Is that more of a system configuration issue or > can > NetworkManager itself do something to prevent this scenario (e.g. not > starting dhcpcd on new interfaces generally or only while system is > locked)? Yes, the feature can be turned off. Check out no-auto-default=* in NetworkManager.conf(5) manual. In Fedora it's sufficient to install NetworkManager-config-server package. However, if you don't trust your USB ports, you may want to set the sysfs attribute "authorized" to false by default on USB devices. Perhaps with a udev rule or something. > > Thanks and have a nice day, > Claudius Have a nice day too! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.4.0 released
Hello everyone! Four months and almost thousand commits after NetworkManager 1.2 we're pleased to announce that NetworkManager 1.4 is here! It brings better MAC address randomization options, improved command line tool, API for configuration checkpoint/rollback, data counters, oFono support and countless internal improvements and bug fixes. Read more here: http://blogs.gnome.org/lkundrak/2016/08/24/networkmanager-1-4/ A complete summary of major changes is available in the NEWS files: http://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/NEWS https://git.gnome.org/browse/network-manager-applet/plain/NEWS NetworkManager 1.4 remains API and ABI compatible with the previous stable series. Grab it while it's hot: https://download.gnome.org/sources/NetworkManager/1.4/NetworkManager-1.4.0.tar.xz https://download.gnome.org/sources/network-manager-applet/1.4/network-manager-applet-1.4.0.tar.xz This release wouldn't be possible without the work of Alfonso Sanchez-Beato, Anders Jonsson, Bastien Nocera, Beniamino Galvani, Christian Kirbach, Cosimo Cecchi, Dan Williams, Didier Raboud, Francesco Giudici, Jiří Klimeš, Joel Holdsworth, Lubomir Rintel, Mario Sanchez Prada, Mathieu Trudel-Lapierre, Michael Biebl, Mingye Wang (Arthur2e5), Patrick J. Volkerding, Piotr Drąg, poma, Rafael Fontenelle, Shih-Yuan Lee (FourDollars), Thomas Haller and Tony Espy. Thank you! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager 1.4 article: call for help
Hi. We're nearing 1.4 GA. Here's the draft of the blog post: http://etherpad.corp.redhat.com/nm-1-4-announcement As usual, input from you -- folks whose language and technical qualities largely surpass mine -- helps tremendously. NetworkManager crowd: don't be shy to do *large* edits; add features I've omitted or perhaps cross out stuff you deem extraneous. Thank you! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Status: Aug 15 - Aug 19 (Week 33)
This week plan: * RHEL bugs * Bug 1231526 - nmcli slow with large numbers of VLANs This week done: * 1.4 RC1 * fix syslog logging for 7.3 - Follow-up on this. The rest is now an anaconda bug; worked with the installer team to ensure they understand the issue. * rh #1367248 - Installing guest os failed with RHEL-7.3-20160811.0 ppc64le iso file - Triaged this. Turned out to be a toolchain bug, already fixed in later versions; reassigned appropriately. * rh #1231526 - nmcli slow with large numbers of VLANs - Progressed this to the point nmcli mostly works with D-Bus object manager. * rh #1367702 - A crash in the test suite - Fixed this Next week plan: * 1.4 pre-release testing & fixing - I expect this to consume most of week's time * rh #1231526 - nmcli slow with large numbers of VLANs - Post for a review * rh #1256822 - support ipv6 shared connections - The userspace part Top 3 bugzillas: * rh #1241822 Handling of aliases in NM (pm_score=2000) - Scheduled a meeting to talk about this with the reporter; to ensure we agree on requirements of what needs to be implemented. * rh #909236 - [BNE] Feature Reddit: Out of the box traffic shaping support (pm_score=600) - Work on this started, but was pre-empted by work of higher priority. * rh #1256822 - support ipv6 shared connections - 7.3 prio item ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.3.91 (1.4-rc1) released
Hello, we've just tagged and released the first release candidate for NetworkManager 1.4. Since the 1.4-beta1 release we've fixed a couple of bugs and added two interesting features: counters of data transmitted on a device [1] and API for checkpoint and restore [2] of the connection configuration. [1] https://developer.gnome.org/NetworkManager/unstable/gdbus-org.freedesktop.NetworkManager.Device.Statistics.html [2] https://developer.gnome.org/NetworkManager/1.3/gdbus-org.freedesktop.NetworkManager.html#gdbus-method-org-freedesktop-NetworkManager.CheckpointCreate The complete summary of the changes since 1.2 release can be found in usual places: http://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/NEWS https://git.gnome.org/browse/network-manager-applet/plain/NEWS The API and ABI is now frozen for release and we'll spend next week or so ensuring we iron out any potential wrinkles. You can help us by trying out the freshly released bits yourself and letting us know how well it works for you: https://download.gnome.org/sources/NetworkManager/1.3/NetworkManager-1.3.91.tar.xz https://download.gnome.org/sources/network-manager-applet/1.3/network-manager-applet-1.3.91.tar.xz Your contributions and feedback is greatly appreciated! On behalf of the NetworkManager crowd Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IP configuration invalid
On Sat, 2016-07-30 at 17:03 +0200, Andreas Moroder wrote: > Hello, > > I am unable to configure Networkmanager to connect to a cisco VPN. I > get > the error "IP configuration invalid" ( translated from german ) > I can connect using vpnc. > My opensuse is german, so maybe the names of the configuration mask > fields are different > I have set > Gateway to the value in IPsec gateways > Username to Xauth username > Userpassword to the password vpnc asks me > Groupname to IPsec ID > Grouppassword to IPsec secret > > and as method "link-local"* That one makes no sense for VPNs I think. Does the remote provide you with network configuration? If not, then that's what the error message says. > *I use NM 1.0.12 on Opensuse* I'm wondering if you could attach the log from the connection attempt (run "journalctl -fl" and capture the output)? (There should be no secrets there, but please check twice). Also, checking with a more recent version of NM may make sense -- there was a ton of work done on the Libreswan plugin and NetworkManager itself after 1.0. > *Can anyone please help me > Thank you > Andreas Thanks, Lubo > ___ > 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: [PATCH 3/3] nm-c-e: UI file for Proxy Tab
On Wed, 2016-07-27 at 20:33 +0530, Atul Anand wrote: > On 7/26/16, Lubomir Rintel wrote: > > > > On Tue, 2016-07-12 at 18:00 +0530, Atul Anand wrote: > > > > > > UI file for 'Proxy' tab contain entries/widgets for the three > > > mode c-e > > > is offering. On setting mode 'none' nothing is pushed inside > > > PacRunner > > > (only exception being Domains which is sent for all modes). In > > > mode > > > 'auto' > > > Pac Url or/and Pac Script can be inserted which PacRunner handles > > > in an > > > order. The 'manual' mode gives entries for different protocols > > > and an > > > entry for adding no-proxy-for (excludes) for that specific > > > connection. > > > --- > > > src/connection-editor/ce-page-proxy.ui | 475 > > > + > > > 1 file changed, 475 insertions(+) > > > create mode 100644 src/connection-editor/ce-page-proxy.ui > > > > > > diff --git a/src/connection-editor/ce-page-proxy.ui > > > b/src/connection-editor/ce-page-proxy.ui > > > new file mode 100644 > > > index 000..fe63c43 > > > --- /dev/null > > > +++ b/src/connection-editor/ce-page-proxy.ui > > > @@ -0,0 +1,475 @@ > > > + > > > + > > > > 3.4 please. > > I Guess you meant 3.20 because glade 3_20_IS_LATEST. I need to > upgrade > more packages for this ex: gtk+ >= 3.20. Sorry; I meant this ^^^. We generally target gtk-3.4 at this point. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 2/3] nm-c-e: Proxy Page Implementation.
On Tue, 2016-07-12 at 18:00 +0530, Atul Anand wrote:
> This Patch implements the Proxy page GUI. Conventional GUI has been
> implemented which people generally see in Browsers. Exception being
> there is a separate page for each of the connection whether active
> or inactive.
>
> + * Atul Anand
"(C) Copyright 2016 Atul Anand ." please.
> + /* Method */
> + method = gtk_combo_box_get_active (priv->method);
> + switch (method) {
> + case PROXY_METHOD_NONE:
> + nm_connection_remove_setting (CE_PAGE (self)->connection,
> NM_TYPE_SETTING_PROXY);
> + priv->setting = (NMSettingProxy *) nm_setting_proxy_new ();
> + nm_connection_add_setting (CE_PAGE (self)->connection,
> NM_SETTING (priv->setting));
> +
> + /* Update NMSetting */
> + g_object_set (priv->setting,
> + NM_SETTING_PROXY_METHOD,
> NM_SETTING_PROXY_METHOD_NONE,
> + NULL);
> + break;
Wouldn't it be a better idea to omit the proxy setting altogether when
the method is NONE?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 3/3] nm-c-e: UI file for Proxy Tab
On Tue, 2016-07-12 at 18:00 +0530, Atul Anand wrote: > UI file for 'Proxy' tab contain entries/widgets for the three mode c-e > is offering. On setting mode 'none' nothing is pushed inside PacRunner > (only exception being Domains which is sent for all modes). In mode 'auto' > Pac Url or/and Pac Script can be inserted which PacRunner handles in an > order. The 'manual' mode gives entries for different protocols and an > entry for adding no-proxy-for (excludes) for that specific connection. > --- > src/connection-editor/ce-page-proxy.ui | 475 > + > 1 file changed, 475 insertions(+) > create mode 100644 src/connection-editor/ce-page-proxy.ui > > diff --git a/src/connection-editor/ce-page-proxy.ui > b/src/connection-editor/ce-page-proxy.ui > new file mode 100644 > index 000..fe63c43 > --- /dev/null > +++ b/src/connection-editor/ce-page-proxy.ui > @@ -0,0 +1,475 @@ > + > + 3.4 please. > + > +True > +False > +12 > +vertical > +18 This is a bit too spacey. I think we use 6 elsewhere? > + > +Default > +True > +True > +False > +Make HTTP proxy default for all protocols. > +100 > +0 This is deprecated. Please use start instead. > + > + > +SOCKS v5 > +True > +True > +False > +Default is SOCKS v4. > +100 > +2.2351741291171123e-10 start instead please. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v2 2/5] NMPacRunnerManager implemented to interact with PacRunner
On Tue, 2016-07-12 at 17:57 +0530, Atul Anand wrote:
>
> A new object NMPacRunnerManager has been added to manage and interact
> PacRunner. It invokes both DBus methods on PacRunner DBus interface.
> It stores the returned object path from CreateProxyConfiguration()
> to feed as parameter to DestroyProxyCofiguration() when network goes down.
> +static void
> +pacrunner_proxy_cb (GObject *source, GAsyncResult *res, gpointer user_data)
> +{
> + NMPacRunnerManager *self = NULL;
> + NMPacRunnerManagerPrivate *priv;
> + gs_free_error GError *error = NULL;
> + gs_free char *owner = NULL;
Not used.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v2 5/5] Fixes to update PacRunner at the right moment.
On Tue, 2016-07-12 at 17:57 +0530, Atul Anand wrote:
> src/: Fixes in core to update PacRunner at the right place and moment.
> When a device goes up PacRunner is configured with the Device IPxConfigs
> and Proxy Config. When it goes down the same configuration is removed
> from PacRunner.
>
> ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network
> scripts.
>
>
> NULL);
> +
> + /* Load PacRunner with VPN's config */
> + if (!nm_pacrunner_manager_send (nm_pacrunner_manager_get (),
> + priv->ip_iface,
> + priv->proxy_config,
> + priv->ip4_config,
> + priv->ip6_config))
> + _LOGI ("Couldn't update pacrunner for %s",
> priv->ip_iface);
priv->proxy_config can be NULL here and probably in other places.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v2 1/5] A new object 'NMProxyConfig' with fields for proxy.
On Tue, 2016-07-12 at 17:57 +0530, Atul Anand wrote:
> A new object NMProxyConfig has been implemented which contain fields
> for proxy related stuff.
> ---
>
> + port = (guint32) atoi (str);
> + if (port >= 0)
Port is unsigned, is always >= 0. Perhaps you meant "if (port)" or
wanted to omit the condition altogether?
> + g_object_set (s_proxy,
> NM_SETTING_PROXY_HTTP_PORT, port, NULL);
> + g_free (str);
> +
> + } else if (strstr (tmp, "https://";)) {
> + tmp = tmp + 8;
> + str = g_strndup (tmp, strchr (tmp, ':') - tmp);
> + g_object_set (s_proxy,
> NM_SETTING_PROXY_SSL_PROXY, str, NULL);
> + g_free (str);
> +
> +
> + tmp = strchr (tmp, ':') + 1;
> + str = g_strndup (tmp, strchr (tmp, '/') - tmp);
> + port = (guint32) atoi (str);
> + if (port >= 0)
Ditto.
> + g_object_set (s_proxy,
> NM_SETTING_PROXY_SSL_PORT, port, NULL);
> + g_free (str);
> +
> + } else if (strstr (tmp, "ftp://";)) {
> + tmp = tmp + 6;
> + str = g_strndup (tmp, strchr (tmp, ':') - tmp);
> + g_object_set (s_proxy,
> NM_SETTING_PROXY_FTP_PROXY, str, NULL);
> + g_free (str);
> +
> + tmp = strchr (tmp, ':') + 1;
> + str = g_strndup (tmp, strchr (tmp, '/') - tmp);
> + port = (guint32) atoi (str);
> + if (port >= 0)
Ditto.
> + g_object_set (s_proxy,
> NM_SETTING_PROXY_FTP_PORT, port, NULL);
> + g_free (str);
> +
> + } else if (strstr (tmp, "socks4://") || strstr (tmp,
> "socks5://")) {
> + if (strstr (tmp, "socks5://"))
> + g_object_set (s_proxy,
> NM_SETTING_PROXY_SOCKS_VERSION_5, TRUE, NULL);
> + else
> + g_object_set (s_proxy,
> NM_SETTING_PROXY_SOCKS_VERSION_5, FALSE, NULL);
> +
> + tmp = tmp + 9;
> + str = g_strndup (tmp, strchr (tmp, ':') - tmp);
> + g_object_set (s_proxy,
> NM_SETTING_PROXY_SOCKS_PROXY, str, NULL);
> + g_free (str);
> +
> + tmp = strchr (tmp, ':') + 1;
> + str = g_strndup (tmp, strchr (tmp, '/') - tmp);
> + port = (guint32) atoi (str);
> + if (port >= 0)
Ditto.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v2 3/5] NMSettingProxy added to libnm-core
On Tue, 2016-07-12 at 17:57 +0530, Atul Anand wrote:
> libnm-core has been expanded to include proxy settings which clients
> like nm-connection-editor use to configure proxy in PacRunner. It
> offers three modes i.e 'none', 'auto' and 'manual' and according take
> data to configure PacRunner. The modes matches on the PacRunner side
> too.
>
> @@ -751,6 +756,14 @@ _normalize_ip_config (NMConnection *self,
> GHashTable *parameters)
> * to fail. But if no IP4 setting was specified,
> assume the caller was just
> * being lazy.
> */
> + if (!s_proxy) {
> + setting = nm_setting_proxy_new ();
> +
> + g_object_set (setting,
> + NM_SETTING_PROXY_METHOD,
> NM_SETTING_PROXY_METHOD_NONE,
> + NULL);
> + nm_connection_add_setting (self, setting);
> + }
I'm not sure if it makes sense to create proxy settings here. Do they
always need to be present?
If yes, please adjust the tests and the comment.
> --- a/libnm/libnm.ver
> +++ b/libnm/libnm.ver
> @@ -1066,6 +1066,23 @@ libnm_1_2_4 {
> libnm_1_4_0 {
> global:
> nm_device_team_get_config;
> + nm_connection_get_setting_proxy;
> + nm_setting_proxy_get_type;
> + nm_setting_proxy_new;
> + nm_setting_proxy_get_method;
> + nm_setting_proxy_get_http_proxy;
> + nm_setting_proxy_get_http_port;
> + nm_setting_proxy_get_http_default;
> + nm_setting_proxy_get_ssl_proxy;
> + nm_setting_proxy_get_ssl_port;
> + nm_setting_proxy_get_ftp_proxy;
> + nm_setting_proxy_get_ftp_port;
> + nm_setting_proxy_get_socks_proxy;
> + nm_setting_proxy_get_socks_port;
> + nm_setting_proxy_get_socks_version_5;
> + nm_setting_proxy_get_pac_script;
> + nm_setting_proxy_get_no_proxy_for;
> + nm_setting_proxy_get_pac_url;
> nm_setting_connection_get_stable_id;
> nm_setting_ip6_config_get_token;
> nm_setting_ip_config_get_dns_priority;
Please also add nm_setting_proxy_method_get_type(); mkenums creates the
glib type for the NMSettingProxyMethod typedef and it's needed at least
to generate the introspection data.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v2 5/5] Fixes to update PacRunner at the right moment.
On Tue, 2016-07-12 at 17:57 +0530, Atul Anand wrote:
> src/: Fixes in core to update PacRunner at the right place and
> moment.
> When a device goes up PacRunner is configured with the Device
> IPxConfigs
> and Proxy Config. When it goes down the same configuration is removed
> from PacRunner.
>
> ifcfg-rh: Fixed to read and write proxy settings to the ifcfg network
> scripts.
>
> static gboolean
> +write_proxy_setting (NMConnection *connection, shvarFile *ifcfg,
> GError **error)
> +{
> + NMSettingProxy *s_proxy;
> + NMSettingProxyMethod method;
> + char *tmp;
> + const char *pac_url, *pac_script;
> + const char *http_proxy, *ssl_proxy, *ftp_proxy,
> *socks_proxy;
> + guint32 http_port, ssl_port, ftp_port, socks_port;
> + gboolean http_default, socks_version_5;
> + GString *no_proxy_for;
> + char **iter, **excludes = NULL;
> +
> + s_proxy = nm_connection_get_setting_proxy (connection);
> + if (!s_proxy)
> + return FALSE;
You want to return TRUE here. It's alright not to have proxy settings
and when returning FALSE you need to set an error.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Replace 'Ternary' with 'Tertiary'
On Tue, 2016-07-26 at 01:04 -0400, Mathieu Trudel-Lapierre wrote: > From a suggestion by Dave Jury on > https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug > /1598803 > > Ternary tends to mean "having three parts", and has other > significance in > IT. Using "Tertiary" seems to be a better choice, even though they > may > both be used interchangeably (afaict from dictionary.com anyway). > > Signed-off-by: Mathieu Trudel-Lapierre ical.com> > Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/network-manager > -applet/+bug/1598803 Applied, thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/5] New GObject NMProxyConfig added to hold proxy details.
Hi,
nice work; the patch set looks overall very good. I'll take a closer
look tomorrow.
Two general nitpicks:
Please comment more. Especially the non-static procedures often need a
Gtk-Doc block. E.g. looking at nm_pacrunner_manager_send() I have very
little idea why do I need to pass ip* configs, and what are they used
for without digging too deep into the code. Also, the logic sometimes
need comments: for instance after a quick look at add_ip4_config() I
can't figure why it only works for type=vpn.
Also, please add license blocks for files you add and copyright notices
wherever you add non-trivial amount of code.
Thank you,
Lubo
On Fri, 2016-06-24 at 00:42 +0530, Atul Anand wrote:
> A new Object NMProxyConfig added with properties for proxies,
> PAC Url and PAC Script. Getters are setters implemented for
> manipulating those fields.
> ---
> src/Makefile.am | 4 +
> src/nm-proxy-config.c | 243
> ++
> src/nm-proxy-config.h | 53 +++
> 3 files changed, 300 insertions(+)
> create mode 100644 src/nm-proxy-config.c
> create mode 100644 src/nm-proxy-config.h
>
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 5e289d9..700cfc4 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -415,6 +415,8 @@ libNetworkManager_la_SOURCES = \
> nm-exported-object.h \
> nm-firewall-manager.c \
> nm-firewall-manager.h \
> + nm-proxy-config.c \
> + nm-proxy-config.h \
> nm-ip4-config.c \
> nm-ip4-config.h \
> nm-ip6-config.c \
> @@ -565,6 +567,8 @@ libnm_iface_helper_la_SOURCES = \
> \
> nm-exported-object.c \
> nm-exported-object.h \
> + nm-proxy-config.c \
> + nm-proxy-config.h \
> nm-ip4-config.c \
> nm-ip4-config.h \
> nm-ip6-config.c \
> diff --git a/src/nm-proxy-config.c b/src/nm-proxy-config.c
> new file mode 100644
> index 000..93f9b21
> --- /dev/null
> +++ b/src/nm-proxy-config.c
> @@ -0,0 +1,243 @@
> +/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4
> -*- */
> +
> +#include "nm-default.h"
> +
> +#include "nm-proxy-config.h"
> +
> +#include
> +
> +#include "nm-utils.h"
> +#include "NetworkManagerUtils.h"
> +
> +#define NM_PROXY_CONFIG_GET_PRIVATE(o) (G_TYPE_INSTANCE_GET_PRIVATE
> ((o), NM_TYPE_PROXY_CONFIG, NMProxyConfigPrivate))
> +
> +G_DEFINE_TYPE (NMProxyConfig, nm_proxy_config, G_TYPE_OBJECT)
> +
> +typedef struct {
> + NMProxyConfigMethod method;
> + GPtrArray *proxies;
> + char *pac_url;
> + char *pac_script;
> +} NMProxyConfigPrivate;
> +
> +NM_GOBJECT_PROPERTIES_DEFINE (NMProxyConfig,
> + PROP_METHOD,
> + PROP_PROXIES,
> + PROP_PAC_URL,
> + PROP_PAC_SCRIPT,
> +);
> +
> +NMProxyConfig *
> +nm_proxy_config_new (void)
> +{
> + return NM_PROXY_CONFIG (g_object_new (NM_TYPE_PROXY_CONFIG,
> NULL));
> +}
> +
> +void
> +nm_proxy_config_set_method (NMProxyConfig *config,
> NMProxyConfigMethod method)
> +{
> + NMProxyConfigPrivate *priv = NM_PROXY_CONFIG_GET_PRIVATE
> (config);
> +
> + priv->method = method;
> +}
> +
> +NMProxyConfigMethod
> +nm_proxy_config_get_method (const NMProxyConfig *config)
> +{
> + NMProxyConfigPrivate *priv = NM_PROXY_CONFIG_GET_PRIVATE
> (config);
> +
> + return priv->method;
> +}
> +
> +void
> +nm_proxy_config_reset_proxies (NMProxyConfig *config)
> +{
> + NMProxyConfigPrivate *priv = NM_PROXY_CONFIG_GET_PRIVATE
> (config);
> +
> + if (priv->proxies->len !=0) {
> + g_ptr_array_set_size (priv->proxies, 0);
> + _notify (config, PROP_PROXIES);
> + }
> +}
> +
> +void
> +nm_proxy_config_add_proxy (NMProxyConfig *config, const char *proxy)
> +{
> + NMProxyConfigPrivate *priv = NM_PROXY_CONFIG_GET_PRIVATE
> (config);
> + int i;
> +
> + g_return_if_fail (proxy != NULL);
> + g_return_if_fail (proxy[0] != '\0');
> +
> + for (i = 0; i < priv->proxies->len; i++)
> + if (!g_strcmp0 (g_ptr_array_index (priv->proxies,
> i), proxy))
> + return;
> +
> + g_ptr_array_add (priv->proxies, g_strdup (proxy));
> + _notify (config, PROP_PROXIES);
> +}
> +
> +void
> +nm_proxy_config_del_proxy (NMProxyConfig *config, guint i)
> +{
> + NMProxyConfigPrivate *priv = NM_PROXY_CONFIG_GET_PRIVATE
> (config);
> +
> + g_return_if_fail (i < priv->proxies->len);
> +
> + g_ptr_array_remove_index (priv->proxies, i);
> + _notify (config, PROP_PROXIES);
> +}
> +
> +guint32
> +nm_proxy_config_get_num_proxies (const NMProxyConfig *config)
> +{
> + NMProxyConfigPrivate *priv = NM_PROXY_CONFIG_GET_PRIVATE
> (config);
> +
> + return priv->proxies->len;
> +}
> +
> +const char *
> +nm_proxy_config_get_proxy (const NMProxyConfig *config, guint i)
> +{
> + NMProxyConfigPrivate *priv = NM_PROXY_CONFIG_GET_PRIVATE
> (config);
> +
> + return g_ptr_array_index (priv->proxies, i);
> +}
> +
> +void
> +nm_proxy_config_set_pac_url (NMProxyConfig *config, const char *url)
> +
Re: [PATCH] extracting CISCO_PROXY_PAC env variable
On Fri, 2016-06-24 at 00:43 +0530, Atul Anand wrote:
> ---
> src/nm-openconnect-service-openconnect-helper.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/nm-openconnect-service-openconnect-helper.c
> b/src/nm-openconnect-service-openconnect-helper.c
> index 5256d13..f0f9c17 100644
> --- a/src/nm-openconnect-service-openconnect-helper.c
> +++ b/src/nm-openconnect-service-openconnect-helper.c
> @@ -514,6 +514,11 @@ main (int argc, char *argv[])
> if (val)
> g_variant_builder_add (&ip4builder, "{sv}",
> NM_VPN_PLUGIN_IP4_CONFIG_DOMAIN, val);
>
> + /* Proxy */
> + val = str_to_gvariant (getenv ("CISCO_PROXY_PAC"), TRUE);
> + if (val)
> + g_variant_builder_add (&builder, "{sv}",
> NM_VPN_PLUGIN_CONFIG_PROXY_PAC, val);
> +
> /* MTU */
> tmp = getenv ("INTERNAL_IP4_MTU");
> if (tmp && strlen (tmp)) {
This looks obviously alright.
Acked-by: Lubomir Rintel
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.2.2 released
On Wed, 2016-05-11 at 17:55 +0200, Lubomir Rintel wrote: > Hi, > > The first update to NetworkManager 1.2.x stable series is here. > > The 1.2.2 release includes a couple of bug fixes. The most notable change > is the use of D-Bus API to update the list of name servers when local dnsmasq > is in charge of resolving. Ubuntu has been shipping this patch with > their package for some time already. > > A longer summary of changes can be found here: > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/NEWS?id=nm-1-2 > https://git.gnome.org/browse/network-manager-applet/plain/NEWS?id=nma-1-2 > > You can get the code for NetworkManager, the applet, connection editor and > the VPN plugins here: > > https://download.gnome.org/sources/NetworkManager/1.1/NetworkManager-1.2.2.tar.xz > https://download.gnome.org/sources/network-manager-applet/1.1/network-manager-applet-1.2.2.tar.xz > https://download.gnome.org/sources/NetworkManager-vpnc/1.1/NetworkManager-vpnc-1.2.2.tar.xz > https://download.gnome.org/sources/NetworkManager-openvpn/1.1/NetworkManager-openvpn-1.2.2.tar.xz > https://download.gnome.org/sources/NetworkManager-pptp/1.1/NetworkManager-pptp-1.2.2.tar.xz > https://download.gnome.org/sources/NetworkManager-fortisslvpn/1.1/NetworkManager-fortisslvpn-1.2.2.tar.xz > https://download.gnome.org/sources/NetworkManager-openconnect/1.1/NetworkManager-openconnect-1.2.2.tar.xz > https://download.gnome.org/sources/NetworkManager-libreswan/1.1/NetworkManager-libreswan-1.2.2.tar.xz The links above are incorrect. Sorry for that. The correct addresses are: https://download.gnome.org/sources/NetworkManager/1.2/NetworkManager-1.2.2.tar.xz https://download.gnome.org/sources/network-manager-applet/1.2/network-manager-applet-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.2/NetworkManager-vpnc-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.2/NetworkManager-openvpn-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.2/NetworkManager-pptp-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-fortisslvpn/1.2/NetworkManager-fortisslvpn-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.2/NetworkManager-openconnect-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-libreswan/1.2/NetworkManager-libreswan-1.2.2.tar.xz > This release includes contributions from Anders Jonsson, Balázs Meskó, > Beniamino Galvani, Dan Williams, Francesco Giudici, Gábor Kelemen, > Lubomir Rintel, Mathieu Trudel-Lapierre, Milo Casagrande, Mingye Wang, > Patrick J. Volkerding, Piotr Drąg, Rafael Fontenelle, Thomas Haller, > Wolfgang Stöggl and Zdeněk Hataš. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.2.2 released
Hi, The first update to NetworkManager 1.2.x stable series is here. The 1.2.2 release includes a couple of bug fixes. The most notable change is the use of D-Bus API to update the list of name servers when local dnsmasq is in charge of resolving. Ubuntu has been shipping this patch with their package for some time already. A longer summary of changes can be found here: https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/NEWS?id=nm-1-2 https://git.gnome.org/browse/network-manager-applet/plain/NEWS?id=nma-1-2 You can get the code for NetworkManager, the applet, connection editor and the VPN plugins here: https://download.gnome.org/sources/NetworkManager/1.1/NetworkManager-1.2.2.tar.xz https://download.gnome.org/sources/network-manager-applet/1.1/network-manager-applet-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.1/NetworkManager-vpnc-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.1/NetworkManager-openvpn-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.1/NetworkManager-pptp-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-fortisslvpn/1.1/NetworkManager-fortisslvpn-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.1/NetworkManager-openconnect-1.2.2.tar.xz https://download.gnome.org/sources/NetworkManager-libreswan/1.1/NetworkManager-libreswan-1.2.2.tar.xz This release includes contributions from Anders Jonsson, Balázs Meskó, Beniamino Galvani, Dan Williams, Francesco Giudici, Gábor Kelemen, Lubomir Rintel, Mathieu Trudel-Lapierre, Milo Casagrande, Mingye Wang, Patrick J. Volkerding, Piotr Drąg, Rafael Fontenelle, Thomas Haller, Wolfgang Stöggl and Zdeněk Hataš. Thank you! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Congrats on Xenial Xerus release
Hi, on behalf of the Red Hat's NetworkManager team I'd like to congratulate you all on releasing Xenial Xerus! It seems to me that you'we done an impressive job and judging by responses in the media your users seem to agree. We're especially happy to see that you've included an up-to-date version of NetworkManager. A lot of NetworkManager users, perhaps majority, runs Ubuntu and your choice of the version means that we'll be getting more relevant bug reports (if any! :). That makes me wonder do you have any immediate update plans? Just before the release we've included a couple of fixes that might or might not interest you (with vlan & infiniband support; not sure if you use NM on servers?). Your dnsmasq patch was merged post-release (yay!) and will be included in 1.2.2. Now we should integrate the rest; perhaps the ofono patch. By the way; ModemManager now supports voice calls as well; so perhaps the feature parity with ofono should be better? There's also one unpleasant change; the 1.2.0 versions of the VPN plugins don't use the full paths in their .name files by default (to applease rpmlint or lintian), but that doesn't play well with the version of NM you ship. This will mainly affect people that try to build the 1.2.0 versions of the plugins manually; and can be worked around for packaged versions of the plugins: https://github.com/danfruehauf/NetworkManager-ssh/issues/54 I'm not sure which plugins do you ship (aside from pptp; version of the plugin you ship doesn't have the problem); but the packagers should be aware. Take care! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.2.0 released!
Hi, More than a year after the 1.0 milestone we're thrilled to announce the availability of a new major version: NetworkManager 1.2 is here. This release brings many new features. It improves Wi-Fi and IPv6 privacy, needs less external dependencies, makes VPN support more flexible and adds support for many kinds software devices including IP tunnels, VxLANs and more. As usual, a long summary of changes can be found here: https://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/NEWS?id=nm-1-2 https://git.gnome.org/browse/network-manager-applet/plain/NEWS?id=nma-1-2 We've also put together an article covering the most important changes: https://blogs.gnome.org/lkundrak/2016/04/20/networkmanager-1-2-is-here/ You can get the code here: https://download.gnome.org/sources/NetworkManager/1.2/NetworkManager-1.2.0.tar.xz https://download.gnome.org/sources/network-manager-applet/1.2/network-manager-applet-1.2.0.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.2/NetworkManager-vpnc-1.2.0.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.2/NetworkManager-openvpn-1.2.0.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.2/NetworkManager-pptp-1.2.0.tar.xz https://download.gnome.org/sources/NetworkManager-fortisslvpn/1.2/NetworkManager-fortisslvpn-1.2.0.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.2/NetworkManager-openconnect-1.2.0.tar.xz https://download.gnome.org/sources/NetworkManager-libreswan/1.2/NetworkManager-libreswan-1.2.0.tar.xz This release wouldn't be possible without hard work of many people. NetworkManager 1.2 was brought to you by: Rafael Fontenelle, Aleksander Morgado, Mario Blättermann, Pedro Albuquerque, Dan Winship, Balázs Úr, Milo Casagrande, Rafael Fontenelle, Jordi Mas, Aurimas Černius, Gábor Kelemen, David Woodhouse, Мирослав Николић, Anders Jonsson, Adam Bk, Adrian Likins, Ankit Patel, Anthony Bourguignon, atul, Balázs Meskó, Bastien Nocera, Bernd Edlinger, Bernd Homuth, Bin Li, Boris HUISGEN, Carles Ferrando Garcia, Carlos Alberto Lopez Perez, chrysn, Dan Horák, David Shea, David Ward, Dušan Kazik, Eric Koegel, Ethirajan D, Frédéric Péters, Guido Günther, GunChleoc, Hedda Peters, Jan Alexander Steffens (heftig), Jan Tojnar, Jordi Mas, Josef Bacik, Luke Yelavich, Marvin Schmidt, Mathieu Trudel-Lapierre, Matias Wilkman, Matthias Berndt, Michael Scherer, Mikko Rapeli, Muhammet Kara, Nikolay Martynov, Richard Hughes, Rui Matos, Shantha kumar, Srdjan Grubor, Stjepan Gros, Tom Tryfonidis, Tore Anderson, Walter Garcia-Fontes, You-Sheng Yang, Γιάννης Κουτσούκος, Thomas Haller, Daniel Mustieles, Zdeněk Hataš, Dan Williams, Pavel Šimerda, Baurzhan Muftakhidinov, Colin Walters, Hannie Dumoleyn, Jiri Grönroos, Josef Andersson, Kjartan Maraas, Martin Pitt, Mikhail Efremov, Pablo Castellano, Quentin Glidic, Robby Workman, Stas Solovey, Beniamino Galvani, Christopher Guarneros Díaz, Francesco Giudici, Glenn Washburn, Ignacio Acevedo Carrera, Jiri Grönroos, Jiří Klimeš, Joel Holdsworth, Matej Urbančič, Petr Vorel, Rafael Ferreira, Wolfgang Stöggl, Марко М. Костић, Jiří Klimeš, Christian Kirbach, Matthias Berndt, Tom Tryfonidis, Cédric Valmary, Christian Kirbach, Federico Mena Quintero, Inaki Larranaga Murgoitio, Mathieu Trudel-Lapierre, Sveinn í Felli, Dan Winship, Samir Ribic, Yuri Chornoivan, Marek Černocký, Lubomir Rintel, Josef Andersson, Necdet Yücel, Piotr Drąg and Michael Biebl. Thanks to everyone who contributed or sent feedback! ❤, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-pppd-plugin: fix crash
On Wed, 2016-04-13 at 22:53 +0200, Thomas Haller wrote:
> On Wed, 2016-04-13 at 21:43 +0300, Mikhail Efremov wrote:
> >
> > A bus name is not an object path.
> > Fix crash introduced by commit
> > 17ae85788987ef1f7c92a251c535312163144c33.
> > ---
> > src/nm-pptp-pppd-plugin.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/nm-pptp-pppd-plugin.c b/src/nm-pptp-pppd-plugin.c
> > index 2b8c819..4567fcc 100644
> > --- a/src/nm-pptp-pppd-plugin.c
> > +++ b/src/nm-pptp-pppd-plugin.c
> > @@ -318,8 +318,8 @@ plugin_init (void)
> > proxy = g_dbus_proxy_new_sync (bus,
> > G_DBUS_PROXY_FLAGS_DO_NOT_L
> > OA
> > D_PROPERTIES,
> > NULL,
> > - NM_DBUS_SERVICE_PPTP_PPP,
> > bus_name,
> > + NM_DBUS_PATH_PPTP_PPP,
> > NM_DBUS_INTERFACE_PPTP_PPP,
> > NULL, &err);
> > g_object_unref (bus);
>
Thank you, applied.
> Hi Mikhail,
>
>
>
> Thank you. A few lines before there is also:
>
> bus_name = getenv ("NM_DBUS_SERVICE_PPTP");
> if (!bus_name)
> bus_name = NM_DBUS_SERVICE_PPTP;
>
>
> thus, this should be changed too.
That one looks correct to me?
>
>
> [[ I leave this to Lubomir (CC'ed) ]]
>
>
> Thomas
Lubo
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.1.94 (1.2-rc2) released -- some links broken
On Tue, 2016-04-12 at 08:42 -0500, Alex Ferm wrote: > I was poking around the liked > documentation(https://developer.gnome.org/NetworkManager/), and all > links to enumeration values appear to be broken. Yes, thanks for the heads up. We'll try to get this fixed before the 1.2 release. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.1.93 (1.2-rc1) released
Hi, Today we've reached the point where our 1.2 blocker list is empty, the testing all green and we believe the tree is ready for a release. Yay! Since the last beta, we've fixed interaction with externally created devices and also included a couple of smaller improvements. We've made some cosmetic changes to the manual and imported new translation. The API and ABI are frozen and won't change before 1.2. Please test this release. Tell your friends to test. Ask your foes to test. If you're a distribution maintainer and haven't imported the betas, this is the right time to update your testing package. This is possibly the last call for testing and suggestions before we do a 1.2 release. As usual, a summary of changes can be found here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/NEWS https://git.gnome.org/browse/network-manager-applet/plain/NEWS You can get the code here: https://download.gnome.org/sources/NetworkManager/1.1/NetworkManager-1.1.93.tar.xz https://download.gnome.org/sources/network-manager-applet/1.1/network-manager-applet-1.1.93.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.1/NetworkManager-vpnc-1.1.93.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.1/NetworkManager-openvpn-1.1.93.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.1/NetworkManager-pptp-1.1.93.tar.xz https://download.gnome.org/sources/NetworkManager-fortisslvpn/1.1/NetworkManager-fortisslvpn-1.1.93.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.1/NetworkManager-openconnect-1.1.93.tar.xz https://download.gnome.org/sources/NetworkManager-libreswan/1.1/NetworkManager-libreswan-1.1.93.tar.xz Thanks to everyone who contributed or sent feedback! ❤, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.0.12 released
Hi, While we're busy stabilizing the 1.2.x tree for a release candidate a plenty of fixes accumulated in the 1.0.x tree. Looks like it's about the time we do a NetworkManager 1.0.12 release, which I'm pleased to announce. As usual, we recommend that users of 1.0.x series as well as users of older 0.9.10.x series upgrade to this release which is D-Bus and C API backwards compatible. If you're using a distribution that ships NetworkManager 1.0.x, chances are you'll get the new version when the distributor tests it. This release doesn't introduce any new features. It brings a few interoperability improvements, fixes for a few fairly unlikely crashes, backports of some memory leak fixes we've discovered while testing the 1.2 betas and a fix for low severity race condition that could leak to a local information leak. A more detailed overview is available in the NEWS file: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=1.0.12 You can grab the new version here: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager-1.0.12.tar.xz We're not releasing new versions of the applet or VPN plugins; there's nothing interesting in their respective 1.0.x branches now (as opposed to the 1.2.x release that's going to bring significant improvements). We're keeping our interfaces stable, so the older versions will keep working. This release is brought to you by: Beniamino Galvani, Dan Williams, Dan Winship, Francesco Giudici, Lubomir Rintel, Matthew Millar, Michael Biebl, Nikolay Martynov, and Thomas Haller. Special thanks to everybody that reported bugs and tested this release! PS: Thanks to everyone who participated in the survey. There's almost 1500 responses and we take care to pay attention to each one, so it may take some time until we respond. We're working on that! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.1.91 (1.2-beta3) released
Hello, I'm pleased to announce the release of the third beta version of NetworkManager 1.2 (1.1.92), and the same version of nm-applet, nm-connection-editor and VPN plugins. Compared to previous beta release we've ironed a couple of wrinkles. Notably a long standing issue with missing ability to verify 802.1x subject was addressed (the has a CVE number of CVE-2006-7246 associated as it has security implications). For the old-fashioned users we've now restored the option to avoid using a symlink to manage /etc/resolv.conf. We've improved the behavior with VLANs on software devices (bonds, bridges...) and included some fixes that improve cross-version compatibility with older clients. We now consider the code base quite stable, so this is the last "beta" release. A release candidate will follow in a week or so. A summary of changes since 1.0 can be found here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/NEWS https://git.gnome.org/browse/network-manager-applet/plain/NEWS You can get the code at the usual locations: https://download.gnome.org/sources/NetworkManager/1.1/NetworkManager-1.1.92.tar.xz https://download.gnome.org/sources/network-manager-applet/1.1/network-manager-applet-1.1.92.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.1/NetworkManager-vpnc-1.1.92.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.1/NetworkManager-openvpn-1.1.92.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.1/NetworkManager-pptp-1.1.92.tar.xz https://download.gnome.org/sources/NetworkManager-fortisslvpn/1.1/NetworkManager-fortisslvpn-1.1.92.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.1/NetworkManager-openconnect-1.1.92.tar.xz https://download.gnome.org/sources/NetworkManager-libreswan/1.1/NetworkManager-libreswan-1.1.92.tar.xz Thanks to everyone who contributed or sent feedback! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
The usage survey
Hi, we've created a short survey with a couple of NetworkManager-related questions. It helps us understand how do you use NetworkManager, what bothers you, and what should we improve. If interested, you can submit the answers here: http://goo.gl/forms/ZpnA2YV4O1 Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
nm-1-2 blocker cleanup
Hi, with the 1.2 release approaching, we need to decide on which bugs set for 1.2 milestone need to block the release. No new features should remain in the list, only things that absolutely need to be fixed before the release such as regressions. I propose that these should be retargetted for nm-1.4: 683206: maximize device availability (IFF_UP/IFF_LOWER_UP) for IPv6 link-local communication during runtime and after exit 699843: leave interface configuration when removing from NM management 708829: dnssec: support per-connection DNSSEC options for local zones 699810: dns: support for unbound with split DNS and DNSSEC 746440: improve behavior for assumed and unmanaged devices, do better at seamless take over, and don't touch devices 760907: fix handling of invalid connections in libnm/libnm-glib And I think these should remain blocking 1.2: 697370: live reconfiguration of NMDevices 736406: NetworkManager.service should use KillMode=mixed 740574: support appindicator based systrays (found in Unity, KDE, Enlightenment and more) 740739: cannot activate shared connection on physically disconnected ethernet 748302: [review] lr/cli-add-master: Make it possible to specify master connection/device for any connection profile 760998: resync with systemd upstream code before 1.2 761389: don't mess with interface handled by clatd 762322: reapply does not restore IP configuration 762331: revert behavioral change for NM_UNMANAGED_USER_CONFIG being overwritable by USER_EXPLICIT 762333: ensure autoconnection does not make a device !NM_UNMANAGED_USER_EXPLICT 341323: [ENH] Verify subject of remote certificate [See dependency tree for bug 341323] This is of course not a definitive selection; I'm just asking for your input at this point. Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Translations in Zanata
Hello poma, On Thu, 2016-02-04 at 15:54 +0100, poma wrote: > On 04.02.2016 15:24, Lubomir Rintel wrote: > > Hi, > > > > the NetworkManager is now translated via Zanata [1]. This means the > > translators no longer need to file Bugzilla tickets with > > translations. > > Details here [2]. > > > > The bits that are in GNOME infrastructure (applet and the VPN > > plugins) > > stay there; only the NetworkManager core was added to Zanata. We're > > not > > sure if it makes sense to move to Zanata; input from translators > > would > > be very appreciated. > > > > [1] https://fedora.zanata.org/project/view/NetworkManager > > [2] https://wiki.gnome.org/Projects/NetworkManager/L10N > > > > Thank you, > > Lubo > > > > > https://fedora.zanata.org > "This service uses Fedora account, so if you do not have a Fedora > account already, please go to Fedora Account System to apply for one. > ..." > > OpenID? > > "OpenID is an open standard and decentralized authentication > protocol." > https://en.wikipedia.org/wiki/OpenID Hmm, seems like we should perhaps have used translate.zanata.org. That one supports OpenID. I'm a bit confused about how do the two instances compare. I'll try to figure out what's a better choice for the project. > > Thank you Lubo. > > Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Translations in Zanata
Hi, the NetworkManager is now translated via Zanata [1]. This means the translators no longer need to file Bugzilla tickets with translations. Details here [2]. The bits that are in GNOME infrastructure (applet and the VPN plugins) stay there; only the NetworkManager core was added to Zanata. We're not sure if it makes sense to move to Zanata; input from translators would be very appreciated. [1] https://fedora.zanata.org/project/view/NetworkManager [2] https://wiki.gnome.org/Projects/NetworkManager/L10N Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager temporary file races (CVE-2016-0764)
Hi, today we've discovered and fixed a temporary file race flaw that could enable an unprivileged authenticated local user to read out connection secrets (e.g. a VPN or Wi-Fi password) while the connection is being saved. It's fairly unlikely for this to happen as there's no way to force another user to save their connection. The problem affects all supported NetworkManager releases (and unsupported ones, as it dates way back to before 0.7.x series). The fix will be included in the next NetworkManager release (not schedule yet and no hurry either given the fairly low severity). Just in case anyone would wish to backport the fixes, it's these commits: master: 60b7ed3bdc3941a3b7c56824fba4b7291e79041f [1] 1.0.x: 38ad5c9f3ace1e5578727c9de74b45346ea0a00e [2] [1] http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?i d=60b7ed3bdc3941a3b7c56824fba4b7291e79041f [2] http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h =nm-1-0&id=38ad5c9f3ace1e5578727c9de74b45346ea0a00e Take care! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Revert "Install a desktop file for nm-vpnc-auth-dialog"
On Fri, 2016-01-22 at 00:55 +0100, Michael Biebl wrote: > Am 22.01.2016 um 00:36 schrieb Michael Biebl: > > The desktop file was added a long time ago, when we didn't have > > native > > gnome-shell dialogs yet. This is no longer the case and the vpnc > > plugin > > uses supports-external-ui-mode=true nowadays. So drop the desktop > > file > > again. > > Dan rightfully pointed out, that we need to update po/ accordingly. > See the attached follow up commit. Thanks, applied. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.1.90 (1.2-beta1) released
Hi, I'm pleased to announce the release of NetworkManager 1.1.90 (1.2-beta1) and the same version of nm-applet, nm-connection-editor and the VPN plugins. This is a first pre-release version of the next NetworkManager version, 1.2. It's been in development for over a year now and contains fair amount of new features, bug fixes and also some extensive internal changes. There will be at least one pre-release before we'll do a 1.2 stable release. At this point the code is feature complete and the essential functionality has been tested to work well. That said, there's a lot of testing to be done before we can do a stable release. We need your help with that! While it's not recommended to run the pre-release in production, we encourage you to test the new release and report any issues you encounter. If you are a maintainer of a Linux distribution or a tool that utilizes NetworkManager, you're even more encouraged to try the pre-release. NetworkManager 1.2 will be API and ABI compatible with NetworkManager 1.0.x, series (with the exception of the editor that won't load old VPN plugins due to a symbol clash between libnm and legacy libnm-gtk). A fairly complete summary of changes is available here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/plain/NEWS https://git.gnome.org/browse/network-manager-applet/plain/NEWS You can get the code here: https://download.gnome.org/sources/NetworkManager/1.1/NetworkManager-1.1.90.tar.xz https://download.gnome.org/sources/network-manager-applet/1.1/network-manager-applet-1.1.90.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.1/NetworkManager-vpnc-1.1.90.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.1/NetworkManager-openvpn-1.1.90.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.1/NetworkManager-pptp-1.1.90.tar.xz https://download.gnome.org/sources/NetworkManager-fortisslvpn/1.1/NetworkManager-fortisslvpn-1.1.90.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.1/NetworkManager-openconnect-1.1.90.tar.xz Thanks to everyone who contributed to the development of NetworkManager 1.2 and especially those who send the bug reports. We need your help to make NetworkManager 1.2 the best and most robust NetworkManager release ever! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.0.10 released
Hi, I'm pleased to announce the release of NetworkManager 1.0.10, the latest stable release in the 1.0.x series. As usual, we recommend that users of 1.0.x series as well as users of older 0.9.10.x series upgrade to this release which is D-Bus and C API backwards compatible. This is probably the last NetworkManager release in 2015 and maybe even last of the 1.0.x series before the next major version. We've done five releases with 1280 commits this year and almost twice as many commits to the 1.2 branch soon to be released. Let me take this opportunity to thank everyone who improved NetworkManager, wrote code, contributed bug reports, fixed bugs and added translations. Your work is what makes countless Linux systems connect to networks flawlessly; something that's perhaps not appreciated enough unless it stops working. Thank you! The 1.0.10 includes a couple of bug fixes, adds support for handling VPN secrets into nmcli and nmtui and makes it easier to create Bluetooth connections for the users of nm-connection-editor. An overview of the changes in 1.0.10 is here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=1.0.10 Grab NetworkManager and the applet/editor here: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager-1.0.10.tar.xz https://download.gnome.org/sources/network-manager-applet/1.0/network-manager-applet-1.0.10.tar.xz We're not releasing the new versions of VPN plugins this time. The VPN plugins for older versions of NetworkManager remain compatible with NetworkManager 1.0.10. You're encouraged to run version 1.0.8 of the plugins. This release was made possible by everyone who reported bugs, tested it and those who contributed code and translations: Anders Jonsson, Beniamino Galvani, Dan Williams, Fran Diéguez, Glenn Washburn, Gustavo Marques, Jiri Grönroos, Jiří Klimeš, Lubomir Rintel, Marek Černocký, Milo Casagrande, Piotr Drąg, Rafael Fontenelle, Sveinn í Felli, Thomas Haller and Zdeněk Hataš. Have a wonderful year 2015! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 2/2] Added OpenSSL crypto backend
On Tue, 2015-11-24 at 16:01 +0100, Jirka Klimes wrote: > On Thu, 19 Nov 2015 15:30:46 +0100 > Lubomir Rintel wrote: > > > Hi Joel, > > > > thanks for the patch but I don't think it makes sense to apply it. > > > > I think distributing NetworkManager linked with OpenSSL would be a > > violation of NetworkManager's license (since the OpenSSL license > > adds > > an extra restriction, something that is not allowed by General > > Public > > License). > > > > Maybe, LibreSSL could be used instead. > http://www.libressl.org/ > https://en.wikipedia.org/wiki/LibreSSL No. That's essentially just OpenSSL and thus covered by the very same license. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.0.8 released
Hi, I'm pleased to announce the release of NetworkManager 1.0.8, the latest stable release in the 1.0.x series. We recommend that users of 1.0.x series as well as users of older 0.9.10.x series upgrade to this release which is D-Bus and C API backwards compatible. As the 1.0.x series matures, the development focuses more on enhancing robustness and fixing bugs but there's a few new features. A more exhaustive list of changes in the new release is can be found here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=1.0.8 Grab NetworkManager, the applet/editor, and the VPN plugins here: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager-1.0.8.tar.xz https://download.gnome.org/sources/network-manager-applet/1.0/network-manager-applet-1.0.8.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.0/NetworkManager-vpnc-1.0.8.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.0/NetworkManager-openvpn-1.0.8.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.0/NetworkManager-pptp-1.0.8.tar.xz https://download.gnome.org/sources/NetworkManager-fortisslvpn/1.0/NetworkManager-fortisslvpn-1.0.8.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.0/NetworkManager-openconnect-1.0.8.tar.xz Thanks go to everyone involved in adding features, fixing and reporting bugs and improving the translations. We value your contributions very much! NetworkManager 1.0.8 is brought to you by: Adam Bk, Anders Jonsson, Andika Triwidada, Aurimas Černius, Balázs Meskó, Balázs Úr, Beniamino Galvani, Bernd Homuth, Bin Li, Christian Kirbach, Dan Williams, Felipe Braga, Gábor Kelemen, Glenn Washburn, Jiri Grönroos, Jiří Klimeš, Josef Bacik, Lubomir Rintel, Marvin Schmidt, Michael Biebl, Milo Casagrande, Pedro Albuquerque, Piotr Drąg, Quentin Glidic, Rafael Fontenelle, Stas Solovey, Thomas Haller, Ulrich Ölmann, Wolfgang Stöggl and Zdeněk Hataš. Have fun! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 2/2] Added OpenSSL crypto backend
Hi Joel, thanks for the patch but I don't think it makes sense to apply it. I think distributing NetworkManager linked with OpenSSL would be a violation of NetworkManager's license (since the OpenSSL license adds an extra restriction, something that is not allowed by General Public License). Please refer to the following link for more details and discussion on the topic: https://people.gnome.org/~markmc/openssl-and-the-gpl.html We do already have two crypto backends whose license doesn't clash with our licensing, I suggest you just use those if possible. Sorry for that. Lubo On Thu, 2015-11-19 at 00:01 +, Joel Holdsworth wrote: > --- > configure.ac| 16 ++- > libnm-core/Makefile.am | 6 + > libnm-core/crypto_openssl.c | 324 > > po/POTFILES.in | 1 + > 4 files changed, 340 insertions(+), 7 deletions(-) > create mode 100644 libnm-core/crypto_openssl.c > > diff --git a/configure.ac b/configure.ac > index 7b4ca9a..83ae5a0 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -594,10 +594,12 @@ else > fi > AC_SUBST(NM_MODIFY_SYSTEM_POLICY) > > -AC_ARG_WITH(crypto, AS_HELP_STRING([--with-crypto=nss|gnutls], > [Cryptography library to use for certificate and key > operations]),ac_crypto=$withval, ac_crypto=nss) > +AC_ARG_WITH(crypto, AS_HELP_STRING([--with- > crypto=nss|gnutls|openssl], > + [Cryptography library to use for certificate and key > operations]), ac_crypto=$withval, ac_crypto=nss) > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] vpn-connection: lack of ipv4 config in remote VPN is not fatal
On Thu, 2015-11-05 at 12:44 +0100, Rafaël Carré wrote: > Hello, > > On 05/11/2015 12:31, Lubomir Rintel wrote: > > Thanks for the patch, Rafaël. > > > > I'm not sure it's correct, though. The VPN plugin probably should > > probably only emit "Config" signal and not "IP4Config" when it has > > no > > IPv4 configuration. > > You tell me :) I've committed a slightly modified version of the patch to the NM- openvpn master. I'm wondering if you could try it out and see if it works for you? What configuration are you using the openvpn plugin in? A IPv6-only setup? Thanks, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Slightly [OT]: is NM supported in HA setups (pacemaker) in RHEL 7
Hi, On Sat, 2015-11-07 at 21:47 +0800, Anthony Alba wrote: > In RHEL 6, HA setups with pacemaker require disabling NetworkManager > (documented). > > For RHEL 7 / CentOS 7 is this still the case; I could find no > information about using NM or /etc/init.d/network. I'm not aware of any problems NetworkManager could cause. We'd consider them a bug. You may want to double-check with pacemaker upstream. If they still recommend disabling NetworkManager we'd like to hear & fix. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] openvpn: lack of ipv4 config on tap interface is not fatal
Hello Rafaël,
I'm not sure I understand this one either. What do you mean it's fatal
now? There's just a g_warning(). Is it that without your other patch
this produces invalid IPv4 config and causes the daemon to tear the
down the connection?
On Tue, 2015-11-03 at 19:31 +0100, Rafaël Carré wrote:
> IPv4 config can be set manually
> ---
> src/nm-openvpn-service-openvpn-helper.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/src/nm-openvpn-service-openvpn-helper.c b/src/nm-
> openvpn-service-openvpn-helper.c
> index 512d6ce..4f93193 100644
> --- a/src/nm-openvpn-service-openvpn-helper.c
> +++ b/src/nm-openvpn-service-openvpn-helper.c
> @@ -583,13 +583,10 @@ main (int argc, char *argv[])
> if (tmp && inet_pton (AF_INET, tmp, &temp_addr) > 0) {
> val = g_variant_new_uint32
> (nm_utils_ip4_netmask_to_prefix (temp_addr.s_addr));
> g_variant_builder_add (&ip4builder, "{sv}",
> NM_VPN_PLUGIN_IP4_CONFIG_PREFIX, val);
> - } else if (!tapdev) {
> - if (!has_ip4_prefix) {
> - val = g_variant_new_uint32 (32);
> - g_variant_builder_add (&ip4builder, "{sv}",
> NM_VPN_PLUGIN_IP4_CONFIG_PREFIX, val);
> - }
> - } else
> - g_warning ("No IP4 netmask/prefix (missing or
> invalid 'ifconfig_netmask')");
> + } else if (!has_ip4_prefix) {
> + val = g_variant_new_uint32 (32);
> + g_variant_builder_add (&ip4builder, "{sv}",
> NM_VPN_PLUGIN_IP4_CONFIG_PREFIX, val);
> + }
>
> val = get_ip4_routes ();
> if (val)
Thanks,
Lubo
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] vpn-connection: lack of ipv4 config in remote VPN is not fatal
Thanks for the patch, Rafaël.
I'm not sure it's correct, though. The VPN plugin probably should
probably only emit "Config" signal and not "IP4Config" when it has no
IPv4 configuration.
On Tue, 2015-11-03 at 19:31 +0100, Rafaël Carré wrote:
> IPv4 config can be set manually
> ---
> src/vpn-manager/nm-vpn-connection.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/src/vpn-manager/nm-vpn-connection.c b/src/vpn-
> manager/nm-vpn-connection.c
> index 0c0ac1c..fc49304 100644
> --- a/src/vpn-manager/nm-vpn-connection.c
> +++ b/src/vpn-manager/nm-vpn-connection.c
> @@ -1419,10 +1419,7 @@ nm_vpn_connection_ip4_config_get
> (NMVpnConnection *self, GVariant *dict)
> address.source = NM_IP_CONFIG_SOURCE_VPN;
> nm_ip4_config_add_address (config, &address);
> } else {
> - _LOGE ("invalid IP4 config received!");
> - g_object_unref (config);
> - nm_vpn_connection_config_maybe_complete (self,
> FALSE);
> - return;
> + _LOGW ("invalid IP4 config received!");
> }
>
> if (g_variant_lookup (dict, NM_VPN_PLUGIN_IP4_CONFIG_DNS,
> "au", &iter)) {
Lubo
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager-libreswan to replace NetworkManager-openswan
Hello everyone! For 1.2 series we're renaming NetworkManager-openswan VPN plugin to NetworkManager-libreswan. It seems that the user community has shifted its focus to libreswan for new deployments therefore we decided to rename the plugin to avoid confusion. Currently the plugin supports both libreswan and openswan as there are very few differences between the two when it comes to interfacing with the plugin. However, with openswan having been dropped from major Linux distributions (Fedora and Debian most prominently) it's getting more difficult for us to ensure that openswan remains well supported. NetworkManager-libreswan will remain be compatible with existing NetworkManager-openswan connections and the transition should be smooth. We'll release first version of NetworkManager-libreswan together with the release of NetworkManager 1.2. We're committed to maintain NetworkManager-openswan as long as NetworkManager 1.0 stable branch is maintained. Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Approaching NetworkManager 1.2
Hello everyone, It's been some time since the work on NetworkManager 1.2 has begun. A lot of what's been planed has been implemented and we believe we should wrap up the work and do a major release. The wiki page with 1.2 feature page has been updated with the features we're like to see in the release (most of it already implemented): https://wiki.gnome.org/Projects/NetworkManager/12FeaturesPlanning If anyone believes anything important is missing it's a good time to speak up now. Since the new release will bring significant changes, we'll be doing a beta release (likely towards the end of this year) once the new APIs are settled. When the remaining work that won't involve interface changes is done we'll do a release candidate and repeat that until the wrinkles are ironed out and the feedback is sufficiently good. Thanks, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager and netns
Hi, On Wed, 2015-09-30 at 10:42 +0200, Guy Godfroy wrote: > Hello, > > My idea is to allow regular users to establish VPN tunnels on > specific > network namespaces (netns) via nscli command. > So I wonder if network-manager can handle several namespaces and how. No. We should probably have a proper netns one day, but we're not there yet. > If not, a solution would be to launch one network-manager instance > per > netns. But I don't know how to tell to nmcli which instance of > network-manager to refer to. If a system dbus is available, NetworkManager acquires a name on a system bus and nmcli uses the system bus to talk to it. If there's no system bus a private socket is used. For your namespaced NetworkManager instances you probably want to go with the second option. Therefore, in addition to net ns you need to create a separate mount ns and mount a private /run instance. That would shadow the system-wide dbus socket and NM will use its private socket there. Then just run nmcli in the same mount namespace as the daemon. > > Is there a better solution? > Thanks for your attention. > > Guy Godfroy Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: New VPN plugin: NetworkManager-fortisslvpn 1.0.6
Hi, there's a new VPN plugin that aims to be compatible with "SSL VPN" as by various FortiOS-based devices. It uses openfortivpn on the backend. It's versioned 1.0.6 so that it's aligned with the other VPN plugins. You can grab the source from here: https://download.gnome.org/sources/NetworkManager-fortisslvpn/1.0/NetworkManager-fortisslvpn-1.0.6.tar.xz Note: To use all features provided by the plugin you'll need the most recent Git snapshot of openfortivpn. The new release of openfortivpn the distribution packagers could use is expected shortly (in a day or two). Thanks to Aurimas Černius and Piotr Drąg for contributing the translations, to Michal Ingeli for diligent testing with an actual Fortigate hardware, and to Adrien Vergé who did most of the work on the openfortivpn backend. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager and PKCS#11 URIs
Hi, I was considering implementing this: https://wiki.gnome.org/Projects/NetworkManager/PKCS11 The URIs of the certificates stored in the gnome-keyring's soft token storage are specific to the session and it doesn't seem to be possible or wise to use them from the NetworkManager (or wpa_supplicant of the VPN helpers). How would we deal with those? Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM and IETF MIF working group
Hello Stjepan, On Mon, 2015-09-07 at 12:05 +0200, Stjepan Groš wrote: > Hi All! > > Two colleagues of mine and I started to work on MIF implementation on > Fedora. In case someone doesn't know, IETF MIF working group > (https://datatracker.ietf.org/wg/mif/charter/) tries to solve the > problems of a single node having multiple parallel connections to > different destinations (Internet, VPN, some private networks, etc.). Thanks for the pointer, we'll definitely take a look. > For > example, probably it happened to you, as it did to me, that after > connecting to VPN all my existing connections were terminated and also > VPN allowed me to access only a restricted set of destinations meaning > that I wasn't able to use Internet while the VPN was active. I hope that > the work on MIF will solve this issue, as well as many others. This was possibly because a default route changed to the gateway obtained from the VPN gateway. It can be overriden with "ipv6.never -default" and "ipv4.never-default" properties (can be set in nm -connection-editor by clicking the "Routes" button and selecting "Use this connection only for resources on this network"). > So, it seems to me that the NetworkManager is the core component on the > client side that will have to have functionality specified by MIF > allowing node to use multiple connections in parallel (this, of course, > doesn't mean that it is the only component that will have to be > changed). But since we are at the very beginning of this, we would like > to hear thoughts from developers about this? Did anyone tried to do > this? Give any thought to this and come out with a possible solution, or > problems? We do essentially deal with this to some extent by setting metrics to the routes we set up. We assign priorities to different device types so that e.g. Wired Ethernet is preferred over Wi-Fi or Mobile Broadband. We do also remember order in which routes were added so that newly activated connections on multi-homed hosts don't "steal" the existing connections. That said, I haven't really had a look (maybe someone else from the team had?) at the documents you're created and discussed so far so my understanding of the problem scope might be limited. > > Best regards, > Stjepan Groš Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.0.6 released
Hi, I'm pleased to announce the release of NetworkManager 1.0.6, the latest stable release in the 1.0.x series. We recommend that users of 1.0.x series as well as users of older 0.9.10.x series upgrade to this release which is D-Bus and C API backwards compatible. The 1.0.4 release adds a couple of new features with the usual number of bug fixes and stability improvements. An overview of the changes in 1.0.6 is here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=1.0.6 Grab NetworkManager, the applet/editor, and the VPN plugins here: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager-1.0.6.tar.xz https://download.gnome.org/sources/network-manager-applet/1.0/network-manager-applet-1.0.6.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.0/NetworkManager-vpnc-1.0.6.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.0/NetworkManager-openvpn-1.0.6.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.0/NetworkManager-pptp-1.0.6.tar.xz There's no new release for NetworkManager-openconnect as there were no changes. Users of NetworkManager-openconnect can use the latest stable version 1.0.2: https://download.gnome.org/sources/NetworkManager-openconnect/1.0/NetworkManager-openconnect-1.0.2.tar.xz Thanks to everybody who contributed patches and translations: Balázs Úr, Beniamino Galvani, Cédric Valmary, Dan Horák, Dan Williams, Dan Winship, David Shea, Ethirajan D, Jiří Klimeš, Lubomir Rintel, Marek Černocký, Mathieu Trudel-Lapierre, Piotr Drąg, Quentin Glidic, Stas Solovey, Thomas Haller, Tore Anderson, Zdeněk Hataš Special thanks to everybody that reported bugs and tested this release! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Dbus API License
Hi, On Thu, 2015-08-20 at 12:15 +0500, Ali Muhammad Ali wrote: > Hello All, > I am working on a network manager frontend that will > use > network manager dbus api. Is there any license binding by network > manager > on dbus api . I other words I need to know that can I keep the source > of my > frontend closed and distribute only the binaries ? NetworkManager is licensed under the terms of GPLv2 or (at your option) any later version. This license applies as long as you're distributing derived work from the NetworkManager source. Please make sure you read and understand the license: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/COPYING That is, if you distribute binaries that are built from a source tree that contains code taken from NetworkManager then you need to distribute the full source code with your binaries. If you're merely dynamically linking to libnm or just doing DBus calls from your own code (sounds like this is what you're doing), then no restrictions apply and you don't need to distribute your source code. > Regards, > Muhammad Ali Cheers, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: F23 NetworkManager Test Day August 20th!
On Wed, 2015-08-19 at 11:14 +0200, poma wrote: > On 18.08.2015 15:24, Lubomir Rintel wrote: > > On Sun, 2015-08-16 at 09:54 +0200, poma wrote: > > ... > > > Fedora 23 - mobile broadband components versions: > > > - ModemManager-1.4.6-2.fc23.x86_64 > > > - libqmi-1.12.4-3.fc23.x86_64 > > > - libmbim-1.12.0-2.fc23.x86_64 > > > - usb_modeswitch-2.2.1-2.fc23.x86_64 > > > - usb_modeswitch-data-20150115-2.fc23.noarch > > > > > > It should be: > > > - ModemManager-1.4.10-1.fc2x.x86_64 > > > - libqmi-1.12.6-1.fc2x.x86_64 > > > - libmbim-1.12.2-1.fc2x.x86_64 > > > - usb_modeswitch-2.2.5-1.fc2x.x86_64 > > > - usb_modeswitch-data-20150627-1.fc2x.noarch > > > > > > > > > You intend to test with outdated versions? > > > > Thanks for the heads up; will do the updates right away & set up > > release monitoring. > > > > See you on the test day, hopefully! > > > > Lubo > > > > > As I am concerned, by the way thanks for the call, I test a lot of > things on a daily basis, > and given that I'm driving the above-mentioned current versions of > components for quite a long time, > this "Test Day" has been done already. That's great. I'm wondering if you could describe what you have tested in the wiki, so that we know which areas did you cover? Thank you. > Besides > https://fedoraproject.org/wiki/Test_Day:2015-08-20_NetworkManager#Liv > e_image > "... Live images can be found here." > http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ > Not Found Fixed. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: F23 NetworkManager Test Day August 20th!
On Sun, 2015-08-16 at 09:54 +0200, poma wrote: ... > Fedora 23 - mobile broadband components versions: > - ModemManager-1.4.6-2.fc23.x86_64 > - libqmi-1.12.4-3.fc23.x86_64 > - libmbim-1.12.0-2.fc23.x86_64 > - usb_modeswitch-2.2.1-2.fc23.x86_64 > - usb_modeswitch-data-20150115-2.fc23.noarch > > It should be: > - ModemManager-1.4.10-1.fc2x.x86_64 > - libqmi-1.12.6-1.fc2x.x86_64 > - libmbim-1.12.2-1.fc2x.x86_64 > - usb_modeswitch-2.2.5-1.fc2x.x86_64 > - usb_modeswitch-data-20150627-1.fc2x.noarch > > > You intend to test with outdated versions? Thanks for the heads up; will do the updates right away & set up release monitoring. See you on the test day, hopefully! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] device: prefer wifi over wwan by default
On Tue, 2015-07-21 at 11:37 +0200, Tore Anderson wrote: > This makes wifi preferred to wwan (the modem and bluetooth device > types > to be specific) by default, so that users that care about being > connected at all times can keep both enabled with auto-connect. As > wifi > is usually unmetered and often faster than wwan, it makes sense to > prefer it. This is also how pretty much every smart-phone in the > world > behaves, so it aligns better with user expectations too. > > https://bugzilla.gnome.org/show_bug.cgi?id=744754 > --- > src/devices/nm-device.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c > index eba15a3..332182a 100644 > --- a/src/devices/nm-device.c > +++ b/src/devices/nm-device.c > @@ -721,14 +721,14 @@ nm_device_get_priority (NMDevice *self) > return 400; > case NM_DEVICE_TYPE_BRIDGE: > return 425; > - case NM_DEVICE_TYPE_MODEM: > - return 450; > - case NM_DEVICE_TYPE_BT: > - return 550; > case NM_DEVICE_TYPE_WIFI: > return 600; > case NM_DEVICE_TYPE_OLPC_MESH: > return 650; > + case NM_DEVICE_TYPE_MODEM: > + return 700; > + case NM_DEVICE_TYPE_BT: > + return 750; > case NM_DEVICE_TYPE_GENERIC: > return 950; > case NM_DEVICE_TYPE_UNKNOWN: Thank you. Applied to master & 1.0 stable branch. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] device: restart the DHCP transaction when the carrier goes up during the defer period
This makes NetworkManager recover on brief carrier toggle following a DHCP outage. NetworkManager[1106]: (eth0): link connected NetworkManager[1106]: (eth0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40] NetworkManager[1106]: Auto-activating connection 'Wired connection 1'. NetworkManager[1106]: Activation (eth0) starting connection 'Wired connection 1' NetworkManager[1106]: Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager[1106]: Activation (eth0) Stage 1 of 5 (Device Prepare) started... NetworkManager[1106]: (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0] NetworkManager[1106]: Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... NetworkManager[1106]: Activation (eth0) Stage 1 of 5 (Device Prepare) complete. NetworkManager[1106]: Activation (eth0) Stage 2 of 5 (Device Configure) starting... NetworkManager[1106]: (eth0): device state change: prepare -> config (reason 'none') [40 50 0] NetworkManager[1106]: Activation (eth0) Stage 2 of 5 (Device Configure) successful. NetworkManager[1106]: Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled. NetworkManager[1106]: Activation (eth0) Stage 2 of 5 (Device Configure) complete. NetworkManager[1106]: Activation (eth0) Stage 3 of 5 (IP Configure Start) started... NetworkManager[1106]: (eth0): device state change: config -> ip-config (reason 'none') [50 70 0] NetworkManager[1106]: Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds) NetworkManager[1106]: dhclient started with pid 4044 NetworkManager[1106]: Activation (eth0) Stage 3 of 5 (IP Configure Start) complete. NetworkManager[1106]: (eth0): DHCPv4 state changed nbi -> preinit dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14 NetworkManager[1106]: (eth0): link disconnected (deferring action for 4 seconds) NetworkManager[1106]: (eth0): link connected NetworkManager[1106]: (eth0): DHCPv4 request timed out. NetworkManager[1106]: (eth0): canceled DHCP transaction, DHCP client pid 4044 NetworkManager[1106]: Activation (eth0) Stage 4 of 5 (IPv4 Configure Timeout) scheduled... NetworkManager[1106]: Activation (eth0) Stage 4 of 5 (IPv4 Configure Timeout) started... NetworkManager[1106]: Activation (eth0) Stage 4 of 5 (IPv4 Configure Timeout) complete. Reported-by: Jean-Christian de Rivaz --- Hi Jean-Christian, I think something like this could help. Lubo src/devices/nm-device.c | 4 1 file changed, 4 insertions(+) diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c index 913c488..53ddb66 100644 --- a/src/devices/nm-device.c +++ b/src/devices/nm-device.c @@ -1295,6 +1295,10 @@ link_disconnect_action_cancel (NMDevice *self) g_source_remove (priv->carrier_defer_id); _LOGD (LOGD_DEVICE, "link disconnected (canceling deferred action) (id=%u)", priv->carrier_defer_id); priv->carrier_defer_id = 0; + + /* Don't let the DHCP requests that were lost while the carrier was down +* contribute to the DHCP timeout -- restart the transaction. */ + update_dynamic_ip_setup (self); } } -- 2.4.3 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] platform: move link_get_user_ipv6ll_enabled() to nm-platform-linux
It uses Linux specific functionality.
Furthermore, the IN6_ADDR_GEN_MODE_NONE macro might not be available in
nm-platform which breaks the build.
Reported-by: Petr Vorel
---
Petr,
does this look good to you?
Thanks,
Lubo
src/platform/nm-linux-platform.c | 16
src/platform/nm-platform.c | 11 ++-
src/platform/nm-platform.h | 1 +
3 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/src/platform/nm-linux-platform.c b/src/platform/nm-linux-platform.c
index f3a9254..b6b8e33 100644
--- a/src/platform/nm-linux-platform.c
+++ b/src/platform/nm-linux-platform.c
@@ -2987,6 +2987,21 @@ link_set_user_ipv6ll_enabled (NMPlatform *platform, int
ifindex, gboolean enable
}
static gboolean
+link_get_user_ipv6ll_enabled (NMPlatform *platform, int ifindex)
+{
+#if HAVE_LIBNL_INET6_ADDR_GEN_MODE
+ {
+ const NMPlatformLink *pllink;
+
+ pllink = nm_platform_link_get (platform, ifindex);
+ if (pllink && pllink->inet6_addr_gen_mode_inv)
+ return _nm_platform_uint8_inv
(pllink->inet6_addr_gen_mode_inv) == IN6_ADDR_GEN_MODE_NONE;
+ }
+#endif
+ return FALSE;
+}
+
+static gboolean
link_supports_carrier_detect (NMPlatform *platform, int ifindex)
{
const char *name = nm_platform_link_get_name (platform, ifindex);
@@ -4952,6 +4967,7 @@ nm_linux_platform_class_init (NMLinuxPlatformClass *klass)
platform_class->link_get_udev_device = link_get_udev_device;
platform_class->link_set_user_ipv6ll_enabled =
link_set_user_ipv6ll_enabled;
+ platform_class->link_get_user_ipv6ll_enabled =
link_get_user_ipv6ll_enabled;
platform_class->link_set_address = link_set_address;
platform_class->link_get_permanent_address = link_get_permanent_address;
diff --git a/src/platform/nm-platform.c b/src/platform/nm-platform.c
index 8803377..ee4b1a1 100644
--- a/src/platform/nm-platform.c
+++ b/src/platform/nm-platform.c
@@ -965,15 +965,8 @@ nm_platform_link_get_user_ipv6ll_enabled (NMPlatform
*self, int ifindex)
g_return_val_if_fail (ifindex >= 0, FALSE);
-#if HAVE_LIBNL_INET6_ADDR_GEN_MODE
- {
- const NMPlatformLink *pllink;
-
- pllink = nm_platform_link_get (self, ifindex);
- if (pllink && pllink->inet6_addr_gen_mode_inv)
- return _nm_platform_uint8_inv
(pllink->inet6_addr_gen_mode_inv) == IN6_ADDR_GEN_MODE_NONE;
- }
-#endif
+ if (klass->link_get_user_ipv6ll_enabled)
+ return klass->link_get_user_ipv6ll_enabled (self, ifindex);
return FALSE;
}
diff --git a/src/platform/nm-platform.h b/src/platform/nm-platform.h
index 16eb351..9ef4080 100644
--- a/src/platform/nm-platform.h
+++ b/src/platform/nm-platform.h
@@ -446,6 +446,7 @@ typedef struct {
GObject *(*link_get_udev_device) (NMPlatform *self, int ifindex);
gboolean (*link_set_user_ipv6ll_enabled) (NMPlatform *, int ifindex,
gboolean enabled);
+ gboolean (*link_get_user_ipv6ll_enabled) (NMPlatform *, int ifindex);
gboolean (*link_get_permanent_address) (NMPlatform *,
int ifindex,
--
2.4.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: C&P error in --enable-more-logging commit
On Tue, 2015-07-14 at 20:17 +0200, Michael Biebl wrote: > Hi, > > commit 63593a19d8e7d7fb5e844f0e3c8ac847e68699cb added a > --enable-more-logging configure switch which seems to be a C&P of the > asserts configure switch, resulting in > > AC_DEFINE(NM_MORE_LOGGING, [1], [Define if more asserts are enabled]) Thank you! Fixed: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=924117c14422d5c40d00a3c03053c7fc20bfc5b6 Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.0.4 released
Hi, I'm pleased to announce the release of NetworkManager 1.0.4, the latest stable release in the 1.0.x series. We recommend that users of 1.0.x series as well as users of older 0.9.10.x series upgrade to this release which is D-Bus and C API backwards compatible. The 1.0.4 release is mostly a bugfix release, but it adds a fair amount of new features and resolves a number of issues. An overview of the changes in 1.0.4 is here http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=nm-1-0 Grab NetworkManager and the applet/editor: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager-1.0.4.tar.xz https://download.gnome.org/sources/network-manager-applet/1.0/network-manager-applet-1.0.4.tar.xz We did not release new versions of the VPN plugins. Please use version 1.0.2 of the plugins with NetworkManager 1.0.4. Thanks to everybody who contributed patches and translations: Andika Triwidada, Balázs Úr, Beniamino Galvani, Cédric Valmary, Dan Williams, Dan Winship, Gábor Kelemen, Jan Alexander Steffens, Jiří Klimeš, Lubomir Rintel, Marek Černocký, Pavel Šimerda, Piotr Drąg, Thomas Haller, Yuri Chornoivan and Zdeněk Hataš. Special thanks to everybody that reported bugs and tested this release! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v2 2/2] autogen.sh: print errors to stderr, printf instead echo -n
On Wed, 2015-07-01 at 16:05 -0500, Dan Williams wrote:
> On Fri, 2015-06-19 at 01:25 +0200, Petr Vorel wrote:
> > Signed-off-by: Petr Vorel
> > ---
> > autogen.sh | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/autogen.sh b/autogen.sh
> > index a7e1c17..b4394bf 100755
> > --- a/autogen.sh
> > +++ b/autogen.sh
> > @@ -15,8 +15,8 @@ PKG_NAME=NetworkManager
> >
> > (test -f $srcdir/configure.ac \
> >&& test -f $srcdir/src/main.c) || {
> > -echo -n "**Error**: Directory "\`$srcdir\'" does not look like
> > the"
> > -echo " top-level $PKG_NAME directory"
> > +printf "**Error**: Directory "\`$srcdir\'" does not look like
> > the" >&2
> > +echo " top-level $PKG_NAME directory" >&2
> > exit 1
> > }
> >
>
> This patch at least seems OK to me...
>
> Dan
>
Yes, applied.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 2/2] applet: default to ipv6.method=auto for WWAN connections
On Wed, 2015-07-01 at 16:07 -0500, Dan Williams wrote: > NM has fallback logic to ensure that even if IPv6 gets tried and > fails, > that IPv4 gets used instead. So it should be safe to default to > automatic IPv6 support for new WWAN connections now, and bugs should > get fixed instead of papered over. > --- > src/mobile-helpers.c | 9 + > 1 file changed, 9 insertions(+) Both patches look good to me. Applied (and will cherry-pick to 1.0 branch shortly). ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
1.0.4 release next week?
Hello, it's some time since the 1.0.2 release already and the nm-1-0 branch now has plenty bug fixes and enhancements. Moreover, significant effort has been done at Red Hat to test and stabilize the branch for the next update of the Enterprise Linux distribution. It sounds like it's a good idea to conduct some manual smoke testing and do a release during the next week. Would anyone mind? The NEWS file has already been updated to reflect the newsworthy changes that are already in: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=nm-1-0 If anyone needs anything cherry-picked from the master branch, now is the good time to do it (or ask us to do the backport). Comments, ideas, opinions? Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH v2 1/2] Allow building without gtk-doc installed
This doesn't look good to me.
autogen.sh is a maintainer tool and we pretty much always want to
create tarballs with GTK-doc.
Why don't you just use autoreconf (with -f and -i) instead of
autogen.sh when doing builds off Git?
On Fri, 2015-06-19 at 01:25 +0200, Petr Vorel wrote:
> This requires creating minimal gtk-doc.make and check for
> GTK_DOC_CHECK
> availability in configure.ac.
>
> Signed-off-by: Petr Vorel
> ---
> autogen.sh | 14 +-
> configure.ac | 7 ++-
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/autogen.sh b/autogen.sh
> index 5ec9a5a..a7e1c17 100755
> --- a/autogen.sh
> +++ b/autogen.sh
> @@ -22,7 +22,19 @@ PKG_NAME=NetworkManager
>
> cd $srcdir
>
> -gtkdocize
> +GTKDOCIZE=`which gtkdocize` || true
> +if test -z $GTKDOCIZE; then
> +echo "**Warning**: No GTK-Doc found, documentation won't be
> generated" >&2
> +echo " and 'make dist' and 'make distcheck' will not work." >&2
> +
> +# create minimal gtk-doc.make if missing as we depend on it
> +if test -f gtk-doc.make; then :; else
> + printf "EXTRA_DIST = \nCLEANFILES = \n" > gtk-doc.make
> +fi
> +else
> +gtkdocize || exit $?
> +fi
> +
> autopoint --force
> AUTOPOINT='intltoolize --automake --copy' autoreconf --force -
> -install --verbose
>
> diff --git a/configure.ac b/configure.ac
> index e1a1917..c776d3d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -898,7 +898,12 @@ AS_IF([test "$with_valgrind" != "no"],
> AC_SUBST(VALGRIND_RULES, []))
> AM_CONDITIONAL(WITH_VALGRIND, test "${with_valgrind}" != "no")
>
> -GTK_DOC_CHECK(1.0)
> +# Check for GTK_DOC_CHECK availability. The GTK_DOC_CHECK invocation
> +# must be on its own line, gtkdocize relies on it
> +m4_ifdef([GTK_DOC_CHECK], [
> +GTK_DOC_CHECK([1.0])
> +])
> +AM_CONDITIONAL(ENABLE_GTK_DOC, test "$enable_gtk_doc" = "yes")
>
> # check for pregenerated manpages to be installed
> install_pregen_manpages=no
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Docker images with NetworkManager
Hi, I've switched my NetworkManager image (with Fedora and systemd) to the nm-1-0 stable branch and added an image for CentOS 7: https://registry.hub.docker.com/u/lkundrak/network-manager/ https://registry.hub.docker.com/u/lkundrak/centos-network-manager/ They mostly serve as a proof-of-concept that we work just fine in containers, but maybe someone would find a more useful use for it. Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Cherry-pick 'fix build with Linux 3.2.0 headers' also to branch nm-1-0
On Tue, 2015-06-16 at 14:10 +0200, Petr Vorel wrote: > Hi there, > > could you please cherry-pick commit 22b99e3b 'fix build with Linux > 3.2.0 headers' also to > branch nm-1-0? It'd be nice to have it in 1.0.4 (not sure if it 1.0.4 > is going to be made > from master or from nm-1-0). I'm wondering -- what is your use case here? The 3.2.0 is rather old and the internal DHCP client from systemd doesn't work with it. I guess a distribution shipping a kernel that is this old has some other components that are too old, such as glib2? > Thanks a lot. > > Kind regards, > Petr Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: net/bridge/br_private.h:626 suspicious rcu_dereference_check() usage!
On Fri, 2015-05-08 at 13:26 +0200, poma wrote: > $ dmesg ... > [ 61.167012] net/bridge/br_private.h:626 suspicious > rcu_dereference_check() usage! > Is this material for linux-kernel@ ? Yes. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 1.0.2 released
On Tue, 2015-05-05 at 15:39 +0200, Lubomir Rintel wrote: > Hi, > > I'm pleased to announce the release of NetworkManager 1.0.2, the > latest stable release in the 1.0.x series. We recommend that users > of 1.0.x series as well as users of older 0.9.10.x series upgrade to > this release which is D-Bus and C API backwards compatible. This announcement has some extra line breaks and thus the links are difficult to follow. I'm sorry for that. I'm sending another one. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.0.2 released
Hi, I'm pleased to announce the release of NetworkManager 1.0.2, the latest stable release in the 1.0.x series. We recommend that users of 1.0.x series as well as users of older 0.9.10.x series upgrade to this release which is D-Bus and C API backwards compatible. The 1.0.2 release is mostly a bugfix release, but it adds a couple of new features and resolves a huge number of issues and memory leaks. An overview of the changes in 1.0.2 is here http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=nm-1-0 Grab NetworkManager, the applet/editor, and the VPN plugins here: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager-1.0.2.tar.xz https://download.gnome.org/sources/network-manager-applet/1.0/network-manager-applet-1.0.2.tar.xz https://download.gnome.org/sources/NetworkManager-vpnc/1.0/NetworkManager-vpnc-1.0.2.tar.xz https://download.gnome.org/sources/NetworkManager-openvpn/1.0/NetworkManager-openvpn-1.0.2.tar.xz https://download.gnome.org/sources/NetworkManager-openconnect/1.0/NetworkManager-openconnect-1.0.2.tar.xz https://download.gnome.org/sources/NetworkManager-pptp/1.0/NetworkManager-pptp-1.0.2.tar.xz Thanks to everybody who contributed patches and translations: Aleksander Morgado, Anders Jonsson, Andika Triwidada, Ankit Patel, Balázs Úr, Bastien Nocera, Beniamino Galvani, Bernd Edlinger, Christian Kirbach, Dan Williams, Dan Winship, David Ward, Dušan Kazik, Efstathios Iosifidis, Fran Dieguez, Hedda Peters, Inaki Larranaga Murgoitio, Jiří Klimeš, Kjartan Maraas, Lubomir Rintel, Luke Yelavich, Marek Černocký, Mathieu Trudel-Lapierre, Milo Casagrande, Muhammet Kara, Necdet Yücel, Pavel Šimerda, Petr Vorel, Piotr Drąg, Rafael Ferreira, Rui Matos, Samir Ribic, Stas Solovey, Thomas Haller, Tom Tryfonidis, You-Sheng Yang, Yuri Chornoivan, Zdeněk Hataš, Мирослав Николић Special thanks to everybody that reported bugs and tested this release! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.0.2 released
Hi, I'm pleased to announce the release of NetworkManager 1.0.2, the latest stable release in the 1.0.x series. We recommend that users of 1.0.x series as well as users of older 0.9.10.x series upgrade to this release which is D-Bus and C API backwards compatible. The 1.0.2 release is mostly a bugfix release, but it adds a couple of new features and resolves a huge number of issues and memory leaks. An overview of the changes in 1.0.2 is here http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=nm- 1-0 Grab NetworkManager, the applet/editor, and the VPN plugins here: https://download.gnome.org/sources/NetworkManager/1.0/NetworkManager -1.0.2.tar.xz https://download.gnome.org/sources/network-manager-applet/1.0/network -manager-applet-1.0.2.tar.xz https://download.gnome.org/sources/NetworkManager -vpnc/1.0/NetworkManager-vpnc-1.0.2.tar.xz https://download.gnome.org/sources/NetworkManager -openvpn/1.0/NetworkManager-openvpn-1.0.2.tar.xz https://download.gnome.org/sources/NetworkManager -openconnect/1.0/NetworkManager-openconnect-1.0.2.tar.xz https://download.gnome.org/sources/NetworkManager -pptp/1.0/NetworkManager-pptp-1.0.2.tar.xz Thanks to everybody who contributed patches and translations: Aleksander Morgado, Anders Jonsson, Andika Triwidada, Ankit Patel, Balázs Úr, Bastien Nocera, Beniamino Galvani, Bernd Edlinger, Christian Kirbach, Dan Williams, Dan Winship, David Ward, Dušan Kazik, Efstathios Iosifidis, Fran Dieguez, Hedda Peters, Inaki Larranaga Murgoitio, Jiří Klimeš, Kjartan Maraas, Lubomir Rintel, Luke Yelavich, Marek Černocký, Mathieu Trudel-Lapierre, Milo Casagrande, Muhammet Kara, Necdet Yücel, Pavel Šimerda, Petr Vorel, Piotr Drąg, Rafael Ferreira, Rui Matos, Samir Ribic, Stas Solovey, Thomas Haller, Tom Tryfonidis, You-Sheng Yang, Yuri Chornoivan, Zdeněk Hataš, Мирослав Николић Special thanks to everybody that reported bugs and tested this release! Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-iface-helper: set last_config properly
On Sat, 2015-04-25 at 16:15 +0200, Thomas Haller wrote: > On Fri, 2015-04-24 at 22:38 -0400, David Ward wrote: > > Update last_config outside of the conditional; otherwise it will > > always remain set to NULL. > > > > Signed-off-by: David Ward > > --- > > Acked-By: Thomas Haller Looks fine from here. Thank you, applied! > ___ > 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: Annoying bug in NM1.0.0-8
On Sun, 2015-04-19 at 13:21 -0600, Chris Murphy wrote: > On Sun, Apr 19, 2015 at 9:20 AM, Dan Mossor wrote: > > Greetings, folks. > > > > I and at least one other individual have noticed an annoying bug with > > NetworkManager-1.0.0-8.fc22.x86_64 but we aren't sure of the root cause so > > we can't legitimately file a BZ on it yet. The issue we're seeing is that > > with a fully updated Fedora 22 Beta system, once NM is in operation for a > > bit it starts to loose connectivity. Not total connectivity, but partial. > > I'm having the same experience, which is sometimes networking works > for some thing some of the time sometimes. Google searches work, > logging in to sites like outlook.com works, but then hangs when email > is to be downloaded or sent. If I reboot the same hardware to OS X the > problems don't happen. If I reboot Fedora 22, it might be fixed for a > short while, or it might misbehave right away. I can't figure out the > pattern. Please report that issue into bugzilla. Whenever the issue occurs, please include the following: 1.) Output of "ip addr", "ip link", "ip route" 2.) Output of "nmcli c", "nmcli d" 3.) Logs. Complete "systemctl -b0 -l" would be awesome. If that's too long, "journalctl -b0 -l _COMM=NetworkManager" would probably do too. Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Running NetworkManager in a container
Hello, I've made a short writeup about running NetworkManager in various container solutions: https://wiki.gnome.org/LubomirRintel/NMContainers Maybe someone will find it useful for hacking on NetworkManager. Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: jhbuild run for NetworkManager
On Mon, 2015-04-13 at 11:34 +0200, Thomas Haller wrote: > One problem is that the system-wide NetworkManager instance gets D-Bus > activated at random times. > E.g. > >systemctl stop NetworkManager > ># NetworkManager gets D-Bus activated again > >./src/NetworkManager --debug ># fails with: ># Could not acquire the NetworkManager service as it is already taken. > > For that, you could do: > >chmod -x /sbin/NetworkManager "systemctl mask NetworkManager" is probably less invasive and should be preferred (doesn't modify the packaged files, just adds configuration). >systemctl stop NetworkManager > > > > You probably want to start NetworkManager with --debug so that it stays > in foreground. Maybe also --log-level=DEBUG Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: You must be root to run NetworkManager --version / --help
On Tue, 2015-04-07 at 18:15 +0200, poma wrote: > $ NetworkManager --version > You must be root to run NetworkManager! > > $ NetworkManager --help > You must be root to run NetworkManager! Seems it's already fixed in master. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] core: add "fatal-warnings" option to NM_DEBUG
Looks good.
On Tue, 2015-03-31 at 07:41 +0200, Thomas Haller wrote:
> NM already understands the command line argument --g-fatal-warnings
> which causes setting of g_log_set_always_fatal().
>
> Also interpret the "fatal-warnings" token in NM_DEBUG environment
> variable and in main.debug configuration setting.
>
> Usage hint: either set
>
> $ export NM_DEBUG=RLIMIT_CORE,fatal-warnings
>
> or add the following section to NetworkManager.conf
>
> [main]
> debug=RLIMIT_CORE,fatal-warnings
> ---
> man/NetworkManager.conf.xml.in | 8 +++-
> src/main.c | 25 +
> 2 files changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/man/NetworkManager.conf.xml.in b/man/NetworkManager.conf.xml.in
> index 0fbf9d2..ae4ba88 100644
> --- a/man/NetworkManager.conf.xml.in
> +++ b/man/NetworkManager.conf.xml.in
> @@ -261,7 +261,13 @@ no-auto-default=*
> values are supported:
>
>RLIMIT_CORE: set ulimit -c unlimited
> - to write out core dumps.
> + to write out core dumps. Beware, that a core dump can contain
> + sensitive information such as passwords or configuration settings.
> +
> +
> + fatal-warnings: set g_log_set_always_fatal()
> + to core dump on warning messages from glib. This is equivalent
> + to the --g-fatal-warnings command line option.
>
>
>
> diff --git a/src/main.c b/src/main.c
> index 2648a08..520a82d 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -160,11 +160,23 @@ parse_state_file (const char *filename,
> }
>
> static void
> +_set_g_fatal_warnings ()
> +{
> + GLogLevelFlags fatal_mask;
> +
> + fatal_mask = g_log_set_always_fatal (G_LOG_FATAL_MASK);
> + fatal_mask |= G_LOG_LEVEL_WARNING | G_LOG_LEVEL_CRITICAL;
> + g_log_set_always_fatal (fatal_mask);
> +}
> +
> +static void
> _init_nm_debug (const char *debug)
> {
> const guint D_RLIMIT_CORE = 1;
> + const guint D_FATAL_WARNINGS = 2;
> GDebugKey keys[] = {
> { "RLIMIT_CORE", D_RLIMIT_CORE },
> + { "fatal-warnings", D_FATAL_WARNINGS },
> };
> guint flags = 0;
> const char *env = getenv ("NM_DEBUG");
> @@ -178,7 +190,7 @@ _init_nm_debug (const char *debug)
> if (debug && strcasecmp (debug, "help") != 0)
> flags |= g_parse_debug_string (debug, keys, G_N_ELEMENTS
> (keys));
>
> - if (flags & D_RLIMIT_CORE) {
> + if (NM_FLAGS_HAS (flags, D_RLIMIT_CORE)) {
> /* only enable this, if explicitly requested, because it might
>* expose sensitive data. */
>
> @@ -188,6 +200,8 @@ _init_nm_debug (const char *debug)
> };
> setrlimit (RLIMIT_CORE, &limit);
> }
> + if (NM_FLAGS_HAS (flags, D_FATAL_WARNINGS))
> + _set_g_fatal_warnings ();
> }
>
> void
> @@ -270,13 +284,8 @@ main (int argc, char *argv[])
> config_cli = nm_config_cmd_line_options_new ();
> do_early_setup (&argc, &argv, config_cli);
>
> - if (global_opt.g_fatal_warnings) {
> - GLogLevelFlags fatal_mask;
> -
> - fatal_mask = g_log_set_always_fatal (G_LOG_FATAL_MASK);
> - fatal_mask |= G_LOG_LEVEL_WARNING | G_LOG_LEVEL_CRITICAL;
> - g_log_set_always_fatal (fatal_mask);
> - }
> + if (global_opt.g_fatal_warnings)
> + _set_g_fatal_warnings ();
>
> if (global_opt.show_version) {
> fprintf (stdout, NM_DIST_VERSION "\n");
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Using nmcli
Hi Garry, On Fri, 2015-02-20 at 06:58 -0800, Garrison Ricketson wrote: > Hello all. > Recently I had some problems, my "desktop" would not load, and I needed > to connect online, to try to re-install , how ever normally I start my > internet connection from the desktop, and had never tried this from the > command-line,which is all I had, so I searched google, and found I could > use the command "nmcli" , but I am having trouble understanding what the > correct syntex would be, someone told me this " nmcli dev wifi con > password " but I got "syntax error near unexpected token > `newline'" Well, you need to replace "" with the actual network name: $ nmcli dev wifi list * SSID MODE CHAN RATE SIGNAL BARS SECURITY My Network Infra 5254 Mbit/s 49 ▂▄__ WPA2 802.1X ... $ nmcli --ask dev wifi connect 'My Network' Password: behemoth Device 'wlp4s0' successfully activated with 'e27bd7dd-97a5-4a66-8d48-af943947028f'. $ > I spent several hours going over some articles I found via google, but > couldn't make much sense of them. Can anyone tell me what the correct > commands would be to start neworkmanager, then connect or activate the > device, in this case it would have been "wlan" not wifi,..Thank you all > in advance, Please have a look at the NetworkManager manual; the results are likely to be better than the search results from google. I believe the "EXAMPLES" section in nmcli(1) manual covers exactly your use case. > > > From Garry Regards, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
networkd bus activation and exit on idle
>From systemd 219 release notes: [1] > * networkd now exits when idle. It will be automatically > restarted as soon as interfaces show up, are removed or > change state. networkd will stay around as long as there is > at least one DHCP state machine or similar around, that keep > it non-idle. [1] http://lists.freedesktop.org/archives/systemd-devel/2015-February/028447.html Anyone knows details? How do they find out about an interface showing up? Could we do the same thing too? At least for servers where only devices are platform devices; no Bluetooth or Modems? Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [review] dcbw/0910-memleaks
On Tue, 2015-02-10 at 15:10 +0100, Dan Williams wrote: > Hi, > > Review request for this; most are cherry-picks (with fixup) for > thaller's git master memleak fixes. Anything that has my commit > authorship is new though and should get a look. It allows > valgrind-enabled 'make check' to pass on 0.9.10. Looks good to me. Passed a compile-check with Werror too. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] build: install nm-settings-ifcfg-rh.5 man page conditionally
Hi Michael, Thanks you for the patch. On Mon, 2015-02-09 at 01:31 +0100, Michael Biebl wrote: > Only install nm-settings-ifcfg-rh.5 man page if the ifcfg-rh > configuration plugin has been enabled. It's confusing to have this man > page around on e.g. a Debian based distro. > > See attached patch. > > There might be small issue here, i.e. if you build the release tarball > and you don't have ifcfg-rh enabled, then the nm-settings-ifcfg-rh.5 man > page would be missing from the release tarball as it's not added to > EXTRA_DIST > > If that is a concern, please let me know and I'll rework to the patch to > always unconditionally build and dist the man pages, but only install > them conditionally. The distribution tarball contents indeed should not depend on the configuration configuration options. Please rework it the way you suggest. Thank you, Lubo (By the way, the preferred way to submit patches by e-mail is inline as opposed to adding an attachment. git send-email makes that easy. Not a big deal really, especially for small patches, but it makes it a bit more convenient to quickly review and reply inline in some e-mail clients.) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ANN: NetworkManager 0.9.10.1 (0.9.10.2-rc1) testing release
On Thu, 2015-01-22 at 17:16 -0600, Dan Williams wrote: > Hi, > > It's past time for a bug-fix release for NetworkManager 0.9.10, so > here's a testing release candidate. Please help test if you're using > 0.9.10 already, so that we can get the release out next week. > > There are a ton of fixes, many already cherry-picked by distros, but > many new ones as well. Lets make it solid! > > https://download.gnome.org/sources/NetworkManager/0.9/NetworkManager-0.9.10.1.tar.xz > https://download.gnome.org/sources/network-manager-applet/0.9/network-manager-applet-0.9.10.1.tar.xz Thank you. I've added it to Fedora 21 testing and so far there's a couple of positive comments: https://admin.fedoraproject.org/updates/FEDORA-2015-1087/network-manager-applet-0.9.10.1-2.fc21 https://admin.fedoraproject.org/updates/FEDORA-2015-1142/NetworkManager-0.9.10.1-2.fc21 It works good on my Fedora 21 installation too. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] dist: include manual page sources
On Thu, 2015-01-22 at 09:50 -0500, Dan Winship wrote: > On 01/22/2015 04:54 AM, Lubomir Rintel wrote: > > - $(docbook_generated_man_pages:.%=.xml) \ > > > + $(addsuffix .xml,$(basename $(docbook_generated_man_pages)))\ > > That seems like it should be the same thing... what does the first one do? The ".%" pattern is applied to the complete string (think ^\..*$). It thus does not match and nothing is substituted (which is why the generate manual pages got included and not the source). Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] libnm: drop libdbus-glib from pkg-config file
libnm uses GIO DBus library instead.
https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00065.html
---
libnm/libnm.pc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Thu, 2015-01-22 at 03:40 +0100, Michael Biebl wrote:
Hi,
>
> the libnm.pc file for the new libnm library has
>
> Requires: gio-2.0 dbus-glib-1
>
> This looks incorrect, especially the dependency on dbus-glib-1.
> Is this a C&P error? Especially since the Description is the same as for
> libnm-util.pc.
Yes, that looks like a mistake. Unless anyone objects I'll remove it.
Thank you
Lubo
diff --git a/libnm/libnm.pc.in b/libnm/libnm.pc.in
index 6392799..5fe26b6 100644
--- a/libnm/libnm.pc.in
+++ b/libnm/libnm.pc.in
@@ -6,7 +6,7 @@ includedir=@includedir@
Name: libnm
Description: Convenience library for clients of NetworkManager
Version: @VERSION@
-Requires: gio-2.0 dbus-glib-1
+Requires: gio-2.0
Cflags: -I${includedir}/libnm
Libs: -L${libdir} -lnm
--
2.1.0
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] dist: include manual page sources
Omitted by mistake with an errorneous substitution.
https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00066.html
---
man/Makefile.am | 16
1 file changed, 8 insertions(+), 8 deletions(-)
On Thu, 2015-01-22 at 04:14 +0100, Michael Biebl wrote:
hi,
>
> I just noticed that the 1.0.0 tarball failed to build twice in a row
> (./configure && make && make clean * 2)
> due to man/{NetworkManager.xml,nmcli-examples.xml} missing in the dist
> tarball.
> The tarball only contains the generated man pages but should also
> contains the xml sources.
Good catch, Michael, thank you. Unless anyone objects I'll apply this patch and
future releases (from 1.0 branch too) will contain the files.
Regards,
Lubo
diff --git a/man/Makefile.am b/man/Makefile.am
index 4577cb4..e7262e7 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -71,14 +71,14 @@ docbook_autogenerated_man_pages = \
nm-settings-keyfile.5 \
nm-settings-ifcfg-rh.5
-EXTRA_DIST += \
- nm-settings.xml \
- nm-settings.xsl \
- nm-settings-keyfile.xml \
- nm-settings-keyfile.xsl \
- nm-settings-ifcfg-rh.xml\
- nm-settings-ifcfg-rh.xsl\
- $(docbook_generated_man_pages:.%=.xml) \
+EXTRA_DIST += \
+ nm-settings.xml \
+ nm-settings.xsl \
+ nm-settings-keyfile.xml \
+ nm-settings-keyfile.xsl \
+ nm-settings-ifcfg-rh.xml\
+ nm-settings-ifcfg-rh.xsl\
+ $(addsuffix .xml,$(basename $(docbook_generated_man_pages)))\
$(docbook_autogenerated_man_pages)
man_MANS += $(configure_generated_man_pages)
--
2.1.0
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm bonding interface change MTU size
Hi Prabhakar, On Tue, 2015-01-06 at 08:28 +0530, prabhakar_puj...@dell.com wrote: > Hi All, > > I am not found an option to change bond interface MTU size in nm GUI. Also > if I edited CFG file with MTU size nm is not considering to set it while > reboot. > > Is there any plan to add this? Yes, I intend to add this soon. I see you've opened a Bugzilla ticket too, I'll keep you updated there. > Thanks > Prabhakar Thank you, Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless Interface APIs needed
On Fri, 2014-11-28 at 16:33 +0530, Vasudeo Bidve wrote: > Hi, > > I am working on a networking project where only Wi-Fi interfaces are > used on all hosts for communication. It has to be a private network, > operating on IPv6 without using DHCP(v6). So obviously, the trick is > to assign Link-Local IPv6 addresses to all hosts using their > respective MAC ids and proceed. > > I did a proof-of-concept of such networking using Ethernet and PCs > with ubuntu (14.04 LTS). But this is not working with wireless > interfaces. > > I tried to do this with command line utilities like 'iw' and > 'iwconfig' on my PCs, but as soon as I plug in the USB-wifi adapter, > the network-manager in ubuntu sets it in 'managed' mode, which I don't > want. Further, if I try to assign another mode, I get an error message > as 'device is busy'. That's possible because AP scan is running. > Then by taking the link down, it doesn't add any > modes. Using the network setting panel in ubuntu, I can configure it > in 'ad-hoc' mode, but I want to do it programmatically (through a C > code, shell script, anything) without using that network-manager > utility finally in my project. Wrong list, possibly? :) Any particular reason you won't use NetworkManager? See "unmanaged-devices" in NetworkManager.conf(5) manual. > In my project, finally all PCs will be replaced by embedded linux > SBCs. USB wi-fi adapters will possibly be replaced by wi-fi modules. > But programmatically, they should be able to communicate with each > other at Link-Local IPv6 addresses in Ad-Hoc mode. > > At this moment, what I need is a set of wireless interface APIs, (of > course with some helpful documentation) to configure the wifi > interface in Ad-Hoc mode (possibly in AP/Station mode as and when > needed), get a Link-Local IPv6 address assigned to itself and start > networking. Any URL to such information will also do. > > If there is any step-by-step guide (or example codes) then it will be > even more helpful. > > I am hopeful from this group because the network-manager internally > *USES* these APIs and you people must be knowing what I need. We use the same nl80211 API as "iw" does. We also talk to wpa_supplicant via DBus. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OK, I give up
On Thu, 2014-11-27 at 17:15 -0500, Gene Czarcinski wrote: > On Fedora 21 with NetworkManager-0.9.10.0-13.git20140704.fc21.x86_6 and > on Fedora 20 with NetworkManager-0.9.9.0-46.git20131003.fc20.x86_64 I am > seein some strange network devices: > > 18: rose7: mtu 249 qdisc noop state DOWN group default > > link/rose 00:00:00:00:00 brd 00:00:00:00:00 > > 19: rose8: mtu 249 qdisc noop state DOWN group default > > link/rose 00:00:00:00:00 brd 00:00:00:00:00 > > 20: rose9: mtu 249 qdisc noop state DOWN group default > > link/rose 00:00:00:00:00 brd 00:00:00:00:00 > and in /var/log/messages: > > Nov 27 17:04:53 vulture NetworkManager[24854]: (rose7): new > > Generic device (driver: 'unknown' ifindex: 18) > > Nov 27 17:04:53 vulture NetworkManager[24854]: (rose7): > > exported as /org/freedesktop/NetworkManager/Devices/17 > > Nov 27 17:04:53 vulture NetworkManager[24854]: (rose8): new > > Generic device (driver: 'unknown' ifindex: 19) > > Nov 27 17:04:53 vulture NetworkManager[24854]: (rose8): > > exported as /org/freedesktop/NetworkManager/Devices/18 > > Nov 27 17:04:53 vulture NetworkManager[24854]: (rose9): new > > Generic device (driver: 'unknown' ifindex: 20) > > Nov 27 17:04:53 vulture NetworkManager[24854]: (rose9): > > exported as /org/freedesktop/NetworkManager/Devices/19 > What is this? As the name suggests, those are ROSE devices. You most likely are using (or attempted to use) an amateur radio? > It sure does clutter up the output of "ip addr" Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: https://bugzilla.redhat.com/show_bug.cgi?id=1155719
On Thu, 2014-11-13 at 16:58 +, Barry Scott wrote: > On Thu 13 Nov 2014 09:31:24 Chuck Anderson wrote: > > On Thu, Nov 13, 2014 at 01:59:20PM +, Barry Scott wrote: > > How would monotonic time handle suspend/resume? > > Good question, I recall that monotonic time freezes while suspended. In Linux 2.6.39, CLOCK_BOOTTIME was added, which is essentially monotonic time that accounts for time when suspended (rtc progresses, no chance of it being reconfigured). We use that one around NetworkManager: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/NetworkManagerUtils.c#n1746 We essentially keep the CLOCK_MONOTONIC support so that the test suite doesn't needlessly fail on el6 (2.6.32) build hosts. Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
