| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This is not cool; warn about it. Let's not remove it yet to stay on the
safe side.
|
| |
|
|
|
|
|
| |
The docker bridges are no special -- just regular externally created
bridges.
This reverts commit 0ce73275506e8d3156b8d3cd9ca7a1105c5dc4fb.
|
| |
|
|
|
|
|
| |
It doesn't have to be at the end of line, there may be more words
following.
Fixes: d66a1ace23c5 ('contrib/checkpatch: avoid command injection in checkpatch.pl script')
|
| |
|
|
|
|
|
|
| |
The teamd instance must not be killed if the device was externally
activated.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/158
https://bugzilla.redhat.com/show_bug.cgi?id=1693142
|
| |\
| |
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/144
https://bugzilla.redhat.com/show_bug.cgi?id=1667874
|
| | |
| |
| |
| |
| |
| |
| |
| | |
If we created a software interface it is because we already decided
that it should be managed, and so there is no point in waiting udev to
check that the interface is not udev-unmanaged.
We still wait udev for software interfaces created externally.
|
| | |
| |
| |
| |
| |
| |
| | |
An active connection started by user could be queued in state UNKNOWN
which means the device hasn't started activating yet. Eventually it
will, and we don't want to cancel the user activation because of an
internal autoconnection attempt.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a special case for ensuring that the device's configuration
doesn't disappear when some factory is too late at recognizing the
device is just a component of another one.
It was always a bad idea. If the device already had an active
connection (such as for a generated default wired connection), it would
remain around, with a dangling reference to the device.
This effectively reverts commit 5ad69cb29b7c ('core: remove child devices
without deconfiguring them (bgo #738479)'). It's okay to do so, because
we now wouldn't deconfigure the device upon its removal anyway.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
|
| |
|
|
|
|
|
|
|
|
|
|
| |
"/var/run"
The pid-file is private to NetworkManager. It should reside in NetworkManager's
run directory instead of "/var/run".
I don't think that changing this location can break existing uses. Why
would somebody outside of NetworkManager care about this file?
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/157
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rename tests so that they have unique names.
meson requires that the build executables have unique names (at least,
older versions). Hence, we used to name the test binary different from
the source file ("libnm-test-general" vs. "test-general.c").
The tests should be named "*/tests/test-*", and the source file should
have the same name as the test executable.
Rename the sources so that the names are unique.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
For the most part, we only have one main .gitignore file.
There were a few nested files, merge them into the main file.
I find it better to have only one gitignore file, otherwise the
list of ignored files is spread out through the working directory.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
We already have 4 other tests that are named "test-general". Rename.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We already have "libnm-core/tests/test-keyfile.c" from which we build
"test-keyfile".
Our test binaries should be named the following:
- "*/tests/test-*"
- the test binary "*/tests/test-*" should be build from a source file
"*/tests/test-*.c". Meaning: the source's and executable's name should
correspond.
- test binaries should be named uniquely. Also, because older meson
versions don't like having the same binary name more than once.
Rename to avoid the duplicate name.
|
| |/
|
|
|
|
|
| |
.gitignore
The bottom contains the tombstones for files that we ignored in
the past, but no longer actually have. Move the lines.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This will be the default for Slackware 15.0 and on.
This should be safe for both master and 1.12.x stable branch, as
no existing Slackware releases are expected to run NM-1.12.x or
later.
Signed-off-by: Robby Workman <rworkman@slackware.com>
https://mail.gnome.org/archives/networkmanager-list/2019-May/msg00011.html
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Older versions of meson don't like building multiple artifacts
with the same name (even if they are in different directories). We
have multiple tests called "test-general.c", and it would be natural
to compile a test binary of the same name.
Meson encountered an error in file src/tests/meson.build, line 14, column 2:
Tried to create target "test-general", but a target of that name already exists.
It's generally a bad idea to have in our source tree multiple files with the
same name. Rename the test.
Fixes: 16cd84d346f1 ('build/meson: rename platform tests to use same name as autotools'):
|
| |
|
|
|
|
|
|
|
|
|
| |
package
Valgrind is known to report many false positives with certain glib2
versions. Workaround that by disabling it based on the installed
package version.
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=1710417
See-also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/155
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/155
|
| | |
| |
| |
| |
| |
| |
| |
| | |
On Ubuntu 16.04 (trusty) valgrind fails due to rdrand being advertised
but not implemented.
Work around that by installing valgrind from Ubuntu 18.04 (bionic) via
the "contrib/scripts/nm-ci-install-valgrind-in-ubuntu1604.sh" script.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First of all, all file names in our source-tree should be unique. We should
not have stuff like "libnm-core/tests/test-general.c" and "src/tests/test-general.c".
The problem here are the C source files, and consequently also the test
binaries have duplicate names. We should avoid that in general. However,
our binaries should have a matching name with the C source. If
"test-general.c" is not good enough, that needs renaming. Not building
"platform-test-general" out of it.
On the other hand, all our tests should have a filename "*/tests/test-*", like
they do for autotools.
Rename the meson platform tests.
It's also important because "tools/run-nm-test.sh" relies on the test
name to workaround valgrind warnings.
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/145
|
| | |
| |
| |
| |
| | |
Do so on all RHEL/Fedora releases. They all use systemd, and it's the right
choice for all of them.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Nowadays, it's adivisable to use "/run" instead of "/var/run" ([1]). This is because
"/var" might not be mounted in early boot, during shutdown, or during rescue mode.
Autoconf 2.70 will add an option --runstatedir ([2], [3]). However, the latest
autoconf release is 2.69 from April 2012, so this might take a while longer. Note
that some distributions patched their autoconf 2.69 to support --runstatedir [4],
but not Fedora.
See also [5], [6] for when we added support for autoconf 2.70's
"--runstatedir".
Add a "--with-runstatedir" option that we can use. Note that this
overwrites autoconf's "--runstatedir" (should it be supported). That
makes sense, because this way the user can set the option regardless of
whether autoconf supports "--runstatedir".
For example, Xen did something similar [7].
Meson currently does not support this either. I will not add a
workaround, because there is hope that it will be eventually fixed [8].
Also, autotools is still our default way for building. There is a
NetworkManager issue about this ([9]), which is still unfixed.
[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
[2] https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
[3] https://lists.gnu.org/archive/html/bug-autoconf/2013-09/msg00000.html
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759647
[5] https://bugzilla.gnome.org/show_bug.cgi?id=737139
[6] commit cd3c52a24d ('build: support runstatedir configure option')
[7] https://patchwork.kernel.org/patch/9576621/
[8] https://github.com/mesonbuild/meson/issues/4141
[9] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/24
|
| | |
| |
| |
| |
| |
| |
| |
| | |
"/var/run/ConsoleKit/database"
There should be no difference in pratice. But we should not mention "/var/run"
as /var might not be mounted in early boot or rescue environment. Of course,
in those cases ConsoleKit is not running either. But still...
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This change is a bit annoying, because we package "NetworkManager.conf" file in
our RPM. So, upon package upgrade, rpm will note that a new config file should
be installed and thus will leave ".rpmnew" files.
Also, don't mention "/var/run". It should really be just "/run" because
"/var" might not be mounted in early boot/initrd or in rescue environment.
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
"RUNDIR" is set to "$runstatedir/NetworkManager". That is not correct,
we must use "$runstatedir".
I don't understand how this could have ever worked. Commit e2ecf5b808c5
('dhcp: dhcpcd uses a fixed path for PID files') seems to address this issue,
but already then "RUNDIR" was set to "$(localstatedir)/run/NetworkManager".
|
| |\
| |
| |
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1709741
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/147
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NM_LOG_DOMAINS is a comma-separated list of the selected logging domains.
As the number of all logging domains is fixed at compile-time, the maximum
length of the buffer is known.
$ git grep $'^\t{ LOGD_' | sed 's/.*"\(.*\)" .*/\1/' | xargs | sed 's/ */,/g' | sed 's/^/NM_LOG_DOMAINS=/'
NM_LOG_DOMAINS=PLATFORM,RFKILL,ETHER,WIFI,BT,MB,DHCP4,DHCP6,PPP,WIFI_SCAN,IP4,IP6,AUTOIP4,DNS,VPN,SHARING,SUPPLICANT,AGENTS,SETTINGS,SUSPEND,CORE,DEVICE,OLPC,INFINIBAND,FIREWALL,ADSL,BOND,VLAN,BRIDGE,DBUS_PROPS,TEAM,CONCHECK,DCB,DISPATCH,AUDIT,SYSTEMD,VPN_PLUGIN,PROXY
Note that the static buffer "_all_logging_domains_to_str" is known
to be large enough to contain these domain names (it's even longer,
as it also contains "ALL", "IP", and "DHCP" alises). We can use that
to define the array of suitable size.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Don't create a heap allocated GString to hold the static
result of nm_logging_all_domains_to_string().
Instead, use a static buffer of the exactly required size.
The main reason to do this, is to get the exact size of
"_all_logging_domains_to_str" buffer. This is the upper
boundary for the size of a string buffer to hold all domain
names.
We will need that boundary in the next commit. The attractive
thing here is that we will have a unit-test failure if this
boundery no longer matches (--with-more-asserts). That means,
this boundary is guarded by unit tests and we don't accidentally
get it wrong when the domains change.
Also, take care to initialize the buffer in a thread-safe manner.
It's easy enough to get right, so there is no excuse for having
non-thread-safe code in logging.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Syslog's "facility" is a well defined thing and must be
one of a few well-known numbers. Don't re-use it for our
own purposes.
Fixes: 1b808d3b255c ('logging: add native systemd-journald support to nm-logging')
https://bugzilla.redhat.com/show_bug.cgi?id=1709741
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
This overflow could only happen when we would try to log a message
with "NM_DEVICE=", "NM_CONNECTION=", and more than 8 logging domains
(_NUM_MAX_FIELDS_SYSLOG_FACILITY - 2).
The latter is never the case. While we sometimes log messages with
more than one logging domain, there are no logging statements that
use most as 8 different logging domains. So, this overflow is not
actually reachable from current code (I think).
Fixes: ed552c732c76 ('logging: log device and connection along with the message'):
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I find
for (i = 0; i < n_ports && !owns; i++)
owns = ...
hard to read.
If the condition is satisfied, we can just return the result right
away.
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/125
|
| |/
|
|
| |
This affects gitlab-ci and travis-ci, which both run this script.
|
| |
|
|
|
|
|
|
|
| |
Split DNS usually refers to "Split Horizon DNS" whereas "Conditional
Forwarding" is specifically for what the documentation describes.
[thaller@redhat.com: rewrote commit message]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/143
|
| | |
|
| |
|
|
| |
nm_dhcp_client_start_timeout()
|
| | |
|
| |
|
|
|
| |
This allows the linker to put the variable into read-only memory,
which is desirable here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type of the "data" pointer may not be compatible with the type of
the "to_free" / output pointer. This is due to constness, and that we
are unable in C to remove constness from a type.
For example,
{
const char *const *data = ...;
gs_free const char **cpy_to_free = NULL;
const char **cpy;
cpy = nm_memdup_maybe_a (300, data, NM_PTRARRAY_LEN (data) + 1, &cpy_to_free);
}
is prefectly valid , but would not have compiled.
It shows that "data" is not of type "*(&cpy_to_free)", but rather
it might be a non-const pointer of the same type.
Fixes: d0e1d0e626d1 ('shared: propagate types in nm_malloc_maybe_a(), nm_malloc0_maybe_a(), nm_memdup_maybe_a()')
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Always ensure that the entire buffer is initialized with padding NULs.
For example, valgrind checks whether we access uninitalized memory,
so leaving this uninitalized can be unexpected and cause valgrind
failures. In general, one might be tempted to copy the ifname buffer (of
well known size IFNAMSIZ) with memcpy(). In that case, we should not
have trailing garbage there.
We could use strncpy() for that (which guarantees NUL padding), but
then we still would have to ensure NUL termination. But strncpy() is
frowned upon, so let's not use it here.
Note that g_strlcpy() does not guarantee NUL padding, so it's
unsuitable.
We could also implement this with a combination of memcpy() and
memset(). But in this case, it just seems simpler to iterate over the
16 bytes and do it manually.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==6207== Syscall param ioctl(SIOCETHTOOL) points to uninitialised byte(s)
==6207== at 0x514603B: ioctl (syscall-template.S:78)
==6207== by 0x19FC2F: _ioctl_call (nm-platform-utils.c:183)
==6207== by 0x1A026B: _ethtool_call_handle (nm-platform-utils.c:319)
==6207== by 0x1A031F: ethtool_get_stringset (nm-platform-utils.c:378)
==6207== by 0x1A03BC: ethtool_get_stringset_index (nm-platform-utils.c:414)
==6207== by 0x1A181E: nmp_utils_ethtool_supports_vlans (nm-platform-utils.c:912)
==6207== by 0x1756D7: link_supports_vlans (nm-linux-platform.c:6508)
==6207== by 0x1A81D8: nm_platform_link_supports_vlans (nm-platform.c:1536)
==6207== by 0x14B96B: test_internal (test-link.c:602)
==6207== by 0x4F5C18D: test_case_run (gtestutils.c:2597)
==6207== by 0x4F5C18D: g_test_run_suite_internal (gtestutils.c:2685)
==6207== by 0x4F5BF33: g_test_run_suite_internal (gtestutils.c:2697)
==6207== by 0x4F5C679: g_test_run_suite (gtestutils.c:2772)
==6207== by 0x4F5C694: g_test_run (gtestutils.c:2007)
==6207== by 0x166B4D: main (test-common.c:2092)
==6207== Address 0x1ffeffeecf is on thread 1's stack
==6207== in frame #1, created by _ioctl_call (nm-platform-utils.c:110)
==6207==
"ifname" is the stack-allocated array "known_ifnames" of suitable
IFNAMSIZ bytes. But it may not be fully initialized, so using memcpy()
to copy the string leads to unintialized warning.
We really should only copy the valid bytes, either with strcpy() or our
nm_utils_ifname_cpy() wrapper.
Fixes: 856322562eff ('platform/ethtool,mii: retry ioctl when interface name was renamed for ehttool/mii')
|
