The 9b79e6c73 commit moved setting of the MTU from IP4Config to NMDevice, but
VPN connections don't have a NMDevice instance (yet). Set the MTU also from the
VPN connection. Also, copying of the MTU to the IP4Config is no longer needed
as the ip4_config_commit no longer sets the MTU.
Fixes: 9b79e6c732https://bugzilla.gnome.org/show_bug.cgi?id=754781
(cherry picked from commit e0fa48f224)
g_dbus_proxy_get_cached_property_names() function can return NULL.
Program received signal SIGSEGV, Segmentation fault.
on_bss_proxy_acquired (proxy=0x7fffe4003880 [GDBusProxy], result=0x895490, user_data=<optimized out>) at supplicant-manager/nm-supplicant-interface.c:159
159 while (*iter) {
(gdb) bt
#0 0x000000000048fac7 in on_bss_proxy_acquired (proxy=0x7fffe4003880 [GDBusProxy], result=0x895490, user_data=<optimized out>)
at supplicant-manager/nm-supplicant-interface.c:159
#1 0x0000003bf84728b7 in g_simple_async_result_complete (simple=0x895490 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#2 0x0000003bf8472919 in complete_in_idle_cb (data=<optimized out>) at gsimpleasyncresult.c:775
#3 0x0000003bf5c497fb in g_main_context_dispatch (context=0x7d6420) at gmain.c:3111
#4 0x0000003bf5c497fb in g_main_context_dispatch (context=context@entry=0x7d6420) at gmain.c:3710
#5 0x0000003bf5c49b98 in g_main_context_iterate (context=0x7d6420, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#6 0x0000003bf5c49ec2 in g_main_loop_run (loop=0x7d64e0) at gmain.c:3975
#7 0x00000000004349d6 in main (argc=1, argv=0x7fffffffe598) at main.c:486
https://bugzilla.redhat.com/show_bug.cgi?id=1266003
(cherry picked from commit 33527341b1)
Depending on the network and the values of the 'dad_transmits' and
'retrans_timeout_ms' sysctls, DAD for the IPv6LL address can take
quite a while. Obviously there must be some upper bound on the
timeout, but 5 seconds seems a bit low. In this case it was observed
to be ~12 seconds but the sysctl values are unknown. In any case,
we can't predict the network/config so being a bit more lenient here
makes sense.
https://bugzilla.redhat.com/show_bug.cgi?id=1101809
(cherry picked from commit 5b374a4a9f)
If SIM in a modem is locked, ModemManager can't initialize SupportedIpFamilies
and NetworkManager will set the property to 0. ModemManager then updates the
property after the modem is unlocked, but NetworkManager did not watch changes
to the property. And that resulted in a connection failure:
(ttyUSB1): Failed to connect 'O2 Internet': Connection requested IPv4 but IPv4 is unsuported by the modem.
(ttyUSB1): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28]
https://bugzilla.redhat.com/show_bug.cgi?id=1263959
(cherry picked from commit eecb4c46cc)
Got a crash with unknown reason on nm-1-0 branch. It's unclear why,
but the reason could be that a lease in client_receive_advertise()
was cleared, but not its timers.
Backtrace from nm-1-0 branch (note that the systemd code where the crash
happend is different, but similar):
#0 sd_event_source_unref (s=0xf5c007e8fb894853) at dhcp-manager/systemd-dhcp/nm-sd-adapt.c:53
#1 0x0000555555682340 in client_timeout_t1 (s=<optimized out>, usec=<optimized out>, userdata=0x5555559f5240)
at dhcp-manager/systemd-dhcp/src/libsystemd-network/sd-dhcp6-client.c:451
#2 0x00005555556a078f in time_ready (source=0x5555559f3c20) at dhcp-manager/systemd-dhcp/nm-sd-adapt.c:146
#3 0x00007ffff4a481b3 in g_timeout_dispatch () from /lib64/libglib-2.0.so.0
#4 0x00007ffff4a4779a in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#5 0x00007ffff4a47ae8 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0
#6 0x00007ffff4a47dba in g_main_loop_run () from /lib64/libglib-2.0.so.0
#7 0x0000555555597073 in main (argc=1, argv=0x7fffffffe2b8) at main.c:512
Equivalent upstream systemd patch:
https://github.com/systemd/systemd/pull/1332f89087272bhttps://bugzilla.redhat.com/show_bug.cgi?id=1260727
(cherry picked from commit 401a2eb834)
sd_event_source is either used for sd_event_add_io() or sd_event_add_time().
Depending on the use, different fields of the struct are relevant. Refactor
the struct to have a union.
This reduces the size of the struct, but more importantly, it makes it
clear which fields are used in which context.
(cherry picked from commit 2d2d742cf1)
Systemd supports omitting the output source argument. In this case,
the created event source is floating and the reference count
is handled properly.
We have however no callers that make use of that functionality, so
instead of implementing floating references, assert that we don't
need it.
This isn't a change in behavior, because previously the could would just
SEGFAULT if a caller didn't want to take ownership of the created event.
(cherry picked from commit 02c51d4231)
It is common that the callbacks unref the event source. Hence we must
ensure that the @source stays alive until the callback returns.
(cherry picked from commit 9901047ae3)
Especially systemd, which makes use of the error argument for logging, likes
to represent errors as negative numbers. We hence must invert a negative error
code to get the real errno.
(cherry picked from commit d6370d09e6)
NetworkManager set wpa_supplicant's fragment_size option to 1300. But if MTU
was lower, wpa_supplicant failed with "l2_packet_send - sendto: Message too
long" due to fragmentation of EAP-TLS or EAP-PEAP packets.
Actually, MTU has to be 14 bytes bigger than the "fragment_size" parameter.
Ideally, wpa_supplicant would take MTU in the account and adjust the
fragmentation limit accordingly. See discussion in
http://lists.shmoo.com/pipermail/hostap/2015-August/033546.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=755145
(cherry picked from commit 94bbe7465f)
When we receive an update for a link, cancel a scheduled
REFRESH_LINK delayed-action for that ifindex. At the point when we
scheduled refrehing the link, we only cared about receiving a
notification that was newer then the current state.
We scheduled requesting this new notification to resync the cache.
It is not necessary to actually request a new update, any update we
receive *after* requesting a new update will suffice.
This potentially saves extra round-trips re-requesting the link.
(cherry picked from commit f4f4e1cf09)
When moving a link to another netns, it gets removed from
NMPlatform's view.
Currently kernel does not sent a notification to inform about
that change (see related bug rh#1262908).
Ensure that we reload all linked interfaces which now might
have an invisible parent.
(cherry picked from commit 2cd6aaa918)
Due to a bug, we would only handle one REFRESH_LINK delayed action
and ignore the ones queued afterwards.
Fixes: 051cf8bbde
(cherry picked from commit eee240ffe8)
Defect type: CHECKED_RETURN
3. NetworkManager-1.0.6/src/platform/nm-linux-platform.c:1145: check_return: Calling "clock_gettime" without checking return value (as is done elsewhere 6 out of 7 times).
(cherry picked from commit 0f694f1a9a)
The GATEWAY from /etc/sysconfig/network file is used as a default value when
no GATEWAY is in ifcfg file. However, we have to ignore that GATEWAY for
connections without static addresses. Otherwise such connections would be
invalid and would disappear after restart/reaload.
Some notes:
Putting GATEWAY into /etc/sysconfig/network is not recommended, because it
inherently belongs to the ifcfg file as it is a per-interface property.
The recommended practice is to specify GATEWAY in individual ifcfg files and
define DEFROUTE=no if the interface should not get the default route.
But we continue to read GATEWAY from /etc/sysconfig/network for compatibility
reasons.
See also
https://bugzilla.redhat.com/show_bug.cgi?id=896198#c25https://bugzilla.redhat.com/show_bug.cgi?id=896198#c27
Fixes: f17699f4e3https://bugzilla.redhat.com/show_bug.cgi?id=1262972
(cherry picked from commit ed85fcc711)
When a new link is detected, NM tries to generate a default "Wired
connection" in nm_settings_device_added(), but if the link has not
been initialized by udev yet the function returns early because
priv->unmanaged_flags = UNMANAGED_PLATFORM_INIT.
To be sure that a default connection is created is such situation, we
need to call again nm_settings_device_added() after link
initialization.
https://bugzilla.redhat.com/show_bug.cgi?id=1254089
(cherry picked from commit b3b0b46250)
If at the moment when spawning nm-iface-helper dhcp4/slaac
did not yet complete, we would not enable it.
That is wrong. If the connection indicates to use dhcp4/slaac,
it should be used by nm-iface-helper without considering the
current state on the device.
https://bugzilla.redhat.com/show_bug.cgi?id=1260243
(cherry picked from commit b0815813fa)
We do the same for the original MAC address.
A device enslaved to a bond it inherits the bond's MAC address. When
NetworkManager tries to assume a connection the generated cloned-mac property
causes a mismatch with the connection that originally brought up the device,
causing the generated connection to be used instead:
NetworkManager[14190]: <debug> [1424355817.112154] [NetworkManagerUtils.c:1641]
nm_utils_match_connection(): Connection 'eth2' differs from candidate
'bond-slave-eth2' in 802-3-ethernet.cloned-mac-address
https://bugzilla.gnome.org/show_bug.cgi?id=744812https://bugzilla.redhat.com/show_bug.cgi?id=1256430
(cherry picked from commit cd2cef9cab)
There seems to be an issue with glib/ffi that causes failures
to pass enum-typed arguments to signals (related bug rh#1260577).
Add a test for platform signals which, beside NM_CONFIG_SIGNAL_CONFIG_CHANGED,
is the only place where we use enum-typed arguments for signals.
Strangely, this test doesn't cause the failure, so it's unclear why
the workaround was necessary for "config-changed" signal (commit
e7d66f1df6).
(cherry picked from commit 52cd5ee612)
There seems to be a bug in glib/ffi that hits on s390x/ppc64 architecture.
It causes @changes in nm-dns-manager.c:config_changed_cb() to be NONE,
although it is clearly set (see the related bug rh #1260577 for glib).
Workaround this, by making the argument type a plain guint.
Note that the ill behavior is caught by test_config_signal() in
"src/tests/config/test-config.c".
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1062301
(cherry picked from commit e7d66f1df6)
If DHCP fails for an assumed connection, NetworkManager would
transition the device to the FAILED and then to the ACTIVATED state
(because it is assumed); hence if the DHCP server goes temporarily
down the device will go into a permanent state without IP
configuration.
Fix this and try DHCP again after some time when the connection
is an assumed one.
https://bugzilla.redhat.com/show_bug.cgi?id=1246496
This would cause the ip_vti0 generic device (that appears upon insertion of
ip_vti module during libreswan ipsec stack init) to go managed and brought UP.
Without addresses assigned the device would cause all the VPN traffic to
disappear in the oblivion.
(cherry picked from commit 1c46ddf196)
Addresses the clash between the two commits which would cause the parent device
gateway to be overwritten with 0.0.0.0 upon route-based VPN activation:
Fixes: 063677101a
Fixes: 1465c1d326
(cherry picked from commit da2ae8ce4e)
On slow virtual machine, these tests could fail because the
timeout was too low. As in a successful run the timeouts should
not be reached anyway, just extend them.
(cherry picked from commit bf6187e030)
When the DHCPv6 lease received from the server contains multiple
addresses, dhclient generates a new BOUND event for each of
them. Instead of overwriting the previous IP6 configuration for each
BOUND event, we should try to detect if the new configuration belongs
to the same lease and merge its addresses with the existing one in
such case.
This allows NetworkManager to configure multiple addresses on an
interface via DHCPv6.
https://bugzilla.gnome.org/show_bug.cgi?id=681764https://bugzilla.redhat.com/show_bug.cgi?id=1244293
(cherry picked from commit 1d6e8e8da7)
