| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
We set the metric to the routes as we receive them from the PPP plugin. We
ought to let the modem know before it starts IPv4 configuration, not right
before the commit.
https://bugzilla.redhat.com/show_bug.cgi?id=1585611
|
| |
|
|
|
|
|
| |
Check the wpa_flags and rsn_flags values to see if the network needs the
password added to the 802-11-wireless-security settings. The current
ap_flags check alone would only trigger the password to be sent for WEP
networks. Also remove unneeded initialization of the three variables.
|
| |
|
|
|
|
| |
clients/cli/connections.c:1909:3: error: unused variable 'out_indices' [-Werror,-Wunused-variable]
NMC_OUTPUT_DATA_DEFINE_SCOPED (out);
^
|
| |
|
|
|
|
| |
src/devices/nm-device.c:7764:25: error: unused variable 'stable_hwaddr' [-Werror,-Wunused-variable]
gs_unref_bytes GBytes *stable_hwaddr = NULL;
^
|
| |\
| |
| |
| | |
https://github.com/NetworkManager/NetworkManager/pull/128
|
| | | |
|
| | |
| |
| |
| | |
For no reason at all.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is going to make it possible to parse and complete argument lists in one go:
-nmc_complete_strings (*argv, "ifname", "bssid", NULL);
-next_arg (nmc, &argc, &argv, NULL);
-if (strcmp (*argv, "ifname") == 0)
-...
-else if (strcmp (*argv, "bssid") == 0)
-...
+option = next_arg (nmc, &argc, &argv, "ifname", "bssid", NULL)
+switch (option) {
+case 1:
+...
+case 2:
+...
Beautiful.
|
| |/
|
|
|
| |
This is the time when the last Wi-Fi scan finished. It will help clients
decide whether the AP list is fresh enough.
|
| | |
|
| |\
| |
| |
| | |
https://github.com/NetworkManager/NetworkManager/pull/133
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In a lot of cases, we don't require the GBytes out-argument. This
is the case when called from NMSettingIP6Config's verify().
Avoid allocating the GBytes instance and also don't heap allocate
the temporary buffer in that case.
Also, being called from NMSettingIP6Config's verify(), at which
point the string value contains untrusted data. Of course, we
do very badly in general protecting against the user creating
huge settings, which could trick NetworkManage to allocate
large amounts of memory (and being killed by glib's out of memory
handling). We should handle such cases better in general, but
just avoid it here.
Since we know that the buffer must hold at most 128+2 bytes,
we can stack allocate it. Later, in case we really need to
return the value, we can create a GBytes instance of the right
size.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For better or worse, the logging done for ipv4.dhcp-client-id
is prefixed with ipv4.dhcp-client-id. Let ipv6.dhcp-duid follow
that pattern.
Also, generate_duid_from_machine_id() would log at two places,
it should use the same logging prefix.
Also, it logs the value of "duid" variable. Ensure, that "duid"
is not %NULL at that point.
Also, fix leak of nm_dhcp_utils_duid_to_string() value during logging.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
code path
Previously, there were two blocks
if (NM_IN_SET (duid, "ll", "llt")
preprocess_hwaddr()
else if (NM_IN_SET (duid, "stable-ll", "stable-llt", "stable-uuid"))
preprecess_stable_id()
if (nm_streq (duid, "ll")
generate_ll()
else if (nm_streq (duid, "llt"))
generate_llt()
else if (nm_streq (duid, "stable-ll")
generate_stable_ll()
...
That is, the latter block depends on the execution of the previous
block, while the previous block is guarded by a particular condition,
slighlty different than the condition in the later block.
It is confusing to follow. Instead, check for our cases one by one, and
when we determined a particular DUID type, process it within the same block
of code. Now the code consists of individual blocks, that all end with a "goto
out*". That means, it's easier to understand the flow of the code.
Also, don't initialize duid_error variable and separate between
"out_error" and "out_good". This allows that the compiler gives
a warning if we missed ot initialize duid_error.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
dhcp6_get_duid() already handles failure to generate the DUID in a
sensible manner. No reason to duplicate the error handling in
generate_duid_from_machine_id().
Especially, because generate_duid_from_machine_id() used to cache the
random DUID in memory and reuse it from then on. There is no reason to do
that, /etc/machine-id must be available to NetworkManager. We still
handle such a grave error gracefully by generating a random DUID.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
client-id
First of all, generating the client-id is not expected to fail. If it fails,
something is already very wrong. Maybe, a failure to generate a client-id
should result in failing the activation. However, let's not go full
measure in this question.
Instead:
- ensure that we log a warning and a reason why the client-id could not
be generated.
- fallback to a random client id. Clearly, we were unable to generate
the requested client-id, hence, we should fallback to a default value
which does not make the host easily identifyable. Of course, that means
that the generated DHCP client-id is not at all stable. But note that
something is already very wrong, so when handling the error we should do
something conservative (that is, protecting the users privacy).
This is also what happens for a failure to generate the ipv6.dhcp-duid.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ipv4.dhcp-client-id=mac
In practice, there should be no difference between peeking into
the platform cache, or using the cached value from nm_device_get_hw_address().
Prefer the hardware address from the platform, because:
- we also pass the current MAC address to nm_dhcp_manager_start_ip4().
For not particularly strong reason, it uses the MAC address obtained
from platform. At the least, it makes sense that we use the same
addresses for the client-id as well.
- ipv6.dhcp-duid also gets the address from platform. Again,
no strong reason either way, but they should behave similar
in this regard.
|
| |
|
|
| |
https://github.com/NetworkManager/NetworkManager/pull/134
|
| |
|
|
| |
Fixes: 28d2c07661f6e8c4305a5a7f66db346b09a607e2
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This test shows how
$ nmcli device wifi list bssid "$BSSID"
is broken.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commands that fail with G_DEBUG=fatal-warnings produce unstable
output like
(process:10743): GLib-CRITICAL **: 16:29:13.635: g_ptr_array_add: assertion 'rarray' failed
To workaround that, add a new option for marking the output as unstable.
An alternative might be to extend the replace_stdout, replace_stderr
arguments to support more powerful matching, like by specifying regular
expression for replacing. However, it's just too complicated. Add a simpler
workaround by passing _UNSTABLE_OUTPUT.
|
| |/
|
|
|
|
| |
We don't want any g_critial() or g_warning() in our nmcli
output. By default, let the tests crash. But tests could opt-out of
this.
|
| |\
| |
| |
| | |
https://github.com/NetworkManager/NetworkManager/pull/114
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unless the initscripts package too old to allow alternatives is present,
install nmcli as an alternative implementation of ifup and ifdown.
The triggerin scriptlet allow us to do the right thing regardless of
which initscripts version is installed or even when it's upgraded.
The initscripts patch was included in Fedora 29:
https://github.com/fedora-sysv/initscripts/pull/197
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
They're intended to be used via update-alternatives(8) as compatibility
shims for Red Hat systems without the legacy network control scripts.
While they're not strictly parts of the settings plugin, they're best
just installed along with it, since they're supposed to be available on
systems that use the ifcfg files.
|
| | |
| |
| |
| |
| | |
This is handy for users who configure NetworkManager by dropping files
into /etc.
|
| | |
| |
| |
| |
| |
| |
| | |
This allows the user to look up the file where the connection is stored.
Useful especially for ifcfg users.
Not shown by default.
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
| |
This allows implementing some convenience features in nmcli -- listing
the backing store for the connection in "nmcli c show", and using the
filename for specifying connection in "nmcli c up/down".
Eventually, paired with ReloadConnections(), this could be used to
implement something similar to what "systemctl edit" does for units
(though we'd need to pick another command name as we aready use
"nmcli c edit" for something different).
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
How does `nmcli -f ALL dev show $DEV` look, if it references
a connection that is invisible to the user?
Note in the output:
CONNECTIONS.AVAILABLE-CONNECTIONS[1]: (null) | (null)
|
| | | |
|
| | |
| |
| |
| |
| | |
For adding tests what nmcli shows regarding IP and DHCP configuration,
let the stub service generate config instances.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
It's still unused, but commit it individually, as it also causes
trivial changes to the .expected files.
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
| |
There's a couple of places where compose the output using nmc_print().
However, most of them (such as connectivity status or logging level) are
mostly one-line outputs where pager wouldn't make sense. These two stand
out.
|
| |
|
|
|
| |
The connection.id (NAME) is not necessarily unique.
To avoid confusion, log the UUID as well.
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1414093
|
| | | |
|
| | | |
|
