Re: DHCP and static IP configuration hangs when no DHCP

[David Bourgeois]

Hi Francesco,

I had Network Manager 1.6.2 from Debian Stretch installed and there it does
not work, no IP assigned while connecting. I updated to 1.14 and there it
indeed works like you were expecting. And this does what I need it to, so
thank you very much for the help!

Regards,
David

On Wed, Jun 12, 2019 at 9:58 PM Francesco Giudici 
wrote:

> Hi David,
>
> On 6/12/19 8:17 PM, David Bourgeois wrote:
> > The only hack I found is to create a static IP only, then in add a
> > up-post script that manually launches dhclient on the interface. That
> > does what I need but it's somehow cumbersome.
> >
> > On Wed, Jun 12, 2019 at 8:15 PM David Bourgeois  > > wrote:
> >
> > Hi Francesco,
> >
> > Thank you for your answer. I can indeed do that to keep DHCP trying
> > forever or nearly, that's a good idea. But my problem is that the
> > static IP is not created at all until there's an answer from a DHCP
> > server. I was expecting that the static IP would be created then the
> > dynamic IP would appear whenever the DHCP answers. But they both
> > appear only when the DHCP answers. i'm unable to create a static IP
> > first, then start DHCP. Any idea?
>
> This is weird, as I just gave it a try and works by assigning the static
> ip first, then keeping trying the dhcp. If the dhcp timeouts, the
> connection fails and is teared down, clearing also the static ip that
> was configured. This is why the trick worked for me.
> Which NM version do you have?
> Can you confirm that when the connection is in the "connecting" state
> (check with 'nmcli connection') the ip address is not assigned (check
> for the ip with 'ip add')?
>
> Thanks
>
> Francesco
>
>
> >
> > Thanks,
> > David
> >
> > On Wed, Jun 12, 2019 at 10:26 AM Francesco Giudici
> > mailto:fgiud...@redhat.com>> wrote:
> >
> > Hi David,
> >
> > On 6/11/19 12:24 AM, David Bourgeois wrote:
> >  > Hi,
> >  >
> >  > I can't find the proper configuration to have an always
> > enabled static
> >  > IP address and an optional DHCP address when connected to a
> > network that
> >  > has a DHCP server. My use case is a portable device that
> > connects to
> >  > local embedded devices using a private local LAN so the
> > static IP should
> >  > always be there. When we need to connect on the internet, I
> > would like
> >  > to plug a DHCP enabled connection to the switch and receive a
> > second IP
> >  > automatically from DHCP for this.
> >  >
> >  > I can setup both DHCP and static using this configuration:
> >  > [ipv4]
> >  > address1=10.192.11.10/16 
> > 
> >  > method=auto
> >  >
> >  > The problem is that the whole connection profile will fail if
> > no DHCP
> >  > server is found, the static IP will never be set. As soon as
> > I plug the
> >  > DHCP network, both IP will appear. But I would need the
> > static IP to be
> >  > available from the beginning. I have the same problem if I
> > try the
> >  > ifupdown configuration through /etc/network/interfaces. I had
> > gentoo in
> >  > the past and could achieve this using their RC system, DHCP
> > would be
> >  > assigned to eth0:0 and a static IP to eth0:1. I just can't
> > find a way to
> >  > do this with Network Manager.
> >  >
> >  > Any idea if that's possible with the profile configuration,
> > or if I need
> >  > to use 2 configurations or play with some scripts?
> >
> > I think you can achieve your desired configuration by setting
> > the dhcp
> > timeout value to something really big.
> > As easy as:
> >
> > $ nmcli connection modify $YOUR_CONNECTION_NAME
> > ipv4.dhcp-timeout infinity
> >
> > This way, the connection will keep trying getting an ip from
> > time to
> > time, and will never be teared down.
> >
> > Francesco
> >
> >  >
> >  > Thank you,
> >  > David
> >  >
> >  > ___
> >  > 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

[PATCH] core/pppd-plugin: wait to recover port settings before notifying death

[Alfonso Sánchez-Beato via networkmanager-list]

pppd restores the previous settings for the serial port it uses right
before exiting. It is especially important to do so because otherwise
ModemManager is not able to recover the port as it can receive a hangup
event from the port due to CLOCAL not being restored.  However, there is
currently a race condition that produces this issue. This is because
when PHASE_DEAD is notified, pppd still has not restored the port
settings - it does that a bit later, in the die() function.

This patch delays notifying PHASE_DEAD until when the exitnotify() hook
is called by pppd: when this happens the port settings have already been
restored.

There were previously efforts to fix this in commit fe090c3, so
PHASE_DEAD was used instead of PHASE_DISCONNECT to notify MM that the
port was disconnected, but that still early to ensure that the port
settings are restored.

The MM traces seen when the bug is triggered are:

ModemManager[2158]:   (ttyACM1): could not re-acquire serial port lock: 
(5) Input/output error
ModemManager[2158]:   Couldn't load Operator Code: 'Cannot run sequence: 
'Could not open serial device ttyACM1: it has been forced close'
---
 src/ppp/nm-pppd-plugin.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/src/ppp/nm-pppd-plugin.c b/src/ppp/nm-pppd-plugin.c
index 626dcdbd8..f0b9027ca 100644
--- a/src/ppp/nm-pppd-plugin.c
+++ b/src/ppp/nm-pppd-plugin.c
@@ -51,7 +51,7 @@ static struct {
 } gl;
 
 static void
-nm_phasechange (void *data, int arg)
+nm_phasechange (int arg)
 {
NMPPPStatus ppp_status = NM_PPP_STATUS_UNKNOWN;
char *ppp_phase;
@@ -167,6 +167,16 @@ nm_phasechange (void *data, int arg)
}
 }
 
+static void
+nm_phasechange_hook (void *data, int arg)
+{
+   /* We send the nofication in exitnotify instead */
+   if (arg == PHASE_DEAD)
+   return;
+
+   nm_phasechange (arg);
+}
+
 static void
 nm_ip_up (void *data, int arg)
 {
@@ -181,7 +191,7 @@ nm_ip_up (void *data, int arg)
 
if (!opts.ouraddr) {
g_warning ("nm-ppp-plugin: didn't receive an internal IP from 
pppd!");
-   nm_phasechange (NULL, PHASE_DEAD);
+   nm_phasechange (PHASE_DEAD);
return;
}
 
@@ -384,6 +394,11 @@ nm_exit_notify (void *data, int arg)
 {
g_return_if_fail (G_IS_DBUS_CONNECTION (gl.dbus_connection));
 
+   /* We wait until this point to notify dead phase to make sure that
+* the serial port has recovered already its original settings.
+*/
+   nm_phasechange (PHASE_DEAD);
+
g_message ("nm-ppp-plugin: cleaning up");
 
g_clear_object (&gl.dbus_connection);
@@ -435,7 +450,7 @@ plugin_init (void)
pap_passwd_hook = get_credentials;
pap_check_hook = get_pap_check;
 
-   add_notifier (&phasechange, nm_phasechange, NULL);
+   add_notifier (&phasechange, nm_phasechange_hook, NULL);
add_notifier (&ip_up_notifier, nm_ip_up, NULL);
add_notifier (&exitnotify, nm_exit_notify, NULL);
add_ip6_notifier ();
-- 
2.17.1

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Looking for advice how to start contributing in NetworkManager and implement Hotstpot 2.0 feature for WiFi

[Thomas Haller via networkmanager-list]

On Thu, 2019-06-13 at 14:17 +0600, work vlpl via networkmanager-list
wrote:
> Hello,
> 
> I want to contribute to NetworkManger but don't know where to start,
> so I am looking for advise how I can start it.

Hi,

thanks for reaching out. We would very welcome your help!

> wpa_supplicant supports great feature Hotspot 2.0 and contains in its
> distribution program - osu_client, that allow to do automatic wifi
> configuration provision using protocols and conventions defined in
> Hotspot 2.0 Specification. I want to implement support of this
> feature
> in NetworkManager.
> 
> wpa_supplicant - query AP for information needed for for Hotspot 2.0,
> and act as executor for commands that come from osu_client.
> osu_client - communicate with Online Signup server (parsing response,
> generate payload), enrolling user certificates for EAP-TLS,
> downloading root certificates that will validate certificated
> provided
> by radius servers, saving wifi configuration in xml file and load it
> in wpa_supplicant.
> 
> I have superficially studied how NetworkManager mange wpa_supplicant.
> If I am not wrong it does it using D-Bus.

Correct

> But main features that
> provide Hotspot 2.0 experience located in osu_client program. It is
> the standalone program that communicate with wpa_supplicant using
> control interface /run/wpa_supplicant. I think that it is a viable
> way
> to implement in NetworkManager functionality from osu_client that
> execute wpa_supplicant command, for example `interworking select`.
> But
> I doubt that it is a good idea to implement certificate enrolment in
> NetworkManager.

It sound to me like NetworkManager really would prefer to talk to some
D-Bus API here. Possibly the functionality of osu_client could go into
wpa-supplicant (and exposed on D-Bus), or osu_client could itself be a
D-Bus service. Re-implmenting osu_client in NetworkManager does not
sound preferable... (but maybe it is?? It seems large, but not
extremely large). But talking to a command line tool is also not
preferable...


> So my questions are:
> 
> What features should be implemented in NetworkManager code?

Any features that you deem useful and are willing to contribute :)


> If some functionality is better to keep in separate program, for
> example osu_client, how organise communication between NetworkManager
> and that program? osu_client does not support D-Bus.

Theretically anything you can think of. Including spawning processes or
any protocol via sockets (varlink?). But having a separate service and
a D-Bus API sounds preferable to me. I think it would make it easier
for everybody to talk to this API, so the effort spend there would not
only benefit NetworkManager.

wpa-supplicant itself is a D-Bus activatable service and not spawned by
NetworkManager. That is very nice, because the service is properly
managed (e.g. by systemd) and not by NetworkManager (which would do a
less great job at that).


> Both NetworkManager and osu_client can configure wifi connection, so
> if osu_client will be kept, how to pass wifi configuration? From it,
> or from NetworkManager?



> I which NetworkManager source files I should put new code?

That depends... probably most of it under "src/device/wifi" and some
under "src/supplicant".



You can also find us on IRC (freenode, #nm). See 
https://wiki.gnome.org/Projects/NetworkManager/Hacking (and if you have
questions that are not answered there, maybe we could improve the
wiki).


best,
Thomas



signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Looking for advice how to start contributing in NetworkManager and implement Hotstpot 2.0 feature for WiFi

[work vlpl via networkmanager-list]

Hello,

I want to contribute to NetworkManger but don't know where to start,
so I am looking for advise how I can start it.

wpa_supplicant supports great feature Hotspot 2.0 and contains in its
distribution program - osu_client, that allow to do automatic wifi
configuration provision using protocols and conventions defined in
Hotspot 2.0 Specification. I want to implement support of this feature
in NetworkManager.

wpa_supplicant - query AP for information needed for for Hotspot 2.0,
and act as executor for commands that come from osu_client.
osu_client - communicate with Online Signup server (parsing response,
generate payload), enrolling user certificates for EAP-TLS,
downloading root certificates that will validate certificated provided
by radius servers, saving wifi configuration in xml file and load it
in wpa_supplicant.

I have superficially studied how NetworkManager mange wpa_supplicant.
If I am not wrong it does it using D-Bus. But main features that
provide Hotspot 2.0 experience located in osu_client program. It is
the standalone program that communicate with wpa_supplicant using
control interface /run/wpa_supplicant. I think that it is a viable way
to implement in NetworkManager functionality from osu_client that
execute wpa_supplicant command, for example `interworking select`. But
I doubt that it is a good idea to implement certificate enrolment in
NetworkManager.

So my questions are:

What features should be implemented in NetworkManager code?
If some functionality is better to keep in separate program, for
example osu_client, how organise communication between NetworkManager
and that program? osu_client does not support D-Bus.
Both NetworkManager and osu_client can configure wifi connection, so
if osu_client will be kept, how to pass wifi configuration? From it,
or from NetworkManager?
I which NetworkManager source files I should put new code?

--
Vladimir
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list