The atm/adsl plugin really is a generic ATM plugin but (a) it needs a
bit of work to do IPoATM rather than just PPPoATM and PPPoEoATM, and
(b) most people currently using NM's ATM support are using DSL devices
not actual ATM cards anyway, and have no idea what "ATM" even means.
If we add the necessary IPoATM support later we can rename the plugin
back to -atm
Make WWAN support a plugin using the new device factory interface.
Provides a 5% size reduction in the core NM binary.
Before After
NM: 1187224 1125208 (-5%)
MM: 0 100576
(all results from stripped files)
Make Bluetooth support a plugin using the new device factory interface.
Provides a 5% size reduction in the core NM binary.
Before After
NM: 1253016 1187224 (-5%)
BT: 0 85752
(all results from stripped files)
Make ADSL support a plugin using the new device factory interface.
Provides a 1% size reduction in the core NM binary.
Before After
NM: 1265336 1253016 (-1%)
ATM: 0 27360
(all results from stripped files)
We were setting GLIB_VERSION_MAX_ALLOWED to 2.34, since we provide
reimplementations of a few 2.34 functions in nm-glib-compat.h. But
this was turning off warnings for the 2.34+ APIs we *didn't* have
compat versions of too.
Fix this by setting MAX_ALLOWED to 2.32 (same as MIN_REQUIRED), and
defining macros to wrap calls to compat-ified functions and disable
deprecation warnings around them.
This points out several places where we were accidentally using 2.34
APIs without noticing, which need to be fixed now.
`make dist` packs the 'configure' file in the tarball, so this is
useful, to include the commit id into the release tarball.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At critical times during the connection process, especially during
DHCP and EAPOL, the driver can increase the reliability of communication
in an attempt to increase the possibility of success. This could be
done by suppressing bluetooth for a short period, or locking in a low
(and thus more reliable) bitrate, or enforcing some other interference
protection. The 3.10 kernel added nl80211 support for this, so lets
use it if we can.
Given an IPv4 address and prefix for a shared config, figure out
the DHCP address range automatically. To keep things simple we
allow a max of 252 addresses (not including network address,
broadcast address, and the hotspot) no matter what prefix you use,
so if the address is 10.0.10.1, you still only get a range of
10.0.10.2 -> 10.0.10.254.
But we also leave some addresses available above the host address
for static stuff, like we did before. This is done on a sliding
scale from 0 to 8 addresses, where about 1/10th the number of
available addresses are reserved.
https://bugzilla.gnome.org/show_bug.cgi?id=675973
If the hostname is "foo.example.com" then we want to add
"search example.com" to resolv.conf, but if it's just "example.com",
we don't want to add "search com" (rh #812394).
So if NetworkManager is being built with recent libsoup, use
soup_tld_domain_is_public_suffix() to double-check the domain before
adding it. (If it is not being built with libsoup, or is being built
with too old a version, we just skip that test, keeping the old
behavior.)
dhcpcd v5.99 and later automatically enabled IPv6 behavior unless
specifically disabled. This is undesirable for two reason:
1) dhcpcd sends IPv4 Router Solicitations, which NetworkManager
handles itself, so there's no need to do it twice. NetworkManager
knows better than dhcpcd whether IPv6 is supposed to be used for
that interface or not.
2) Some devices don't react well to IPv6 when they aren't expecting
it. For example, older Qualcomm Gobi-based devices will listen
for Router Solicitations and attempt to set up IPv6, but if other
settings are not done correctly, or the firmware doesn't actually
support it, the firmware will then crash. So simply upgrading your
dhcpcd from 5.x to 6.x magically stops WWAN working for these
devices.
Without this patch, the following fails with a rather obscure message
about missing make target.
./autogen.sh && make && make distcheck
...
*** No rule to make target `NetworkManager.8', needed by `distdir'. Stop.
Swap the order of the subdirectories 'docs' and 'man' to build
'docs' earlier. This way, `make distcheck` fails in the directory 'docs'
with a better error message:
*** gtk-doc must be installed and enabled in order to make dist
Also, add 'man/nmcli-examples.5' to the list of files, to determine
whether to use the pre generated doc files.
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMBluezManager is now a proxy and only delegates to either
NMBluez4Manager or NMBluez5Manager. It detects the running BlueZ
version at runtime, and once it decides for one version, it cannot be
changed anymore as long NetworkManager is running.
This means, when switching from BlueZ4 to BlueZ5 or vice versa you have
to restart NetworkManager. This should be acceptable, because it is
not a common use case (most systems won't have both versions installed
anyway) and it greatly simplifies implementation.
Also note that NMBluez4Manager and NMBluez5Manager do not implement a
common interface. NMBluezManager delegates to the correct manager.
Having them share an common interface or base class would not simplify
the code, because NMBluezManager not only delegates, but it also acts as
a proxy until it is decided which BlueZ version is running. So, this
proxy-like behaviour would still be needed. The alternative would be to
merge the functionality of all three NMBluez*Manager classes into one.
This also removes the --enable-bluez4 configure switch, because both
versions are now always enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=709412
Signed-off-by: Thomas Haller <thaller@redhat.com>
Earlier versions of automake complain if they get a configuration
parameter which they don't understand. The error is:
configure.ac:19: option `serial-tests' not recognized
Use some m4 hackery to work around this.
Stolen from here by jklimes:
https://www.redhat.com/archives/libguestfs/2013-February/msg00102.html
The nm-rdisc subsystem, just as the nm-platform subsystem is separately
testable and it proved convenient to be able to build the test programs
by just typing 'make' in the rdisc/platform directory where the source
code for those modules resides.
src/rdisc doesn't need a makefile just to point to the tests,
we can do that more easily from src/Makefile.am like we do for
all the other tests subdirs.
Abstract class, fake implementation and a manual testing tool for
NetworkManager's internal IPv6 router discovery module. When a real
implementation is ready, it will replace nm-ip6-manager and will be used
by nm-device.
There is no longer a 'ModemCapabilities' uint32 property; instead we have
'SupportedCapabilities' giving a list of uint32 values. Just read the list and
merge the values into a single mask; NM doesn't care about the exact
combinations supported.
https://bugzilla.gnome.org/show_bug.cgi?id=701668
systemd's new network-online target abstracts the "wait until
networking is up" stuff, and NM-wait-online implements that
functionality. Thus NM-wait-online should be ordered before
(and thus be a dependency of) network-online.
dist tarballs shouldn't ever be released without the documentation,
and this allows us to build the tarballs with pre-generated docs
that get installed on the end system, but don't need to be built
there. So the end system doesn't need gtk-doc installed, only
the dist system does.
https://bugzilla.gnome.org/show_bug.cgi?id=700093
Although having different parts of NM in different subdirectories
keeps the source tree neat, it has made the build messy, particularly
because of cross-dependencies between the subdirs.
Reorganize to build all of the pieces of the NetworkManager binary
from src/Makefile, and only use recursive make for test programs,
helper binaries, and plugins.
As part of this, get rid of all the per-directory convenience
libraries, and switch to building a single top-level
libNetworkManager.la, containing everything except main.c, which all
of the test programs can then link against.
When --with-modem-manager-1=yes not explicitly specified (i.e. 'auto' mode), and
libmm-glib is not found, we should not report:
Features:
...
modemmanager-1: auto
Instead, better report:
Features:
...
modemmanager-1: no
If the Intel WiMAX stack is built with libnl1, but NM is built with a
newer libnl, then symbol conflicts between libnl versions will occur
when the WiMAX plugin is loaded into NM, and NM will crash.
Distros should be building their WiMAX stack with libnl3, using the
following git repos, rather than the long-defunct Intel git repos:
git://people.freedesktop.org/~dcbw/wimax
git://people.freedesktop.org/~dcbw/wimax-tools
These repos contain fixes to allow the WiMAX stack to build against
libnl3.
If the Intel WiMAX stack is built with libnl1, but NM is built with a
newer libnl, then symbol conflicts between libnl versions will occur
when the WiMAX plugin is loaded into NM, and NM will crash.
Distros should be building their WiMAX stack with libnl3, using the
following git repos, rather than the long-defunct Intel git repos:
git://people.freedesktop.org/~dcbw/wimax
git://people.freedesktop.org/~dcbw/wimax-tools
These repos contain fixes to allow the WiMAX stack to build against
libnl3.
