[PATCH] RFC: fall back to IPv4-LL in case of DHCP failure
In some cases, it is useful to have a static configuration which succeeds
to configure a network interface regardless of whether a DHCP server
is available or not. One such use-case is an embedded system with
factory default settings, which would fall back to IPv4-LL when
connected directly to the notebook of a field engineer.
With this patch, when DHCP reports a timeout, the connection attempt
is restart with phase 3 of autoipd-based IPv4 Link-Local configuration.
For now this behaviour is hard-coded, but I'd make it configurable
if this approach is acceptable.
For configuration, a new IPv4 method could be added (either a new
'Automatic with fall back' or 'DHCP only', making enabled fall back
the default in 'Automatic'). Alternatively an option could be added
to the IPv4 configuration (i.e. 'll-fall-back=true').
Best regards,
Jan Luebbe
---
src/nm-device.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/src/nm-device.c b/src/nm-device.c
index 6eaa94d..886d5bc 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -204,9 +204,10 @@ typedef struct {
DBusGProxyCall*fw_call;
/* avahi-autoipd stuff */
- GPidaipd_pid;
- guint aipd_watch;
- guint aipd_timeout;
+ GPid aipd_pid;
+ guintaipd_watch;
+ guintaipd_timeout;
+ gboolean aipd_failed;
/* IP6 configuration info */
NMIP6Config * ip6_config;
@@ -1262,6 +1263,8 @@ aipd_cleanup (NMDevice *self)
}
aipd_timeout_remove (self);
+
+ priv-aipd_failed = FALSE;
}
static NMIP4Config *
@@ -1331,7 +1334,8 @@ nm_device_handle_autoip4_event (NMDevice *self,
if (s_ip4)
method = nm_setting_ip4_config_get_method (s_ip4);
- if (g_strcmp0 (method, NM_SETTING_IP4_CONFIG_METHOD_LINK_LOCAL) != 0)
+ if ( g_strcmp0 (method, NM_SETTING_IP4_CONFIG_METHOD_LINK_LOCAL) != 0
+g_strcmp0 (method, NM_SETTING_IP4_CONFIG_METHOD_AUTO) != 0)
return;
iface = nm_device_get_iface (self);
@@ -1423,6 +1427,7 @@ aipd_timeout_cb (gpointer user_data)
nm_log_info (LOGD_AUTOIP4, (%s): avahi-autoipd timed out.,
nm_device_get_iface (self));
priv-aipd_timeout = 0;
aipd_cleanup (self);
+ priv-aipd_failed = TRUE;
if (priv-ip4_state == IP_CONF)
nm_device_activate_schedule_ip4_config_timeout (self);
@@ -2499,6 +2504,21 @@ nm_device_activate_schedule_stage3_ip_config_start
(NMDevice *self)
static NMActStageReturn
real_act_stage4_ip4_config_timeout (NMDevice *self, NMDeviceStateReason
*reason)
{
+ NMDevicePrivate *priv = NM_DEVICE_GET_PRIVATE (self);
+ NMConnection *connection;
+ NMSettingIP4Config *s_ip4;
+ const char *method;
+
+ connection = nm_device_get_connection (self);
+ g_assert (connection);
+
+ s_ip4 = nm_connection_get_setting_ip4_config (connection);
+ g_assert (s_ip4);
+
+ method = nm_setting_ip4_config_get_method (s_ip4);
+ if ( strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_AUTO) == 0
+!priv-aipd_failed)
+ return aipd_start (self, reason);
if (nm_device_ip_config_should_fail (self, FALSE)) {
*reason = NM_DEVICE_STATE_REASON_IP_CONFIG_UNAVAILABLE;
return NM_ACT_STAGE_RETURN_FAILURE;
--
1.7.10
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
configuring bonding using NetworkManager-0.9.4 in Fedora 17
Hello,
I am trying to configure bonding using NetworkManager in Fedora 17. Fedora 17
has NetworkManager-0.9.4. The configuration files look like the following -
Under /etc/sysconfig/network-scripts/
# cat ifcfg-bond0
DEVICE=bond0
BOOTPROTO=dhcp
ONBOOT=yes
NM_CONTROLLED=yes
BONDING_MASTER=yes
BONDING_OPTS=miimon=50 mode=balance-tlb
# cat ifcfg-em3
BOOTPROTO=none
DEVICE=em3
ONBOOT=yes
MASTER=bond0
SLAVE=yes
TYPE=Ethernet
NM_CONTROLLED=yes
After restarting the NetworkManager, i have the following observations -
1. The bonding device bond0 does not have a MAC Id set
2. The slave device as mentioned in the ifcfg-em3 is not enslaved
3. The bond0 has the miimon and mode as described in the BONDING_OPTS set.
# ip addr show dev bond0
20: bond0: NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP mtu 1500 qdisc noqueue
state DOWN
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
# cat /sys/class/net/bond0/bonding/slaves
-
## cat /sys/class/net/bond0/bonding/{miimon,mode}
50
balance-tlb 5
I am trying to get familiar with NetworkManager, and putting some prints in
'src/nm-device-bond.c' to find more details on points 1 and 2. It would be
great if you could point out if I am missing some aspect as part of
configuration.
With regards,
Narendra K
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Linux MBIM
On Sun, Jul 15, 2012 at 10:13 PM, Aleksander Morgado aleksan...@lanedo.comwrote: Hey Greg, I was wondering if there's any effort going on to support MBIM devices on Linux? No plans yet for ModemManager (see thread [1]). Is there any device out there which already supports that protocol? Cheers, [1] https://mail.gnome.org/**archives/networkmanager-list/** 2011-November/msg00352.htmlhttps://mail.gnome.org/archives/networkmanager-list/2011-November/msg00352.html -- Aleksander Hi Aleksander, I've seen that thread but I just wanted to throw the question out there since the thread was from last year. I believe a MBIM device should be coming out later this year. Thanks, Greg ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Linux MBIM
On Mon, Jul 16, 2012 at 12:28 AM, Bjørn Mork bj...@mork.no wrote: Aleksander Morgado aleksan...@lanedo.com writes: I was wondering if there's any effort going on to support MBIM devices on Linux? No plans yet for ModemManager (see thread [1]). Is there any device out there which already supports that protocol? Cheers, [1] https://mail.gnome.org/archives/networkmanager-list/2011-November/msg00352.html If I understand this correctly, MBIM devices will combine CDC NCM with a MBIM control channel in the exact same way QMI devices combine CDC ECM with a QMI control channel. That means that the driver support could be done as simple as combining cdc_ncm with the cdc_wdm subdriver (either in the existing cdc_ncm driver, or as a new separate driver reusing code from cdc_ncm). If this was done, then we would have the MBIM control channel exported to userspace as a /dev/cdc-wdmX device, exactly like qmi_wwan exports its QMI control channel. Leaving MBIM control protocol implementation for userspace make sense for the same reasons it made sense to leave QMI implementation for userspace. Boy, am I happy Marcel and others convinced me to do that :-) I was on the same line of thinking but wasn't aware of the QMI driver. Could you point out its location to me? Hmm, I see now The only difference is that instead of transporting Ethernet frames, MBIM transports raw IP data streams. So we definitely need a new driver based on cdc_ncm. Exporting and reusing a bit of cdc_ncm would probably make most sense. And it might also be necessary to extend the cdc_wdm subdriver interface if the cdc_ncm driver need to see the USB_CDC_NOTIFY_NETWORK_CONNECTION and USB_CDC_NOTIFY_SPEED_CHANGE notifications, or if it needs to send any control messages after the probe phase. Don't know if it does. Doesn't really look like it… All this should still be a piece of cake to stitch together. If there had been any devices, that is. So, no, I don't know of any effort to support MBIM on Linux. There just isn't any need for it yet. The basic kernel driver support can be added in a few weeks if necessary. See also the reply from Torgny Johansson in the thread Aleksander refer to, pointing to this press release: http://www.ericsson.com/news/111201_ericsson_to_phase_out_pc_modules_for_mobile_broadband_access_244188808_c I am guessing here, but the whole MBIM thing looks like it was driven by Ericsson, and it might just not happen when they have put it on hold. Qualcomm are likely to be happy with their current QMI approach. Not sure what value they would see in replacing that with a new standardized protocol, if they are going to be the only ones using the new protocol... Others? Microsoft? Yes, I guess they could drive this if they decided that MBIM is the RNDIS of wwan devices. Maybe they will?? A question back to you, Greg: Why do you ask? I ask because I've been assigned to either come up with a MBIM driver or help with an existing effort. Do you know of any device? Or planned device? Where can I get one? :-) I should be getting a dev board sometime in the next few weeks. I don't even know the manufacturer. Where can you get one? no idea. Bjørn Thanks, Greg ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Linux MBIM
Greg Suarez gpsuarez2...@gmail.com writes: On Mon, Jul 16, 2012 at 12:28 AM, Bjørn Mork bj...@mork.no wrote: If I understand this correctly, MBIM devices will combine CDC NCM with a MBIM control channel in the exact same way QMI devices combine CDC ECM with a QMI control channel. That means that the driver support could be done as simple as combining cdc_ncm with the cdc_wdm subdriver (either in the existing cdc_ncm driver, or as a new separate driver reusing code from cdc_ncm). If this was done, then we would have the MBIM control channel exported to userspace as a /dev/cdc-wdmX device, exactly like qmi_wwan exports its QMI control channel. Leaving MBIM control protocol implementation for userspace make sense for the same reasons it made sense to leave QMI implementation for userspace. Boy, am I happy Marcel and others convinced me to do that :-) I was on the same line of thinking but wasn't aware of the QMI driver. Could you point out its location to me? It's in mainline from 3.4: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/net/usb/qmi_wwan.c The approach is pretty simple: Reuse the existing cdc_wdm driver as a subdriver, giving it full ownership of the status interrupt endpoint. cdc_wdm exports whatever protocol is encapsulated in CDC directly as a character device. The driver does not care about the contents at all, leaving that to userspace. The bulk endpoints are handled by a normal usbnet based minidriver. The only difference from any other minidriver like cdc_ether, is that the status endpoint is unavailable. But the CDC notifications are pretty useless anyway, when you have access to a full management protocol like QMI or MBIM. The exact same should work equally well for MBIM. The network driver part must of course be different, and a lot more complex. But most of it is already done in cdc_ncm. Add push/pull of an ethernet pseudo-header to make the raw IP packets appear as ethernet (there are other options, but I believe adding a dummy header is best), and the registration of the subdriver, and that's it! Execpt of course for everything I forgot :-) If I had a device, I would have started with a very simple usbnet + cdc_wdm driver, verifying that userspace access to the MBIM protocol worked as assumed. In fact, qmi_wwan qualifies as that simple driver. Just add a MBIM class matching rule there and go test MBIM management from userspace. The network interface will of course be non-functional. To add support for that, I would look thoroughly at cdc_ncm to find out which parts could be reused and how to best do that without copying any code. Then I would start exporting the parts of cdc_ncm that I needed and integrate them in the new driver. Another approach, which might result in simpler code and therefore be better, would be adding a few extra functions to cdc_ncm and just add another driver instance there for MBIM. Might be best, given the amount of code that could and should be shared between these two drivers. Last, there is the question of whether you should bother with the Microsoft specific descriptors (the magic 0xee string descriptor and it's friends) or not. I don't think that is necessary, and there are some reasons to stay away. But then I haven't seen a MBIM device yet. Could be that you need those descriptors to figure out the different settings, in particular how to enable the alternate functions. A question back to you, Greg: Why do you ask? I ask because I've been assigned to either come up with a MBIM driver or help with an existing effort. Ah, good. Then that's solved :-) May I ask who assigns such fun tasks? Do you know of any device? Or planned device? Where can I get one? :-) I should be getting a dev board sometime in the next few weeks. I don't even know the manufacturer. Where can you get one? no idea. OK. I'll see what pops up. Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
network-manager-openvpn still not meet everyone's needs
Hello ! Using natty with backports and natty-bleed-ppa repositories enabled. When somebody try to load a custom openvpn config file, unwanted options are set (eg: redirect-gateway def1), then we could suppose other ones are maybe discarded (since the opposite is true).. When somebody import a custom config file, we could believe he expect that it will be used as is... not you ? ... there should be an option for it. (it could also allow using server configurations - though i didnt check if it was not yet working) At least, default gateway or dns requests redirection should be optional. In the meanwhile, 2 years after I mentioned it for the first time, we still need to use /etc/openvpn and crontab to checkvpn ... *sigh* Take a look at Tunneblick (it rocks) for OSuX.. (allowing to look at the log and edit the configuration file, beside the gui) Regards, :7üC: ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
