summaryrefslogtreecommitdiff
path: root/src/dhcp
AgeCommit message (Collapse)AuthorFilesLines
2018-04-12build: meson: use run-nm-test.sh to run testsBeniamino Galvani1-1/+5
Like autotools, use the wrapper script 'run-nm-test.sh' that starts a separate D-Bus session when needed.
2018-04-11dhcp/systemd: ensure aligned memory access in ip6_start() for duidThomas Haller1-8/+5
It probably was no problem in practice, because very likely the chunk of memory was aligned already. Also, drop non helpful comment and fix whitespace.
2018-03-20dhcp: remove unused nm_dhcp_dhclient_read_lease_ip_configs() functionThomas Haller7-486/+0
2018-03-20dhcp: remove unused nm_dhcp_manager_get_lease_ip_configs() functionThomas Haller7-101/+0
2018-03-15dhclient: write client-id with backslash and quotes as hexBeniamino Galvani2-2/+32
2018-03-15dhcp: dhclient: set type 0 for printable client IDsBeniamino Galvani2-16/+113
The documentation for the ipv4.dhcp-client-id property says: If the property is not a hex string it is considered as a non-hardware-address client ID and the 'type' field is set to 0. However, currently we set the client-id without the leading zero byte in the dhclient configuration and thus dhclient sends the first string character as type and the remainder as client-id content. Looking through git history, the dhclient plugin has always behaved this way even if the intent was clearly that string client-id had to be zero padded (this is evident by looking at nm_dhcp_utils_client_id_string_to_bytes()). The internal plugin instead sends the correct client-id with zero type. Change the dhclient plugin to honor the documented behavior and add the leading zero byte when the client-id is a string. This commit introduces a change in behavior for users that have dhcp=dhclient and have a plain string (not hexadecimal) set in ipv4.dhcp-client-id, as NM will send a different client-id possibly changing the IP address returned by the server. https://bugzilla.gnome.org/show_bug.cgi?id=793957
2018-03-12core/dbus: rework D-Bus implementation to use lower layer GDBusConnection APIThomas Haller1-14/+16
Previously, we used the generated GDBusInterfaceSkeleton types and glued them via the NMExportedObject base class to our NM types. We also used GDBusObjectManagerServer. Don't do that anymore. The resulting code was more complicated despite (or because?) using generated classes. It was hard to understand, complex, had ordering-issues, and had a runtime and memory overhead. This patch refactors this entirely and uses the lower layer API GDBusConnection directly. It replaces the generated code, GDBusInterfaceSkeleton, and GDBusObjectManagerServer. All this is now done by NMDbusObject and NMDBusManager and static descriptor instances of type GDBusInterfaceInfo. This adds a net plus of more then 1300 lines of hand written code. I claim that this implementation is easier to understand. Note that previously we also required extensive and complex glue code to bind our objects to the generated skeleton objects. Instead, now glue our objects directly to GDBusConnection. The result is more immediate and gets rid of layers of code in between. Now that the D-Bus glue us more under our control, we can address issus and bottlenecks better, instead of adding code to bend the generated skeletons to our needs. Note that the current implementation now only supports one D-Bus connection. That was effectively the case already, although there were places (and still are) where the code pretends it could also support connections from a private socket. We dropped private socket support mainly because it was unused, untested and buggy, but also because GDBusObjectManagerServer could not export the same objects on multiple connections. Now, it would be rather straight forward to fix that and re-introduce ObjectManager on each private connection. But this commit doesn't do that yet, and the new code intentionally supports only one D-Bus connection. Also, the D-Bus startup was simplified. There is no retry, either nm_dbus_manager_start() succeeds, or it detects the initrd case. In the initrd case, bus manager never tries to connect to D-Bus. Since the initrd scenario is not yet used/tested, this is good enough for the moment. It could be easily extended later, for example with polling whether the system bus appears (like was done previously). Also, restart of D-Bus daemon isn't supported either -- just like before. Note how NMDBusManager now implements the ObjectManager D-Bus interface directly. Also, this fixes race issues in the server, by no longer delaying PropertiesChanged signals. NMExportedObject would collect changed properties and send the signal out in idle_emit_properties_changed() on idle. This messes up the ordering of change events w.r.t. other signals and events on the bus. Note that not only NMExportedObject messed up the ordering. Also the generated code would hook into notify() and process change events in and idle handle, exhibiting the same ordering issue too. No longer do that. PropertiesChanged signals will be sent right away by hooking into dispatch_properties_changed(). This means, changing a property in quick succession will no longer be combined and is guaranteed to emit signals for each individual state. Quite possibly we emit now more PropertiesChanged signals then before. However, we are now able to group a set of changes by using standard g_object_freeze_notify()/g_object_thaw_notify(). We probably should make more use of that. Also, now that our signals are all handled in the right order, we might find places where we still emit them in the wrong order. But that is then due to the order in which our GObjects emit signals, not due to an ill behavior of the D-Bus glue. Possibly we need to identify such ordering issues and fix them. Numbers (for contrib/rpm --without debug on x86_64): - the patch changes the code size of NetworkManager by - 2809360 bytes + 2537528 bytes (-9.7%) - Runtime measurements are harder because there is a large variance during testing. In other words, the numbers are not reproducible. Currently, the implementation performs no caching of GVariants at all, but it would be rather simple to add it, if that turns out to be useful. Anyway, without strong claim, it seems that the new form tends to perform slightly better. That would be no surprise. $ time (for i in {1..1000}; do nmcli >/dev/null || break; echo -n .; done) - real 1m39.355s + real 1m37.432s $ time (for i in {1..2000}; do busctl call org.freedesktop.NetworkManager /org/freedesktop org.freedesktop.DBus.ObjectManager GetManagedObjects > /dev/null || break; echo -n .; done) - real 0m26.843s + real 0m25.281s - Regarding RSS size, just looking at the processes in similar conditions, doesn't give a large difference. On my system they consume about 19MB RSS. It seems that the new version has a slightly smaller RSS size. - 19356 RSS + 18660 RSS
2018-03-12core: rename "nm-bus-manager.h" to "nm-dbus-manager.h"Thomas Haller1-1/+1
The next commit will completely rework NMBusManager and replace NMExportedObject by a new type NMDBusObject. Originally, NMDBusObject was added along NMExportedObject to ease the rework and have compilable, intermediate stages of refactoring. Now, I think the new name is better, because NMDBusObject is very strongly related to the bus manager and the old name NMExportedObject didn't make that clear. I also slighly prefer the name NMDBusObject over NMBusObject, hence for consistancy, also rename NMBusManager to NMDBusManager. This commit only renames the file for a nicer diff in the next commit. It does not actually update the type name in sources. That will be done later.
2018-03-10dbus: extend NM_DEFINE_GDBUS*() helper macrosThomas Haller1-6/+2
2018-02-28dhcp: fix uninitialized pointer in DHCP listener's _method_call_handle()Thomas Haller1-1/+1
Fixes: f67269b49d22278e0a70dad1fb52c5b015c12cf6
2018-02-15dhcp: inject client-id in GBytes format from NMDevice to ↵Thomas Haller4-22/+7
nm_dhcp_manager_start_ip4() Convert the string representation of ipv4.dhcp-client-id property already in NMDevice to a GBytes. Next, we will support more client ID modes, and we will need the NMDevice context to generate the client id.
2018-02-15dhcp: refactor type of NMDhcpClient duid to be GBytesThomas Haller11-72/+87
GBytes is immutable. It's better suited to contain the duid parameter then a GByteArray.
2018-02-15dhcp: refactor type of NMDhcpClient hwaddr to be GBytesThomas Haller5-31/+30
GByteArray is a mutable array of bytes. For every practical purpose, the hwaddr property of NMDhcpClient is an immutable sequence of bytes. Thus, make it a GBytes.
2018-02-15dhcp: initialize use_fqdn and info_only paramters in constructorThomas Haller3-21/+39
The two boolean properties do not need to be ever reset. It's nice to initialize such properties in the constructor and don't mutate them afterwards. Instead of adding two boolean GObject properties, add a new flags property that can encode these two values. In the end, properties are too cumbersome, let's combine them.
2018-02-15dhcp: cache info-only parameter in NMDhcpClientThomas Haller6-13/+18
Optimally, NMDhcpClient would be stateless and all paramters would be passed on as argument. Clearly that is not feasable, because there are so many paramters, and in many cases they need to be cached for the lifetime of the client instance. Instead of passing info_only paramter to ip6_start() and cache it both in NMDhcpClient and NMDhcpSystemd, keep it in NMDhcpClient at one place. In the next commit, we will initialize info-only only once during the constructor, so it is immutable and somewhat stateless.
2018-02-15dhcp: chain up parent stop() for NMDhcpSystem clientThomas Haller3-2/+2
The parent's stop() implementation does nothing interesting for NMDhcpSystem. Still, call it, it's just unexpected to not chain up the parent implementation, if all other subclasses do it. In general, if the parent's implementation is not suitable to be called by the derived class, that should be handled differently then just not chaining up. Otherwise it's inconsistent and confusing.
2018-02-15dhcp: fix memleak parsing dhclient file with multiple dhcp-client-identifier ↵Thomas Haller2-1/+6
lines
2018-02-12dhcp: use NM_DEFINE_GDBUS_INTERFACE_INFO() macros to define D-Bus ↵Thomas Haller1-33/+17
registration info for DHCP listener
2018-02-12dhcp: mark descriptor tables for D-Bus as static constThomas Haller1-10/+10
Marking static variables as const will result in write-protected memory, which is a desired property.
2018-02-07all: replace non-leading tabs with spacesThomas Haller3-12/+12
We commonly only allow tabs at the beginning of a line, not afterwards. The reason for this style is so that the code looks formated right with tabstop=4 and tabstop=8.
2018-02-07dhcp/tests: don't use tab characters in string literalThomas Haller1-14/+14
I think we should avoid non-trailing tabs in source code. Allowing unescaped tab characters in string literals, adds noise when searching the code for non-trailing tabs. Also, depending on the editor configuration, it might be non-obvious that tabs are used. And while I dislike tabs in general, I think they are especially bad, when they have actual meaning in code.
2018-01-18all: require glib 2.40Lubomir Rintel1-2/+0
RHEL 7.1 and Ubuntu 14.04 LTS both have this. https://bugzilla.gnome.org/show_bug.cgi?id=792323
2018-01-11build/meson: use variables for ldflags and linker-scriptThomas Haller1-5/+1
2018-01-10build/meson: unconditionally use linker version scriptsThomas Haller1-4/+3
We also unconditionally use them with autotools. Also, the detection for have_version_script does not seem correct to me. At least, it didn't work with clang.
2018-01-10meson: Improve dependency systemIñigo Martínez2-6/+3
Some targets are missing dependencies on some generated sources in the meson port. These makes the build to fail due to missing source files on a highly parallelized build. These dependencies have been resolved by taking advantage of meson's internal dependencies which can be used to pass source files, include directories, libraries and compiler flags. One of such internal dependencies called `core_dep` was already in use. However, in order to avoid any confusion with another new internal dependency called `nm_core_dep`, which is used to include directories and source files from the `libnm-core` directory, the `core_dep` dependency has been renamed to `nm_dep`. These changes have allowed minimizing the build details which are inherited by using those dependencies. The parallelized build has also been improved.
2018-01-09dhcp: fix check for client-id in _set_client_id()Thomas Haller1-0/+1
Fixes: 686afe531ab3774cd818feda8361de74101971f5
2018-01-08tests: use NMTST_EXPECT*() macrosThomas Haller1-14/+7
Tests are commonly created via copy&paste. Hence, it's better to express a certain concept explicitly via a function or macro. This way, the implementation of the concept can be adjusted at one place, without requiring to change all the callers. Also, the macro is shorter, and brevity is better for tests so it's easier to understand what the test does. Without being bothered by noise from the redundant information. Also, the macro knows better which message to expect. For example, messages inside "src" are prepended by nm-logging.c with a level and a timestamp. The expect macro is aware of that and tests for it #define NMTST_EXPECT_NM_ERROR(msg) NMTST_EXPECT_NM (G_LOG_LEVEL_MESSAGE, "*<error> [*] "msg) This again allows the caller to ignore this prefix, but still assert more strictly.
2018-01-08build: refine the NETWORKMANAGER_COMPILATION defineThomas Haller1-1/+2
Note that: - we compile some source files multiple times. Most notably those under "shared/". - we include a default header "shared/nm-default.h" in every source file. This header is supposed to setup a common environment by defining and including parts that are commonly used. As we always include the same header, the header must behave differently depending one whether the compilation is for libnm-core, NetworkManager or libnm-glib. E.g. it must include <glib/gi18n.h> or <glib/gi18n-lib.h> depending on whether we compile a library or an application. For that, the source files need the NETWORKMANAGER_COMPILATION #define to behave accordingly. Extend the define to be composed of flags. These flags are all named NM_NETWORKMANAGER_COMPILATION_WITH_*, they indicate which part of the build are available. E.g. when building libnm-core.la itself, then WITH_LIBNM_CORE, WITH_LIBNM_CORE_INTERNAL, and WITH_LIBNM_CORE_PRIVATE are available. When building NetworkManager, WITH_LIBNM_CORE_PRIVATE is not available but the internal parts are still accessible. When building nmcli, only WITH_LIBNM_CORE (the public part) is available. This granularily controls the build.
2018-01-04dhcp: cleanup handling of ipv4.dhcp-client-id and avoid assertion failureThomas Haller5-27/+84
The internal client asserts that the length of the client ID is not more than MAX_CLIENT_ID_LEN. Avoid that assert by truncating the string. Also add new nm_dhcp_client_set_client_id_*() setters, that either set the ID based on a string (in our common dhclient specific format), or based on the binary data (as obtained from systemd client). Also, add checks and assertions that the client ID which is set via nm_dhcp_client_set_client_id() is always of length of at least 2 (as required by rfc2132, section-9.14).
2018-01-04dhcp: track dhcp-client instances with CList instead of hash-tableThomas Haller3-45/+34
NMDhcpManager used a hash table to keep track of the dhcp client instances. It never actually did a lookup of the client, the only place where we search for an existing NMDhcpClient instance is get_client_for_ifindex(), which just iterated over all clients. Use a CList instead. The only thing that one might consider a downside is that now NMDhcpClient is aware of whether it is part of a list. Previously, one could theoretically track a NMDhcpClient instance in multiple NMDhcpManager instances. But that doesn't make sense, because NMDhcpManager is a singleton. Even if we would have mulitple NMDhcpManager instances, one client would still only be tracked by one manager. This tighter coupling of NMDhcpClient and NMDhcpManager isn't a problem.
2017-12-18all: get rid of a handful of unused-but-set variablesLubomir Rintel1-2/+2
2017-12-13dhcp: systemd: support the hostname propertyBeniamino Galvani1-0/+8
Send the FQDN option when a hostname is set.
2017-12-13build: add initial support for meson build systemIñigo Martínez2-0/+44
meson is a build system focused on speed an ease of use, which helps speeding up the software development. This patch adds meson support along autotools. [thaller@redhat.com: rebased patch and adjusted for iwd support] https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00022.html
2017-11-16all: use nm_direct_hash() instead of g_direct_hash()Thomas Haller2-2/+2
We also do this for libnm, where it causes visible changes in behavior. But if somebody would rely on the hashing implementation for hash tables, it would be seriously flawed.
2017-11-16all: don't use g_direct_equal() for hash table equality functionThomas Haller1-1/+1
GHashTable optimizes a NULL equality function to use direct pointer comparison. That saves the overhead of calling g_direct_equal(). This is also documented behavior for g_hash_table_new(). While at it, also don't pass g_direct_hash() but use the default of %NULL. The behavior is the same, but consistently don't use g_direct_hash().
2017-10-30dhcp: add support for dhcpcanon clientjuga04-2/+278
https://github.com/NetworkManager/NetworkManager/pull/31
2017-10-18dhcp: include "nm-dhcp-manager.h" in "nm-dhcp-listener.c"Thomas Haller1-0/+1
"nm-dhcp-manager.h" forward declares _nm_dhcp_manager_factories. We need to make the definition aware of the declaration, so that the compiler can warn if they differ.
2017-10-18core,clients: use our own string hashing function nm_str_hash()Thomas Haller4-5/+5
Replace the usage of g_str_hash() with our own nm_str_hash(). GLib's g_str_hash() uses djb2 hashing function, just like we do at the moment. The only difference is, that we use a diffrent seed value. Note, that we initialize the hash seed with random data (by calling getrandom() or reading /dev/urandom). That is a change compared to before. This change of the hashing function and accessing the random pool might be undesired for libnm/libnm-core. Hence, the change is not done there as it possibly changes behavior for public API. Maybe we should do that later though. At this point, there isn't much of a change. This patch becomes interesting, if we decide to use a different hashing algorithm.
2017-10-17shared: split random and hash utilsThomas Haller1-0/+1
"nm-utils/nm-shared-utils.h" shall contain utility function without other dependencies. It is intended to be used by other projects as-is. nm_utils_random_bytes() requires getrandom() and a HAVE_GETRANDOM configure check. That makes it more cumbersome to re-use "nm-shared-utils.h", in cases where you don't care about nm_utils_random_bytes(). Split nm_utils_random_bytes() out to a separate file. Same for hash utils, which depend on nm_utils_random_bytes(). Also, hash utils will eventually be extended to use siphash24.
2017-10-13dhcp: use nm_utils_random_bytes() for generating random DUIDThomas Haller1-6/+1
2017-10-10core: rework tracking of gateway/default-route in ip-configThomas Haller7-43/+101
Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
2017-10-09core: use ipv4.route-table setting for other IPv4 routesThomas Haller9-11/+62
Including device-routes, default-route, DHCPv4, IPv4LL.
2017-10-06dhcp/trivial: rename "priority" variables to "route_metric" in DHCP codeThomas Haller9-49/+46
The name "priority" is well established for routes (e.g. kernel's RTA_PRIORITY netlink attribute). However, we call it at most places "metric" or "route_metric". Rename it, not to use two different names for the same thing.
2017-10-04dhcp: cleanup handling method-call in DHCP listenerThomas Haller1-29/+32
Split out a separate function _method_call_handle(). That way we can get rid of the "goto out" and use cleanup attribute to manage resources inside _method_call_handle().
2017-09-21dhcp: use systemd defines for DHCP optionsThomas Haller1-36/+34
2017-09-21systemd: merge branch systemd into masterThomas Haller1-1/+1
2017-09-18dhcp: consider a timeout equal to MAXINT32 as infinityFrancesco Giudici2-3/+14
This will avoid to spawn internally a timer for the lease to complete.
2017-09-15dhcp: dhclient: remove the --timeout argument from the command lineFrancesco Giudici4-39/+57
the --timeout command line option is a custom feature added in some linux distributions (fedora). Passing that command line argument will make dhclient fail if the binary does not support it, preventing activation of dhcp based connections. Worse, the option has just been recently changed from "-timeout", so that we are currently incompatibile with Centos, RedHat and older versions of Fedora too. Leverage the "timeout" option in dhclient config file: it will produce the expected behavior and will be universally supported. Fixes test: dhcp-timeout Fixes: fa46736013fa1e3df1508b1f67b495ce45daf94a https://bugzilla.redhat.com/show_bug.cgi?id=1491243
2017-09-11core/dhcp: use addr-family parameter for instead of booleanThomas Haller10-133/+163
In many cases we want to treat IPv4 and IPv6 generically. That looks nicer if we distingish by an @addr_family integer, instead of a boolean. Replace the @is_ipv6 boolean with an @addr_family paramter. The @is_ipv6 boolean is inconsistent with other places where we use @is_ipv4 to indicate the opposite. Eventually, we should use @addr_family everywhere. Also, at the call site it's not immediately clear what TRUE/FALSE means, here AF_INET/AF_INET6 is better.
2017-09-11device: enable support for ipv6.dhcp-timeoutThomas Haller3-7/+8
- cleanup data type and use guint32 consistently. We might want to introduce a new "infinity" value. But since libnm's NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range 0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity will have the numerical value G_MAXINT32, hence guint32 is just fine. - make use of existing ipv6.dhcp-timeout setting and add global default configuration in NetworkManager.conf - instead of having subclasses call nm_device_set_dhcp_timeout(), add a virtual function get_dhcp_timeout().