This partially reverts commit 4a9fcb0fc3, which replaced one-byte
reads with buffered ones in the VPN service plugin.
Unfortunately the buffering means that commands coming after the magic
"DONE" string were being pulled into the buffer. Secrets agents expect
a "QUIT" to come after the "DONE", and since with buffering "QUIT" was
in the buffer, this led to a twenty-second delay on every VPN
connection using a secrets manager.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1164
Fixes: 4a9fcb0fc3 ('libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()')
A couple of argument documentation strings were long enough to be broken
up to span over multiple lines. gdbus-codegen, on the other hand, was
of differing opinion and promptly punished the offense by garbling the
resulting docbook.
Merge the string into single lines.
This one attempts to document an option dictionary in a manner that has
been deemed criminal by the high court of gdbus-codegen.
Beat it back into shape.
There has been a lot wrong with this one. Aside from the messy
capitalization, it broke the argument documentation into multiple lines,
baffling gdbus-codegen, which, in turn, generated garbage documentation.
Overhaul it.
There has been a lot wrong with this one. Aside from the messy
capitalization, it broke the argument documentation into multiple lines,
baffling gdbus-codegen, which, in turn, generated garbage documentation.
Overhaul it.
The GMainLoop instance (and the default GMainContext singleton) is not
required for trivial operations like --print-config, --version or
--help). If running as SysV daemon, the event file descriptor is
unnecessarily dup'ed from the parent to the child process.
Signed-off-by: Christian Eggers <ceggers@arri.de>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1160
`msgfmt -vc` warns:
po/be@latin.po:2: warning: header field 'Language' still has the initial default value
Check all files and update the Language manually.
The documentation ([1]) says that either "ll", "ll_CC" or "ll_CC@variant"
is valid. Update accordingly.
[1] https://www.gnu.org/software/gettext/manual/html_node/Header-Entry.html
`msgfmt -vc` warns:
po/as.po:9: warning: header field 'Project-Id-Version' still has the initial default value
Update them all:
$ git grep -l Project-Id-Version | xargs sed 's/^"Project-Id-Version: \(.*\)\\n"$/"Project-Id-Version: NetworkManager\\n"/' -i
The documentation ([1]) says:
Project-Id-Version
This is the name and version of the package. Fill it in if it has not already
been filled in by xgettext.
but don't add the "version". We have these files in git on the devel branch,
so whenever we branch a new release, the version would change. Just say
"NetworkManager".
[1] https://www.gnu.org/software/gettext/manual/html_node/Header-Entry.html
By having a ".md" extension, gitlab renders a nice page instead of
showing as plain text.
Currently our README is pretty bad. Partly, because it doesn't get
shown nicely.
Rename. The file effectively was already markdown. The old file is
gone.
For this we also need to change the automake flavor to "foreign"
(See [1]).
[1] https://autotools.info/automake/options.html#automake.options.flavors
The "check-{patch,tree}" jobs use the same container as the default
test on Fedora ("pages_build", which also builds our documentation).
Previously, we thus extended "t_fedora:35". But that way we also
got things that we didn't want (.nm_artifacts and .build@template).
Solve this differently, by letting the jobs directly define what they
need. It's not much more, than extending "t_fedora:35" and workaround
to drop stuff we don't want.
Our test is long and verbose. The output gets truncated after
a few megabytes, but sometimes it's interesting to see what
happens afterwards. Redirect also to a file and archive it.
The output of our test scripts is captured by gitlab. It does however
sanitize things that look like secrets. So it was reasonably save
to call `env` from within the test script.
Next, we will redirect (`tee`) the output of the test script to a
file and archive it. When we do that, the output does not get sanitized
and can be downloaded from the artifacts page.
Stop running `env` as part of the test script. Do it instead as a
separate step. After all, it is useful to see the environment variables
of the test. But sanitized.
It's true, that our gitlab-ci test mostly consists of building NetworkManager.
Hence the name of the script was not entirely wrong. But it's not only building.
I think "run-test.sh" is a much better name. Rename.
The "take" parameter of _set_effective_client_id() was always "FALSE". Drop it.
Also, drop _set_effective_client_id() and just call nm_dhcp_client_set_effective_client_id()
directly.
We list the properties that can be reapplied, and reject the reapply
operation for any other changes. The idea is that usually reapply
of a property requires an explicit implementation (or may not make
sense).
"connection.autoconnect-slaves" is something that takes effect when
activating the master device. It does not matter when the device
is already active, thus there is no need to reject the reapply
operation.
https://bugzilla.redhat.com/show_bug.cgi?id=2065049https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1150
Curl's CURLOPT_RESOLVE expects one list entry per host. That
documentation ([1]) also makes that clear that the form is
"[+]HOST:PORT:ADDRESS[,ADDRESS]".
The way we constructed the list, only the last entry was honored:
<trace> [1647551393.5362] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:18.159.254.57' to curl resolve list
<trace> [1647551393.5363] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:152.19.134.142' to curl resolve list
<trace> [1647551393.5363] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:18.192.40.85' to curl resolve list
...
<trace> [1647551393.5366] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:85.236.55.6' to curl resolve list
<trace> [1647551393.5366] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:38.145.60.20' to curl resolve list
...
<trace> [1647551393.5415] connectivity: (eth0,IPv4,25) libcurl: == Info: Added fedoraproject.org:80:18.159.254.57 to DNS cache\012
<trace> [1647551393.5416] connectivity: (eth0,IPv4,25) libcurl: == Info: RESOLVE fedoraproject.org:80 is - old addresses discarded!\012
<trace> [1647551393.5416] connectivity: (eth0,IPv4,25) libcurl: == Info: Added fedoraproject.org:80:152.19.134.142 to DNS cache\012
<trace> [1647551393.5417] connectivity: (eth0,IPv4,25) libcurl: == Info: RESOLVE fedoraproject.org:80 is - old addresses discarded!\012
...
<trace> [1647551393.5422] connectivity: (eth0,IPv4,25) libcurl: == Info: RESOLVE fedoraproject.org:80 is - old addresses discarded!\012
<trace> [1647551393.5423] connectivity: (eth0,IPv4,25) libcurl: == Info: Added fedoraproject.org:80:38.145.60.20 to DNS cache\012
<trace> [1647551393.5424] connectivity: (eth0,IPv4,25) libcurl: == Info: Hostname fedoraproject.org was found in DNS cache\012
<trace> [1647551393.5424] connectivity: (eth0,IPv4,25) libcurl: == Info: Trying 38.145.60.20:80...\012
There are two possible fixes. Either join all addresses in one
entry, or use the '+' modifier. Do the former.
Now we get:
<trace> [1647551967.0378] connectivity: (eth0,IPv4,25) set curl resolve list to 'fedoraproject.org:80:38.145.60.21,152.19.134.142,152...
...
<trace> [1647551967.0559] connectivity: (eth0,IPv4,25) libcurl: == Info: Added fedoraproject.org:80:38.145.60.21,152.19.134.142,152.1...
<trace> [1647551967.0560] connectivity: (eth0,IPv4,25) libcurl: == Info: Hostname fedoraproject.org was found in DNS cache\012
<trace> [1647551967.0561] connectivity: (eth0,IPv4,25) libcurl: == Info: Trying 38.145.60.21:80...\012
[1] https://curl.se/libcurl/c/CURLOPT_RESOLVE.html
Reported-by: Bastien Nocera <hadess@hadess.net>
Fixes: 2cec94bacc ('connectivity: use systemd-resolved for resolving the check endpoint')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/648#note_1301596https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1153
This allows us to reject activation of WEP profiles very early,
also providing a reasonable error code to the client:
$ nmcli d wifi connect test
Error: Failed to add/activate new connection: wpa_supplicant does not support WEP encryption
Since version 2.10, it's possible to build wpa_supplicant without WEP
support. In fact, it's disabled by default. Regrettably, there's no
indication in that version as to whether WEP is enabled or not.
A patch has been sent upstream that exposes the information on D-Bus:
https://patchwork.ozlabs.org/project/hostap/patch/20220307085446.706024-1-lkundrak@v3.sk/
This makes use of the above to indicate presence or absence of WEP
support.
I think we should move away from using the source-ids.
Having a "GSource*" pointer makes it clearer what this is, compared to a
guint source ID. Also, g_source_remove() always needs to first do a hash
lookup (with locking) to resolve the source ID to the GSource. This is
unnecessary.
I got a report of a scenario where multiple servers reply to a REQUEST
in SELECTING, and all servers send NAKs except the one which sent the
offer, which replies with a ACK. In that scenario, n-dhcp4 is not able
to obtain a lease because it restarts from INIT as soon as the first
NAK is received. For comparison, dhclient can get a lease because it
ignores all NAKs in SELECTING.
Arguably, the network is misconfigured there, but it would be great if
n-dhcp4 could still work in such scenario.
According to RFC 2131, ACK and NAK messages from server must contain a
server-id option. The RFC doesn't explicitly say that the client
should check the option, but I think it's a reasonable thing to do, at
least for NAKs.
This patch stores the server-id of the REQUEST in SELECTING, and
compares it with the server-id from NAKs, to discard other servers'
replies.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1144
When a NMDevice is involved in a PPPoE activation, it means that the
connection has connection.interface-name=<ethernet-interface>. In such
case, the ppp ifindex should be set as ip-ifindex of the ethernet
device.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
