Re: ifcfg-rh and wpa_supplicant
On 05/21/2012 05:42 PM, Dan Williams wrote: That device is driven by the ath9k driver, which is one of the better-supported mac80211 chipsets, so it should certainly work with nl80211. If it's not working, then we need to get some supplicant and kernel debugging information to see what's wrong in the driver. What kernel version do you have? Dan Right now I've switched back to a fedora 13 with a self compiled kernel 3.2.13. The wpa_supplicant gets started by /etc/init.d/wpa_supplicant abd definitely uses the -Dwext option. The target I'm aiming for is Fedora16 with kernel 3.3.5-2 but I currently can't use it since wifi does not work Thanks O. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ifcfg-rh and wpa_supplicant
On 05/21/2012 07:02 PM, Dan Williams wrote: Right, so we need to figure out why wifi isn't working on F16. It should work, and it should work well with nl80211. WEXT is deprecated and will be removed from upstream kernels in the future. ath9k is actively developed upstream and any issues are usually fixed pretty quickly. Are there any interesting messages in 'dmesg' output for your wifi card? Is your access point 802.11n-enabled? Is it using 40MHz wide channels? Dan Don't know how to figure out the 40MHz issue. (A) Here comes the dmesg part around ath9k initialization in Fedora12/Linux 3.2.13 snip ath9k :04:00.0: PCI INT A - Link[LN3A] - GSI 18 (level, low) - IRQ 18 ath9k :04:00.0: setting latency timer to 64 ... ... ath: EEPROM regdomain: 0x60 ath: EEPROM indicates we should expect a direct regpair map ath: Country alpha2 being used: 00 ath: Regpair used: 0x60 ... ... ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' Registered led device: ath9k-phy0 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xff56, irq=18 /snip and the iwconfig stuff: snip wlan0 IEEE 802.11bgn ESSID:oncaphillis Mode:Managed Frequency:2.442 GHz Access Point: 00:25:9C:D0:04:FB Bit Rate=54 Mb/s Tx-Power=16 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=45/70 Signal level=-65 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:90 Missed beacon:0 /snip (B) The same stuff for Fedora16/Linux 3.3.6 snip [8.398499] ath: EEPROM regdomain: 0x60 [8.398507] ath: EEPROM indicates we should expect a direct regpair map [8.398517] ath: Country alpha2 being used: 00 [8.398523] ath: Regpair used: 0x60 [8.422729] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' [8.423924] Registered led device: ath9k-phy0 [ 12.209542] wlan0: authenticate with 00:25:9c:d0:04:fb (try 1) [ 12.211621] wlan0: authenticated [ 12.211720] wlan0: associate with 00:25:9c:d0:04:fb (try 1) [ 12.214487] wlan0: RX AssocResp from 00:25:9c:d0:04:fb (capab=0x411 status=0 aid=2) [ 12.214500] wlan0: associated [ 12.214512] wlan0: moving STA 00:25:9c:d0:04:fb to state 1 [ 12.214520] wlan0: moving STA 00:25:9c:d0:04:fb to state 2 [ 12.214529] wlan0: moving STA 00:25:9c:d0:04:fb to state 3 [ 12.215576] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready /snip snip wlan0 IEEE 802.11bgn ESSID:oncaphillis Mode:Managed Frequency:2.442 GHz Access Point: 00:25:9C:D0:04:FB Bit Rate=54 Mb/s Tx-Power=16 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=57/70 Signal level=-53 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:54 Missed beacon:0 /snip This however after I switched back to the old network/wpa_supplicant scripts. O. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ifcfg-rh and wpa_supplicant
On 05/18/2012 11:23 PM, Dan Williams wrote: On Thu, 2012-05-17 at 09:58 +0200, Oncaphillis wrote: Hi, I'm using Fedora16 and I'm trying to set up NetworkManager to connect to a wlan on startup via /etc/sysconfig/network-scrip/ifcfg-wlan0 or /etc/sysconfig/network-scrip/ifcfg-ESSID. It seems the settings in /etc/sysconfig/wpa_supplicant are ignored if wpa_supplicant is managed by the NetworkManager,but I don't see any option to pass the -Ddriver option to wpa_supplicant. Correct, the settings in /etc/sysconfig/wpa_supplicant can be harmful when NetworkManager is used, because NetworkManager figures out whether to use the wext, nl80211, or wired driver as appropriate. What's the reason you want to use a specific supplicant driver? Dan Simply the observation that wpa_supplicant fails to associate when not using -Dwext Thanks O. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ifcfg-rh and wpa_supplicant
On 05/19/2012 03:43 AM, Dan Williams wrote: On Fri, 2012-05-18 at 23:39 +0200, Oncaphillis wrote: On 05/18/2012 11:23 PM, Dan Williams wrote: On Thu, 2012-05-17 at 09:58 +0200, Oncaphillis wrote: Hi, I'm using Fedora16 and I'm trying to set up NetworkManager to connect to a wlan on startup via /etc/sysconfig/network-scrip/ifcfg-wlan0 or /etc/sysconfig/network-scrip/ifcfg-ESSID. It seems the settings in /etc/sysconfig/wpa_supplicant are ignored if wpa_supplicant is managed by the NetworkManager,but I don't see any option to pass the -Ddriver option to wpa_supplicant. Correct, the settings in /etc/sysconfig/wpa_supplicant can be harmful when NetworkManager is used, because NetworkManager figures out whether to use the wext, nl80211, or wired driver as appropriate. What's the reason you want to use a specific supplicant driver? Dan Simply the observation that wpa_supplicant fails to associate when not using -Dwext What wifi kernel driver? snip 04:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PC Subsystem: Device 1a3b:1067 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at febf (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [90] MSI-X: Enable- Count=1 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: ath9k Kernel modules: ath9k /snip I got the source rpm at hand. If someone points me to the position where the correct driver gets determined I can patch it. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
ifcfg-rh and wpa_supplicant
Hi, I'm using Fedora16 and I'm trying to set up NetworkManager to connect to a wlan on startup via /etc/sysconfig/network-scrip/ifcfg-wlan0 or /etc/sysconfig/network-scrip/ifcfg-ESSID. It seems the settings in /etc/sysconfig/wpa_supplicant are ignored if wpa_supplicant is managed by the NetworkManager,but I don't see any option to pass the -Ddriver option to wpa_supplicant. How do I solve this ? Thanks ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH/Feature request
On 01/25/2012 09:19 PM, Dan Williams wrote:
On Mon, 2012-01-23 at 10:18 +0100, Oncaphillis wrote:
Hi,
Please find attached a patch against the current git
which re-enables DHCP/DNS Name transmission including
domain suffix as an option.
I have a rather dim DSL router with DHCP function
which doesn't accept any domain specific options
but allows for the transmission of a full hostname
via the send host-name command. I use the domain name
to distinguish between my VPN connection and the rest
of the world. So I used to add the full hostname
for NetworkManager. Now it chops off the
domain suffix before transmission.
The attached patch adds a property dhcp-with-domain
to NetworkManager which disables this behaviour when true.
In addition the ifcfg-rh plugin enables this feature
if it finds the DHCP_WITH_DOMAIN=yes line in the corresponding
ifcfg-xxx file.
Just to clarify, you used to set your persistent system hostname to say
mycomputer.foobar.org and NM used to send that entire hostname to the
router, correct? I know we changed it a while ago to only send the
hostname excluding the domain portion. However, I think we should only
strip the hostname when we're using the system hostname. If the user
manually specifies a name in dhclient-xxx.conf or in the connection
settings, then I think we should send exactly what the user entered.
That needs a bit of work though; we need to adjust the NMDhcpClient
class to take two hostnames to the client_start() function, one for the
system hostname and one for the hostname from the
Hows about the attached patch ? It moves the decision to chop off the
domain part into nm_dhcp_manager_start_ip4 where we can decide if the
hostname came from the nm config or the system settings.
NMSettingIP4Config/NMSettingIP6Config. Then internally
nm-dhcp-dhclient.c would know whether to strip the system hostname (if
the hostname from settings is missing) or to use the configured hostname
verbatim. The original bug for stripping the hostname is rh#694758.
Dan
diff --git a/src/dhcp-manager/nm-dhcp-dhclient-utils.c b/src/dhcp-manager/nm-dhcp-dhclient-utils.c
index caf90f1..b2f49b4 100644
--- a/src/dhcp-manager/nm-dhcp-dhclient-utils.c
+++ b/src/dhcp-manager/nm-dhcp-dhclient-utils.c
@@ -166,19 +166,8 @@ nm_dhcp_dhclient_create_config (const char *interface,
}
if (hostname) {
- char *plain_hostname, *dot;
-
- plain_hostname = g_strdup (hostname);
- dot = strchr (plain_hostname, '.');
-
- /* get rid of the domain */
- if (dot)
-*dot = '\0';
-
- g_string_append_printf (new_contents, HOSTNAME_FORMAT \n, plain_hostname);
+ g_string_append_printf (new_contents, HOSTNAME_FORMAT \n, hostname);
added = TRUE;
-
- g_free (plain_hostname);
}
if (added)
diff --git a/src/dhcp-manager/nm-dhcp-manager.c b/src/dhcp-manager/nm-dhcp-manager.c
index e65f693..e8ef3ca 100644
--- a/src/dhcp-manager/nm-dhcp-manager.c
+++ b/src/dhcp-manager/nm-dhcp-manager.c
@@ -466,8 +466,9 @@ nm_dhcp_manager_start_ip4 (NMDHCPManager *self,
guint8 *dhcp_anycast_addr)
{
NMDHCPManagerPrivate *priv;
- NMDHCPClient *client = NULL;
- const char *hostname = NULL;
+ NMDHCPClient *client = NULL;
+ const char *hostname = NULL;
+ char *chopped_hostname = NULL;
g_return_val_if_fail (self, NULL);
g_return_val_if_fail (NM_IS_DHCP_MANAGER (self), NULL);
@@ -493,16 +494,32 @@ nm_dhcp_manager_start_ip4 (NMDHCPManager *self,
*/
if (!hostname priv-hostname_provider) {
hostname = nm_hostname_provider_get_hostname (priv-hostname_provider);
+
if ( hostname
(!strcmp (hostname, localhost.localdomain) ||
!strcmp (hostname, localhost6.localdomain6)))
hostname = NULL;
+else
+{
+ char * dot = NULL;
+ chopped_hostname = g_strdup (hostname);
+ dot = strchr (chopped_hostname, '.');
+
+ /* get rid of the domain */
+ if (dot)
+ *dot = '\0';
+ hostname = chopped_hostname;
+}
}
}
}
client = client_start (self, iface, uuid, FALSE, s_ip4, NULL, timeout, dhcp_anycast_addr, hostname, FALSE);
+ if(chopped_hostname)
+ {
+ g_free (chopped_hostname);
+ }
return client;
}
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH/Feature request
On 01/25/2012 09:19 PM, Dan Williams wrote: On Mon, 2012-01-23 at 10:18 +0100, Oncaphillis wrote: Hi, Please find attached a patch against the current git which re-enables DHCP/DNS Name transmission including domain suffix as an option. I have a rather dim DSL router with DHCP function which doesn't accept any domain specific options but allows for the transmission of a full hostname via the send host-name command. I use the domain name to distinguish between my VPN connection and the rest of the world. So I used to add the full hostname for NetworkManager. Now it chops off the domain suffix before transmission. The attached patch adds a property dhcp-with-domain to NetworkManager which disables this behaviour when true. In addition the ifcfg-rh plugin enables this feature if it finds the DHCP_WITH_DOMAIN=yes line in the corresponding ifcfg-xxx file. Just to clarify, you used to set your persistent system hostname to say mycomputer.foobar.org and NM used to send that entire hostname to the router, correct? Yes -- I was pretty sure that sending a FQDN breaks some rules but it used to work on my router and allows me to give all my home machine my own private domain. I know we changed it a while ago to only send the hostname excluding the domain portion. However, I think we should only strip the hostname when we're using the system hostname. If the user manually specifies a name in dhclient-xxx.conf or in the connection settings, then I think we should send exactly what the user entered. Does 'should' mean that it is current behaviour ? That doesn't seem to be the case. Explicitly setting DHCP_HOSTNAME in the ifcfg-xxx file doesn't change anything at all. The domain gets chopped of. nm-dhcp-dhclient-util.c doesn't seem to care where the hostname came from and if it has been provided with a valid hostname it filters out any send host-name statements in the /etc/dhclient-xxx.conf file. That needs a bit of work though; we need to adjust the NMDhcpClient class to take two hostnames to the client_start() function, one for the system hostname and one for the hostname from the NMSettingIP4Config/NMSettingIP6Config. Then internally nm-dhcp-dhclient.c would know whether to strip the system hostname (if the hostname from settings is missing) or to use the configured hostname verbatim. The original bug for stripping the hostname is rh#694758. And then you still have to decide if you allow the send host-name command to take place with the FQDN or to build your own sequence of fqdn commands (which my router doesn't seem to understand). thanks or the reply Sebastian ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH/Feature request
On 01/26/2012 01:27 AM, Dan Williams wrote: On Thu, 2012-01-26 at 00:00 +0100, Oncaphillis wrote: On 01/25/2012 09:19 PM, Dan Williams wrote: On Mon, 2012-01-23 at 10:18 +0100, Oncaphillis wrote: Hi, Please find attached a patch against the current git which re-enables DHCP/DNS Name transmission including domain suffix as an option. I have a rather dim DSL router with DHCP function which doesn't accept any domain specific options but allows for the transmission of a full hostname via the send host-name command. I use the domain name to distinguish between my VPN connection and the rest of the world. So I used to add the full hostname for NetworkManager. Now it chops off the domain suffix before transmission. The attached patch adds a property dhcp-with-domain to NetworkManager which disables this behaviour when true. In addition the ifcfg-rh plugin enables this feature if it finds the DHCP_WITH_DOMAIN=yes line in the corresponding ifcfg-xxx file. Just to clarify, you used to set your persistent system hostname to say mycomputer.foobar.org and NM used to send that entire hostname to the router, correct? Yes -- I was pretty sure that sending a FQDN breaks some rules but it used to work on my router and allows me to give all my home machine my own private domain. I know we changed it a while ago to only send the hostname excluding the domain portion. However, I think we should only strip the hostname when we're using the system hostname. If the user manually specifies a name in dhclient-xxx.conf or in the connection settings, then I think we should send exactly what the user entered. Does 'should' mean that it is current behaviour ? That doesn't seem to be the case. Explicitly setting DHCP_HOSTNAME in the ifcfg-xxx file doesn't change anything at all. The domain gets chopped of. nm-dhcp-dhclient-util.c doesn't seem to care where the hostname came from and if it has been provided with a valid hostname it filters out any send host-name statements in the /etc/dhclient-xxx.conf file. By should I meant that it doesn't do that, but we should fix it to do so. Sorry for the ambiguous terminology. That needs a bit of work though; we need to adjust the NMDhcpClient class to take two hostnames to the client_start() function, one for the system hostname and one for the hostname from the NMSettingIP4Config/NMSettingIP6Config. Then internally nm-dhcp-dhclient.c would know whether to strip the system hostname (if the hostname from settings is missing) or to use the configured hostname verbatim. The original bug for stripping the hostname is rh#694758. And then you still have to decide if you allow the send host-name command to take place with the FQDN or to build your own sequence of fqdn commands (which my router doesn't seem to understand). The end goal here is to update your DDNS entries, right? AFAIK that's what the FQDN option is typically used for. Is that what you'd use the hostname option for as well? rantIt kinda sucks that dhclient doesn't pick which one to use; ie if it had a policy like if the hostname given ends in a . then it's fully-qualified and we send FQDN then we wouldn't need to choose between FQDN and hostname. Second, there's the whacky options for FQDN like encoded and server-update which of course we have no idea what to do with and aren't going to expose in any UI. ... and if dhclient would automatically choose the 'right' method it would be totally useless in cases where the dhcp server doesn't understand the FQDN command. In my case it just would have been enough if the nm-dhcp-manager wouldn't overwrite the send host-name option from the /etc/dhclient-xxx.conf file. The strategy that one might specify a FQDN in the NetworkManagers configuration and trigger the transfer this way sounds good. Then may be we need an additional option like SEND_AS_PLAIN_HOSTNAME where the nm-dhcp-manager can decide if it tells dhclient to use the send fqdn.fqdn or the send host-name command. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
PATCH/Feature request
Hi,
Please find attached a patch against the current git
which re-enables DHCP/DNS Name transmission including
domain suffix as an option.
I have a rather dim DSL router with DHCP function
which doesn't accept any domain specific options
but allows for the transmission of a full hostname
via the send host-name command. I use the domain name
to distinguish between my VPN connection and the rest
of the world. So I used to add the full hostname
for NetworkManager. Now it chops off the
domain suffix before transmission.
The attached patch adds a property dhcp-with-domain
to NetworkManager which disables this behaviour when true.
In addition the ifcfg-rh plugin enables this feature
if it finds the DHCP_WITH_DOMAIN=yes line in the corresponding
ifcfg-xxx file.
Cheers
Sebastian
diff --git a/libnm-util/libnm-util.ver b/libnm-util/libnm-util.ver
index 4d14082..ef6bceb 100644
--- a/libnm-util/libnm-util.ver
+++ b/libnm-util/libnm-util.ver
@@ -258,6 +258,7 @@ global:
nm_setting_ip4_config_get_dhcp_client_id;
nm_setting_ip4_config_get_dhcp_hostname;
nm_setting_ip4_config_get_dhcp_send_hostname;
+ nm_setting_ip4_config_get_dhcp_with_domain;
nm_setting_ip4_config_get_dns;
nm_setting_ip4_config_get_dns_search;
nm_setting_ip4_config_get_ignore_auto_dns;
diff --git a/libnm-util/nm-setting-ip4-config.c b/libnm-util/nm-setting-ip4-config.c
index 6b164ea..9c6b40f 100644
--- a/libnm-util/nm-setting-ip4-config.c
+++ b/libnm-util/nm-setting-ip4-config.c
@@ -101,6 +101,7 @@ typedef struct {
gboolean ignore_auto_dns;
char *dhcp_client_id;
gboolean dhcp_send_hostname;
+ gboolean dhcp_with_domain;
char *dhcp_hostname;
gboolean never_default;
gboolean may_fail;
@@ -117,6 +118,7 @@ enum {
PROP_IGNORE_AUTO_DNS,
PROP_DHCP_CLIENT_ID,
PROP_DHCP_SEND_HOSTNAME,
+ PROP_DHCP_WITH_DOMAIN,
PROP_DHCP_HOSTNAME,
PROP_NEVER_DEFAULT,
PROP_MAY_FAIL,
@@ -640,10 +642,18 @@ gboolean
nm_setting_ip4_config_get_dhcp_send_hostname (NMSettingIP4Config *setting)
{
g_return_val_if_fail (NM_IS_SETTING_IP4_CONFIG (setting), FALSE);
-
return NM_SETTING_IP4_CONFIG_GET_PRIVATE (setting)-dhcp_send_hostname;
}
+gboolean
+nm_setting_ip4_config_get_dhcp_with_domain (NMSettingIP4Config *setting)
+
+{
+ g_return_val_if_fail (NM_IS_SETTING_IP4_CONFIG (setting), FALSE);
+
+ return NM_SETTING_IP4_CONFIG_GET_PRIVATE (setting)-dhcp_with_domain;
+}
+
/**
* nm_setting_ip4_config_get_dhcp_hostname:
* @setting: the #NMSettingIP4Config
@@ -890,6 +900,9 @@ set_property (GObject *object, guint prop_id,
case PROP_DHCP_SEND_HOSTNAME:
priv-dhcp_send_hostname = g_value_get_boolean (value);
break;
+ case PROP_DHCP_WITH_DOMAIN:
+ priv-dhcp_with_domain = g_value_get_boolean (value);
+ break;
case PROP_DHCP_HOSTNAME:
g_free (priv-dhcp_hostname);
priv-dhcp_hostname = g_value_dup_string (value);
@@ -944,6 +957,9 @@ get_property (GObject *object, guint prop_id,
case PROP_DHCP_SEND_HOSTNAME:
g_value_set_boolean (value, nm_setting_ip4_config_get_dhcp_send_hostname (setting));
break;
+ case PROP_DHCP_WITH_DOMAIN:
+ g_value_set_boolean (value, nm_setting_ip4_config_get_dhcp_with_domain (setting));
+ break;
case PROP_DHCP_HOSTNAME:
g_value_set_string (value, nm_setting_ip4_config_get_dhcp_hostname (setting));
break;
@@ -1202,6 +1218,15 @@ nm_setting_ip4_config_class_init (NMSettingIP4ConfigClass *setting_class)
TRUE,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT | NM_SETTING_PARAM_SERIALIZE));
+ g_object_class_install_property
+ (object_class, PROP_DHCP_WITH_DOMAIN,
+ g_param_spec_boolean (NM_SETTING_IP4_CONFIG_DHCP_WITH_DOMAIN,
+ Send DHCP hostname with domain suffix,
+ If TRUE, a hostname sent to the DHCP server will include
+ the domain suffix if available. ,
+ TRUE,
+ G_PARAM_READWRITE | G_PARAM_CONSTRUCT | NM_SETTING_PARAM_SERIALIZE));
+
/**
* NMSettingIP4Config:dhcp-hostname:
*
diff --git a/libnm-util/nm-setting-ip4-config.h b/libnm-util/nm-setting-ip4-config.h
index 76dcf37..9dd2a55 100644
--- a/libnm-util/nm-setting-ip4-config.h
+++ b/libnm-util/nm-setting-ip4-config.h
@@ -69,8 +69,9 @@ GQuark nm_setting_ip4_config_error_quark (void);
#define NM_SETTING_IP4_CONFIG_IGNORE_AUTO_ROUTES ignore-auto-routes
#define NM_SETTING_IP4_CONFIG_IGNORE_AUTO_DNSignore-auto-dns
#define NM_SETTING_IP4_CONFIG_DHCP_CLIENT_ID dhcp-client-id
-#define NM_SETTING_IP4_CONFIG_DHCP_SEND_HOSTNAME dhcp-send-hostname
#define NM_SETTING_IP4_CONFIG_DHCP_HOSTNAME dhcp-hostname
+#define NM_SETTING_IP4_CONFIG_DHCP_SEND_HOSTNAME dhcp-send-hostname
+#define NM_SETTING_IP4_CONFIG_DHCP_WITH_DOMAIN dhcp-with-domain
#define NM_SETTING_IP4_CONFIG_NEVER_DEFAULT never-default
#define NM_SETTING_IP4_CONFIG_MAY_FAIL may-fail
@@ -208,7 +209,6 @@ void nm_setting_ip4_config_clear_addresses(NMSettingIP4Config *
guint32 nm_setting_ip4_config_get_num_routes (NMSettingIP4Config *setting);
NMIP4Route *
