| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=764750
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=764955
|
|\
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=764956
|
| | |
|
|/ |
|
|
|
|
| |
Show ignored devices in debug level.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Since commit 44768f0311deb9082c69e3525693091a59788ebb, we skip
exposing NMIPAddress instances with prefix zero. Now, that is
supported and we can remove the check.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Adding addresses with a prefix of zero is valid. Don't
reject them.
Note that this is an actual bug. If you configure an
address with prefix length zero, nmcli will report:
$nmcli connection
(process:1040): libnm-WARNING **: Ignoring invalid IP4 address: Invalid IPv4 address prefix '0'
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Lots of cleanup and refactoring. Most notably, make the
prefix-length property guint8.
Also fix keeping the route cache in sync when "modifying"
an existing route via `ip route change` or `ip route replace`.
|
| |
| |
| |
| |
| |
| |
| | |
When adding a link, set both NLM_F_CREATE and NLM_F_EXCL
flags.
`ip route add` and systemd-networkd sets NLM_F_EXCL too.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Consider:
unshare -n
ip link add d0 type dummy
ip link add d1 type dummy
ip link set d0 up
ip link set d1 up
ip addr add 192.168.100.5/24 dev d0
ip addr add 192.168.101.5/24 dev d1
ip route add 192.168.200.0/24 via 192.168.100.1
ip monitor &
ip route change 192.168.200.0/24 via 192.168.101.1
#prints 192.168.200.0/24 via 192.168.101.1 dev d1
ip route show
#192.168.100.0/24 dev d0 proto kernel scope link src 192.168.100.5
#192.168.101.0/24 dev d1 proto kernel scope link src 192.168.101.5
#192.168.200.0/24 via 192.168.101.1 dev d1
Note that `ip route change` replaced the exising route. "Replaced" in this
case means: the previous route on device "d0" got removed and a new route
on "d1" was added. However, kernel only sent one RTM_NEWROUTE event, no
RTM_DELROUTE that notifies about this change.
We need to workaround that by re-synching the routes when we receive a
RTM_NEWROUTE notification.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We aim to keep the platform cache up-to-date only via the netlink
events. However, due to kernel shortcomings we often have to resync
by re-requesting the data, which especially for routes and addresses
means a full dump (as you cannot request only specific route/address
information).
Thus it makes sense to avoid expensive dumps whenever we can.
We schedule dumps via "delayed-actions" and that is already smart
so that muliple schedulings are combined. However, before requesting
a new dump, we clear the flag that indicates that a dump is scheduled.
Thus, while processing the result of of a dump, we would re-schedule
anew which can be necessary in some cases.
In certain cases, we don't require a full resync, when we are in the
middle of processing a dump, because that one dump will provide us
with the full picture. Thus, we can avoid scheduling a new dump if
- we already scheduled a delayed action
- we are in the middle or processing a dump.
This can now be checked via delayed_action_refresh_all_in_progress().
|
| |
| |
| |
| | |
This makes more sense with the next commit.
|
| | |
|
| |
| |
| |
| |
| | |
This is not for performance. It's to separate the relavant
parts from a part that is only for logging/asserts.
|
| | |
|
| |
| |
| |
| | |
Will be used also from the tests.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of returning only TRUE/FALSE, return the number of signals
that were received while waiting. This make the API cleared, because
previously I always had to check anew whether wait-for-signal returns
TRUE or FALSE on timeout.
Also, add nmtstp_assert_wait_for_signal() and nmtstp_assert_wait_for_signal_until()
macros.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows tests to use these functions on a different platform instance
then on the singleton. The change makes the argument list longer, which is
unfortunate. On the other hand, it makes those functions more useful
in general.
You can't have it all.
Also, they now follow the pattern of most functions in NM where the type
is a singleton: you always pass the singleton to the function, although
in the usual case there is only one singleton instance. This allows to
use the function also on the non-singleton instance.
|
| |
| |
| |
| | |
core
|
| |
| |
| |
| | |
prefix
|
| |
| |
| |
| |
| | |
Make it clear that they are nmtstp functions, i.e. they are found
in the header "test-common.h".
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
On netlink layer, this field is uint8_t/uchar.
A larger (signed) plen makes no sense. Adjust the signatures
to have only guint8.
|
| |
| |
| |
| |
| |
| |
| | |
On netlink layer, this field is uint8_t/uchar.
A larger (signed) plen makes no sense. Adjust the signatures
to have only guint8.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
of union
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.
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| | |
Instead of same_prefix() in nm_ip6_config_destination_is_direct(),
use nm_utils_ip6_address_same_prefix().
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1265239
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In general we don't touch the externally set default route on devices
that use a generated-assumed connection. When the IP method is AUTO
(or DHCP), this means that we are not able to restore the default
route after a temporary expiration of the lease which removes
addresses/routes from the device.
Change this, and let NM update the default route for generated-assumed
devices using dynamic addressing.
https://bugzilla.redhat.com/show_bug.cgi?id=1265239
|
|/
|
|
|
|
|
|
| |
The applied connection must describe the configuration that was
initially activated on the device. Even if the IP configuration
changes, we shouldn't reset the applied connection for devices using a
generated-assumed connection, otherwise we would lose information on
the IP method we're trying on the device.
|
|\ |
|
| |
| |
| |
| | |
It's included from GFDL 1.1+ document; it should be GFDL too.
|