On netlink layer, this field is uint8_t/uchar.
A larger (signed) plen makes no sense. Adjust the signatures
to have only guint8.
(cherry picked from commit 44768f0311)
On netlink layer, this field is uint8_t/uchar.
A larger (signed) plen makes no sense. Adjust the signatures
to have only guint8.
(cherry picked from commit 14ee5dd2f8)
NMPCacheId is a union with fields for all known NMPCacheIdTypes.
Up to now, we always cloned the entire union, computed the hash
over all (possibly unset) fields and used memcmp() unanimously.
That was ok, because NMPCacheId was 16 bytes in total and cache-id
types that consumed less bytes didn't have a large overhead.
Next, we will add a new cache id type which increases the size of
NMPCacheId to 24 bytes. So, while possibly only a fraction of the
instances is that large, they would all have to pay that price.
Change that to consider and clone only those parts of the id
that are actually used.
(cherry picked from commit b1e3deaf2f)
As we get more NMPCacheIdType values, it's better to have for
each type a pre-declared list of supported types, instead of
iterating over all types and letting _nmp_object_init_cache_id()
figure out that the cache-id-type is unsupported on that object.
(cherry picked from commit fe78ae0b6a)
NM_UTILS_LOOKUP_DEFAULT_NM_ASSERT() is useful because unless
compiled with NM_MORE_ASSERTS, there is no assertion.
An assertion includes the function name, and can make the
function ineligible for inlining.
(cherry picked from commit fbfe2ef216)
Since long, dnsmasq supports scoping the IPv6 address
with '@<interface-name>'. Since 2.58, it also supports
'%' as delimiter, which is the standard way to specify
the zone-id (rfc6874).
Since 2.73, specifying the scope with '@' as "server"
address is no longer working properly, thus breaking
NetworkManager with dnsmasq >= 2.73.
To work around that, use '%' delimiter. That breaks pre-2.58
users that have a DNS server on a link local address, but that
seems acceptable as that version was released in January 2012.
https://bugzilla.gnome.org/show_bug.cgi?id=764839
(cherry picked from commit c328cf52f2)
The applied connection must not be modified during the activation. If
the PPP setting needs to be changed when activating a PPPoE
connection, make a copy to prevent the following error:
could not get secrets:
GDBus.Error:org.freedesktop.NetworkManager.Settings.Failed:
The connection was modified since activation
https://bugzilla.redhat.com/show_bug.cgi?id=1324895
(cherry picked from commit 76309ebe79)
For internal compilation we want to be able to use deprecated
API without warnings.
Define the version min/max macros to effectively disable deprecation
warnings.
However, don't do it via CFLAGS option in the makefiles, instead hack it
to "nm-default.h". After all, *every* source file that is for internal
compilation needs to include this header as first.
If the manager removes the device, the IP config objects must
be cleared. The reason is that NMPolicy registers to the IP config
changed signal and passes these object on to NMDnsManager.
If the INTERNAL_DEVICE_REMOVED signal is emited with IP configuration
object pending, those objects will be leaked.
This partly redoes commit f72816bf10,
which was reverted.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=764483
We want to unregister the signals at cleanup time via
g_signal_handlers_disconnect_by_data(). This saves us from
storing the signal handler id or by naming the function
explicitly via g_signal_handlers_disconnect_by_func().
However, the registered user-data @self is a public pointer. That
is ugly, because potentially another component could register a
signal with passing the public @self pointer as user-data.
Although that doesn't currently happen, it is more correct to register
with a private pointer to avoid this case altogether.
Instead of a G_TYPE_INSTANCE_GET_PRIVATE() call every time,
fetching the private data becomes a pointer dereference.
As only one instance of NMPolicy exists, this costs us only
one additional pointer of memory.
Software devices created by NM should be kept up when quitting so that
they can be assumed upon restart. But now we consider devices created
by NM (those with the @is_nm_owned flag) not capable of assuming
connections and therefore we tear them down and deconfigure when
quitting.
Change this and ignore @is_nm_owned when deciding if a device can be
re-assumed.
First let the device know it's being removed soon so that it has a
chance to clean up the IP configuration early.
If the manager removes the device fist, the policy never learns of
config removal and doesn't unhook it from the DNS manager resulting in a
IPConfig leak and possible wrong DNS configuration in effect.
Also adjust the route manager to skip over devices without IP
configuration when determining the best connection; it is perhaps
just due to being removed.
https://bugzilla.gnome.org/show_bug.cgi?id=764483
Later in NMDevice's rdisc_config_changed(), we already reject
routes with plen==0. Just do it earlier.
We would however not reject bogus routes with a prefix larger then 128.
That would later lead to an error when trying to add such a route to the
kernel.
Don't use memset() and set the fields afterwards. Instead use
designated initializers.
Also, move the temporary variables closer to where they are used.
