Under valgrind, we cannot create an NAcd instance.
--10916-- WARNING: unhandled amd64-linux syscall: 321
--10916-- You may be able to write your own handler.
--10916-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--10916-- Nevertheless we consider this a bug. Please report
--10916-- it at http://valgrind.org/support/bug_reports.html.
This limitation already poses a problem, because running NetworkManager
under valgrind might fail. However, for tests it doesn't matter and we
can just skip them.
When building with meson -Dppp=false, the following message is printed
during build:
[623/671] Generating NetworkManager.ver with a custom command. find: ‘./src/ppp/’: No such file or directory
The message is harmless. Hide it.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/43
The script didn't include all the symbols needed by plugins because
libNetworkManager.a, as built by meson, doesn't include symbols from
other static libraries that are linked in. Since we used
libNetworkManager.a to know which symbols are potentiall available
from NM, the result was an incomplete list.
Unfortunately, the only way to include the whole static library is to
create a dependency object and use 'link_whole', but this is only
available in meson >= 0.46. Since 'link_whole' is available for
executables in meson >= 0.40, create a fake executable and use that to
enumerate symbols.
Also add tests to check that plugins can be loaded correctly.
Fixes: dfa2a2b40c
Adapt the meson post-installation script to handle the $DESTDIR
variable supplied by user to specify the installation target
directory. While at it, convert the script to shell because it seems
simpler to me.
NetworkManager.ver needs to whitelist symbols needed by device,
settings, and ppp plugin. Fix the generator script to also allow
using c_siphash_*() symbols. These are needed by nm_hash_*().
Without this, wifi device plugin is broken.
Fixes: ccf36ff4ce
The function is supposed to return the IPv4 address as 32 bit integer in
network byte order (bit endian). The ip4_addr_ne32() name is confusing,
because "ne" commonly stands for "native endianness".
Compare also "unaligned.h" and unaligned_read_ne32(), which also
stands for native endianness (host order), not network order (big
endian).
Rename.
Tests might just take longer than 20 seconds.
Also, we already watch stdin to determine whether the service
should exit.
(cherry picked from commit 4e18ef49bf)
Now that nmcli initiates a scan before displaying Wi-Fi networks,
the stub service must properly support that as well.
For the moment, the stub service chooses "now" as LastScan timestamp.
This causes nmcli not to trigger a new scan, because nmcli gives
unstable output if multiple nmcli processes in parallel race to
trigger a Wi-Fi scan. That should be fixed.
(cherry picked from commit 56a0488bba)
This opens the tests up to races. If we want to change the strength, we
need to do it in a controlled, race-free manner. This is especially the
case, because clients/tests run a large number of nmcli instances in
parallel, and it's thus racy which signal the nmcli processes will
see.
This also fixes a bug at
self._dbus_property_set(IFACE_WIFI_AP, PRP_WIFI_AP_STRENGTH, strength)
@strength must be a D-Bus type, so that python-dbus knows the correct
type for serialization.
(cherry picked from commit 7e118c0091)
Currently, nmcli does not sort the list of available connections
for display. Instead, it shows them in the order as NetworkManager
exposes them on D-Bus.
Previously, test-networkmanager-service.py, would generate the list
of available connections by iterating the connections dictionary.
In Python (at least until Python 3.6), the order when iterating over
dictionaries is undefined. This inconsistancy lets tests behave
differently depending on the python version. Possibly with Python
3.4 and 3.5, tests might even behave differently between individual
runs (since Python there uses siphash with a randomized hash seed).
At several places, "test-networkmanager-service.py" uses generated numbers
with a defined seed. For example, generated connection's UUID is
generated in a predictable, but randomized way (if you forgive the
inprecise use of the word "random" in context of using a deterministic
seed).
Aside the connection's UUID, this becomes more interesting in the next commit
where the stub server generates a list of IP and DHCP settings in a predictable
randomized way.
For "clients/tests" we spawn the test service multiple times, but also
create similar environments by calling init_001(). This is done for
convenience, where out of lazyness all the tests share one setup. But it's
still a good idea that these tests generate slightly different setups,
wherever applicable. this increases the possible setups which get tested.
For example, the number of static IPv4 addresses (the following commit) is
interested to explicitly test for zero or a non-zero number of
addresses. If all tests happen to use the same seed, the tests are expected
to also generate the same number of addresses, and we miss an opportunity to
hit interesting test cases.
There is still no guarantee that all interesting cases are hit, the chances are just
better. The approach of generating the setup randomly, does not preclude that
the stub-server allows to explicitly configure the setup. However, due to the
sheer number of combinations that might be interesting to test, it's much simpler
to rely on some randomization and have the justifid hope we catch interesting cases.
Also in terms of runtime of the test, the cli unit tests should complete within
few seconds. Testing every combination would result in huge tests and long runtimes.
Also, the patch refactors generating random numbers in
"test-networkmanager-service.py". For example, it introduces
Util.RandomSeed(), which can be used to generate a sequence of different
random numbers. It works by having an internal state and a counter which is
combined to chain the seed and generate different numbers on each call.
Just to give it some variety. Also, note how the message from the
server cannot be translated. Which is the case with real NetworkManager
as well, and is a major usability issue.
The real NetworkManager service has a clear understanding how a valid
connection looks like. This is what nm_connection_verify() returns.
Let also our stub-service verify connections the same way.
Note that this is cumbersome, because the stub service uses python's
dbus module, while libnm only accepts creating NMConnection instances
from GVariant. Thus, we need to a cumbersome conversion first.
It would be better if test-networkmanager-service.py would also expose
normalized connections on D-Bus. But that requires the inverse converion
from GVariant to python dbus.
lso, the name "connection" and "con" is overused.
Use "con_inst" where we mean an instance of a "Connection" class,
that is, the object exposed on D-Bus.
- don't use "hash" for a local variable in python.
The editor highlights it like a special python name.
- don't use "settings" for Connection.settings. Name it
Connection.con_hash. The name "settings" is over-used already.
"con_hash" really is the nested dictionary that we expose/receive
from D-Bus. If we would use libnm for it, it would be an
NMSimpleConnection instance, but we don't.
Previously, the callbacks would return gl.mainloop.quit(), which is None
and thus the source got removed already. The later GLib.source_remove()
would thus use an invalid source-id.
Fix that, by no removing the source id from the callback.
Fixes: b1ff82eba5
Instead of exporting exported-objects during construction, export
them right before we register them (for example, in case of device
instances, before we add the device to the manager's device list).
Likewise, when removing the object from the list, always explicitly
unexport them.
Without explicitly unexporting the objects, they can also not be
removed, because object-manage and D-Bus library keep references
to them.
Instead of registering a __get_props() function which constructs the
entire hash anew each time, register a props dictionary. This dictionary
is used as cache for the properies.
In most cases, we don't need to additionally cache the properties
outside the props dictionary. Also, add _dbus_property_set() which
sets the property and emits the notification.
Also, cleanup the property names by giving them a PRP_ prefix.
- no more global variables, except those in the new variable "gl".
- don't pass that bus instance around. Use the singleton gl.bus.
- separate creation of ExportedObj from exporting on D-Bus.
- use enum values loaded from NM via GObject introspection.
- the visible change is that the generated D-Bus paths now start
counting at one. That is also how NetworkManager behaves, and
it looks nicer to have no zero ID for an object.
- add find_devices() and find_device_first() functions,
to not re-implement iterating the device list.
- for test functions, accept the device's "ident", instead
of ifname. The "ident" must b unique, contrary to the "ifname".
Add a test which runs nmcli against our stub NetworkManager
service and compares the output.
The output formats of nmcli are complicated and not easily understood.
For example how --mode tabular|multiline interacts with selecting
output-fields (--fields) and output modes ([default]|--terse|--pretty).
Also, there are things like `nmcli connection show --order $FIELD_SPEC`.
We need unit tests to ensure that we don't change the output
accidentally.
tools/test-networkmanager-service.py is our NetworkManager stub server.
NetworkManager uses libnm(-core) heavily, for example to decide whether
a connection verifies (nm_connection_verify()) and for normalizing
connections (nm_connection_normalize()).
If the stub server wants to mimic NetworkManager, it also must use these
function. Luckily, we already can do so, by loading libnm using python
GObject introspection.
We already correctly set GI_TYPELIB_PATH search path, so that the
correct libnm is loaded -- provided that we build with introspection
enabled.
We still need to gracefully fail, if starting the stub server fails.
That requries some extra effort. If the stub server notices that
something is missing, it shall exit with status 77. That will cause
the tests to g_test_skip().
With autotools, we use libtool so that the right libraries are
automatically found. Still, we won't find the right GI typelib.
Add a mechanism so that when make/meson invokes the run-nm-test.sh
runner, it passes the build-root directory.
Also, try to autodetect when invoked manually.
