At some places, we considered a default route to be a route with
destination network 0.0.0.0 (::). This is wrong because a default route
is a route with plen==0.
This is for example relevant for OpenVPN which adds two routes
0.0.0.0/1 and 128.0.0.0/1 to hijack the default route. We should
not treat 0.0.0.0/1 as default route, instead NM should treat
it as any other subnet route (even if it effectively routes large
parts).
Signed-off-by: Thomas Haller <thaller@redhat.com>
The next-hop should always be set to route->gateway. Just as
it is done in the IPv4 case too.
This bug only affected routes to '::/p via gateway', with a
non-zero gateway and p > 0. That is a quite uncommon case, because
usually non-default routes have not a net-part all zero.
Signed-off-by: Thomas Haller <thaller@redhat.com>
gcc warns:
make[4]: Entering directory `/data/src/NetworkManager/src'
CC nm-device.lo
In file included from devices/nm-device.c:73:0:
../src/config/nm-config.h:61:13: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
const guint nm_config_get_connectivity_interval (NMConfig *config);
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
Since previous commit dafe51e881,
the gtk-doc is no longer ignored. However, the angle brackets
add invalid XML characters to ./docs/libnm-glib/xml/nm-client.xml
This breaks the build.
make[3]: Entering directory `./NetworkManager/docs/libnm-glib'
DOC Scanning header files
DOC Introspecting gobjects
DOC Building HTML
../xml/nm-client.xml:1110: parser error : Opening and ending tag mismatch: NMActiveConnection line 1109 and para
</para></refsect2>
^
../xml/nm-client.xml:1110: parser error : Opening and ending tag mismatch: para line 1107 and refsect2
</para></refsect2>
^
../xml/nm-client.xml:1211: parser error : Opening and ending tag mismatch: refsect2 line 1104 and refsect1
</refsect1>
^
../xml/nm-client.xml:1262: parser error : Opening and ending tag mismatch: refsect1 line 1095 and refentry
</refentry>
^
../xml/nm-client.xml:1263: parser error : Premature end of data in tag refentry line 7
^
../libnm-glib-docs.xml:67: element include: XInclude error : could not load ../xml/nm-client.xml, and no fallback was found
make[3]: *** [html-build.stamp] Error 6
Signed-off-by: Thomas Haller <thaller@redhat.com>
Some libnm-glib object properties were only documented in the
GParamSpec strings, not via gtk-doc comments, so they became
undocumented when the paramspec strings went away. Fix that.
(Also fix incorrect gtk-doc syntax with several NMClient properties.)
When SELinux is disabled, getfscreatecon() fails leaving se_ctx_prev undefined
and then later freecon (se_ctx_prev) fails with a crash. Initializing
se_ctx_prev to NULL fixes the crash. (It is fine to pass NULL context to
setfscreatecon()).
Testcase:
1) Enable ifcfg-rh plugin in /etc/NetworkManger/NetworkManger.conf
plugins=ifcfg-rh
2) Edit /etc/sysconfig/selinux to contain
SELINUX=disabled
3) Reboot
4) Set hostname via nmcli, nmtui or D-Bus SaveHostname() call
5) NM crashes
https://bugzilla.redhat.com/show_bug.cgi?id=1122826
If no APN is specified, passing "" to ModemManager indicates that
the connection should use the default subscription APN, which the
modem and the network determine themselves. This doesn't work
with all modems and operators, but in that case the user can
specify the APN.
In commit 215306f5 [1], NetworkManager was changed to require an APN for GSM
connections; previously, an omitted APN was taken as "use the default APN
for this device".
ModemManager supports this behaviour with an empty APN string; older
NetworkManager versions support this behaviour with no APN in the
settings. Choose the older NM behaviour, for backwards compatibility.
[1] commit 215306f5a1
Author: Dan Williams <dcbw@redhat.com>
Date: Mon Jan 10 23:39:12 2011 -0600
core: add AddAndActivate D-Bus method
Given connection details, complete the connection as well as possible
using the given specific object and device, add it to system
settings, and activate it all in one method.
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=729665
With WWAN, the DHCP is all done in modem firmware, and never started
until we know we have a successful packet connection to the network.
Which means the modem firmware already knows the IP details and
is ready to provide them. Furthermore, since the DHCP is done on
what is essentially a reliable, wired point-to-point link, we don't
have to waste time with retransmits for dropped packets either.
OtherConf implies the address has already been delivered via RA,
and possibly DNS too, meaning our IP configuration is already
good enough. If nothing on the network bothers to reply to our
DHCPv6 Information Requests, let's just run with the config
we already have instead of tearing down the whole device.
Avoid this error:
NetworkManager[25181]: <warn> (cdc-wdm1): Failed to connect 'T-Mobile Internet': Connection requested IPv4 but IPv4 is unsuported by the modem.
NetworkManager[25181]: <info> (cdc-wdm1): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28]
** (NetworkManager:25181): CRITICAL **: mm_modem_simple_disconnect: assertion 'MM_IS_MODEM_SIMPLE (self)' failed
self->priv->simple_iface is only valid if stage1/prepare actually
completes, so don't try to access it if stage1/prepare failed.
Child devices shouldn't be exposed as real NMDevices (yet) since the
configuration and life cycle is controlled by the parent. We already
do this if the ip_iface is known when the child device is added, but
PPP and other transient interfaces often show up just before we know
the parent's ip_iface.
Add an 'unknown' value; make the type an enum, and rename it since
this enum is private to NetworkManager and abstracts differences
in old and new MM.
We also need separate methods for IPv4 and IPv6 since they may not
use the same mechanism. For example, IPv4 may use DHCP but IPv6 may
require static configuration, based on what the modem firmware wants.
Add support for IPv6 to the pppd plugin and return the interface identifiers
to NetworkManager. Use those to construct the IPv6LL addresses for the
PPP interface and the peer.
We want to set the WWAN config last, to ensure that the configuration we
use overwrites anything that pppd might have set, becuase it touches some
stuff itself. That means we have to keep the WWAN config separate, since
dev_ip4_config is used for DHCP and IPv4LL, which we always set first to
ensure they these don't overwrite external, administrator added config
(eg, priv->ext_ip4_config).
This also synchronizes the IPv4 config path with the upcoming IPv6
config path.
If the IID cannot be generated, the IPv6 address resulting from
the combination of an advertised prefix and 64-bits of zero is
both wrong and quite likely to clash with some other machine on
the network that doesn't implement IPv6 quite right either.
Require an valid interface identifier. If NetworkManager doesn't
know how to generate one, then we should fix NM to do so.
Ethernet-like interfaces aren't the only type of interfaces that can
run IPv6 but the rdisc code only returns an address if the interface's
hardware address is 6 bytes.
Interface types like PPP (rfc5072) and IPoIB (rfc4391) have their own
specifications for constructing IPv6 addresses and we should honor
those.
So instead of expecting a MAC address, let each device subclass
generate an Interface Identifier and use that for rdisc instead.
We no longer need a class method for reading the hardware address
length, for a couple reasons:
1) Using the IP interface hardware address for IP operations now makes
NMDevice's priv->hw_addr_len constant. So there's no reason to re-read
it all the time.
2) get_hw_address_length() is now only used for determining whether the
hardware address is permanent, and that only mattered for Bluetooth.
Since Bluetooth interfaces have a bogus interface name, they will never
have a valid ifindex, and thus nm_platform_link_get_address() would be
useless. So instead of using the 'permanent' stuff, just don't bother
updating the hardware address if the NMDevice's ifindex isn't valid,
and let subclasses pass the initial hardware address at device creation.
This also works correctly for NMDevice classes that previously
implemented get_hw_address_length() like ADSL and WWAN, since those
too will never have a valid ifindex or a valid hardware address.
3) Reading the device's hardware address length just ended up calling
nm_platform_link_get_address() for most devices anyway, so
nm_device_update_hw_address() would effectively read the link address
twice (once to read the length, the second time to read the actual
address). Let's just read the address once.
The IP interface may have its own hardware address (like the net
port for WWAN devices) and that's the hardware address that must be
used for DHCP and IPv6 SLAAC, not the hardware address (if any) of
the NMDevice itself.
This patch does change the NMDevice hardware address property to
always be the Device's hardware address, instead of the IP interface
hardware address. This means that ADSL and WWAN will no longer
change their hardware address to the hardware address of their
IP interface. But in all these cases, the hardware address is
non-existent (PPP) or transient and meaningless (WWAN/ADSL).
NMConfigDevice was added because in the 0.9.8 days, when each subdir
of src/ was compiled separately, it was impossible to make src/config/
depend on src/devices/ because of circular dependencies.
Since now everything gets compiled into a single libNetworkManager.la,
this is no longer a problem, and so NMConfigDevice is just an
unnecessary complication.
NMConfig accepted no-auto-default and ignore-carrier lists with
untagged specs (ie, interface names not prefixed with
"interface-name:" and hardware addresses not prefixed with "mac:").
Move that handling into nm_match_spec_interface_name() and
nm_match_spec_hwaddr() instead.
We were linking libndp into the NetworkManager binary, but it ought to
be marked as a dependency of libNetworkManager, in case a test
exercises that code.
Clean up some of the cross-includes between headers (which made it so
that, eg, if you included NetworkManagerUtils.h in a test program, you
would need to build the test with -I$(top_srcdir)/src/platform, and if
you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all
GObject struct definitions for src/ and src/settings/ into nm-types.h
(which already existed to solve the NMDevice/NMActRequest circular
references).
Update various .c files to explicitly include the headers they used to
get implicitly, and remove some now-unnecessary -I options from
Makefiles.
Several plugins were using -I$(top_srcdir)/libnm-glib, which is bad
since libnm-glib has its own nm-types.h which is different from src's.
Worse yet, some were actually linking against libnm-glib (which
presumably only worked at all because they weren't calling any
functions in it and so the linker just ignored the request). Fix both
problems.
5b4be27f moved test-dhcp-options from src/tests/ to
src/dhcp-manager/tests/, but src/tests/Makefile.am still included it
in "TESTS" (which would still work until you tried to build from a
clean tree...)
In preparation for library-based DHCP clients, remove some assupmtions
that all DHCP clients are subprocesses, and that all DHCP options
get passed back NM via D-Bus.
https://bugzilla.gnome.org/show_bug.cgi?id=732965
The goal is to remove generic logic from nm_dhcp_client_new_options(),
since library-ized DHCP clients won't ever call that function since
their native data format isn't a hash table of strings.
The options hash is never used except for BOUND events, so don't
bother caching it in the DHCP client object. Just pass it along
with the BOUND state change, like the IP configuration object.
