valgrind complains (rightly):
==7702== 15 bytes in 2 blocks are definitely lost in loss record 411 of 6,278
==7702== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7702== by 0x8151E6E: g_malloc (gmem.c:104)
==7702== by 0x816972E: g_strdup (gstrfuncs.c:364)
==7702== by 0x1D6671: nm_properties_changed_signal_add_property (nm-properties-changed-signal.c:235)
==7702== by 0x1AF2D5: nm_dbus_manager_register_exported_type (nm-dbus-manager.c:867)
==7702== by 0x7EE0D3D: g_type_class_ref (gtype.c:2220)
==7702== by 0x7EC9A78: g_object_new_valist (gobject.c:1928)
==7702== by 0x7EC9C10: g_object_new (gobject.c:1559)
==7702== by 0x14A5FC: new_link (nm-device-bridge.c:482)
==7702== by 0x1CF8FD: platform_link_cb (nm-manager.c:2154)
==7702== by 0x988FD8B: ffi_call_unix64 (unix64.S:76)
==7702== by 0x988F6BB: ffi_call (ffi64.c:522)
nm_device_disambiguate_names() will disambiguate them by their
hardware address. This is not very helpful, so detect this case and
use the Bluetooth device name instead.
This function is used by System Settings when showing the list of
network devices.
https://bugzilla.gnome.org/show_bug.cgi?id=740553
(Port of a libnm-gtk patch written by Ryan Lortie.)
During queued_ip_config_change(), we eventually call update_ip_config()
and ip4_config_merge_and_apply(). These functions read the IP configuration
from platform and setup the private ip4_config instance.
Trigger this initialization after constructing the device to setup
the IP configuration.
Before, for unmanaged devices we would not call ip4_config_merge_and_apply()
until the first platform change event.
Note that in the worst case we do some unnecessary work due to this,
because queued_ip_config_change() must already be robust to be called
at any time.
Since 0c136c1e2, we also track the default route for devices
without active-connection (unmanaged). They must not be returned
as best_config() or as best_device(), because the caller don't
expect unmanaged devices here.
This also gets closer to the original behavior of get_best_device()
before merging default-route-manager in d4417e3460
where we also would ignore devices depending on the state.
This fixes an assertion when having an interface unmanaged
and activating it externally:
#0 0x00007ffff6806187 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007ffff6807dea in __GI_abort () at abort.c:89
#2 0x00007ffff6c0aec5 in g_assertion_message (domain=domain@entry=0x5332d5 "NetworkManager", file=file@entry=0x539460 "nm-default-route-manager.c", line=line@entry=1056, func=func@entry=0x539920 <__FUNCTION__.28934> "_ipx_get_best_config", message=message@entry=0x8c9cb0 "assertion failed: (req)") at gtestutils.c:2356
#3 0x00007ffff6c0af5a in g_assertion_message_expr (domain=domain@entry=0x5332d5 "NetworkManager", file=file@entry=0x539460 "nm-default-route-manager.c", line=line@entry=1056, func=func@entry=0x539920 <__FUNCTION__.28934> "_ipx_get_best_config", expr=expr@entry=0x53132f "req") at gtestutils.c:2371
#4 0x000000000049a196 in _ipx_get_best_config (self=<optimized out>, ignore_never_default=ignore_never_default@entry=1, out_ip_iface=out_ip_iface@entry=0x7fffffffd310, out_ac=out_ac@entry=0x0, out_device=0x0, out_vpn=0x7fffffffd318, vtable=0x7a0a00 <vtable_ip4>, vtable=0x7a0a00 <vtable_ip4>) at nm-default-route-manager.c:1056
#5 0x000000000049a3f6 in nm_default_route_manager_ip4_get_best_config (self=<optimized out>, ignore_never_default=ignore_never_default@entry=1, out_ip_iface=out_ip_iface@entry=0x7fffffffd310, out_ac=out_ac@entry=0x0, out_device=out_device@entry=0x0, out_vpn=out_vpn@entry=0x7fffffffd318) at nm-default-route-manager.c:1079
#6 0x00000000004b7518 in update_ip4_dns (self=0x7ecac0 [NMPolicy], out_vpn=0x7fffffffd318, out_device=0x0, out_ac=0x0, out_ip_iface=0x7fffffffd310, ignore_never_default=1) at nm-policy.c:390
#7 0x00000000004b7518 in update_ip4_dns (dns_mgr=0x8623a0 [NMDnsManager], policy=0x7ecac0 [NMPolicy]) at nm-policy.c:406
#8 0x00000000004b99d5 in device_ip4_config_changed (device=0x8844b0 [NMDeviceEthernet], new_config=0x908aa0 [NMIP4Config], old_config=0x908aa0 [NMIP4Config], user_data=0x7ecac0) at nm-policy.c:1260
#9 0x000000368f405d60 in ffi_call_unix64 () at /lib64/libffi.so.6
#10 0x000000368f4057d1 in ffi_call () at /lib64/libffi.so.6
#11 0x00007ffff6ee5b8c in g_cclosure_marshal_generic_va (closure=0x886a40, return_value=0x0, instance=0x8844b0, args_list=<optimized out>, marshal_data=0x0, n_params=2, param_types=0x87d3a0) at gclosure.c:1541
#12 0x00007ffff6ee5144 in _g_closure_invoke_va (closure=closure@entry=0x886a40, return_value=return_value@entry=0x0, instance=instance@entry=0x8844b0, args=args@entry=0x7fffffffd810, n_params=<optimized out>, param_types=0x87d3a0) at gclosure.c:831
#13 0x00007ffff6eff900 in g_signal_emit_valist (instance=0x8844b0, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd810) at gsignal.c:3201
#14 0x00007ffff6f0014f in g_signal_emit (instance=instance@entry=0x8844b0, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3348
#15 0x000000000044a1f4 in nm_device_set_ip4_config (self=self@entry=0x8844b0 [NMDeviceEthernet], new_config=new_config@entry=0x9089a0 [NMIP4Config], default_route_metric=default_route_metric@entry=100, commit=commit@entry=0, reason=reason@entry=0x0) at devices/nm-device.c:5866
#16 0x000000000044a5af in ip4_config_merge_and_apply (self=self@entry=0x8844b0 [NMDeviceEthernet], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at devices/nm-device.c:3037
#17 0x000000000044b4fd in update_ip_config (self=self@entry=0x8844b0 [NMDeviceEthernet], initial=initial@entry=0) at devices/nm-device.c:6617
#18 0x000000000044bc39 in queued_ip_config_change (user_data=<optimized out>) at devices/nm-device.c:6688
#19 0x00007ffff6be4e1b in g_main_context_dispatch (context=0x7ba3a0) at gmain.c:3122
#20 0x00007ffff6be4e1b in g_main_context_dispatch (context=context@entry=0x7ba3a0) at gmain.c:3737
#21 0x00007ffff6be51b0 in g_main_context_iterate (context=0x7ba3a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#22 0x00007ffff6be54d2 in g_main_loop_run (loop=0x7ba460) at gmain.c:4002
#23 0x000000000043291d in main (argc=1, argv=0x7fffffffdef8) at main.c:442
Fixes: da708059da
Enum types larger then the native 'int' type are undefined behavior
according to C standard. Assert that our compiler does the right thing.
the expression that defines the value of an enumeration constant shall
be an integer constant expression that has a value representable as an
int
We trigger a new solicitation upon seeing the new token. Kernel triggers one
too, but that one is of no use to us, since the advertisement might arrive sooner
than we learn about the token change.
This branch brings three major changes:
- when routes or addresses are removed externally,
remove those entiries also from what we want to configure
on the interface. That way, on the next commit, we will
not re-add those externally removed entries.
-- at least not unless the entries reappear due to an
event such as a new DHCP lease.
- the combined NMIPConfig object of a device which is also
exposed via DBUS, will no longer contain those externally
removed entries. The IP config really shows what is actually
configured.
- for default-routes, no longer enforce the default route even
on managed devices. Only during commit phases, we might re-add/
remove a default route from a device, otherwise, pickup the
default route (or its absence) as actually configured.
https://bugzilla.gnome.org/show_bug.cgi?id=740443
Even more eagerly pickup external default routes from the device.
For assumed devices we already picked up the default route.
(a) For assumed devices we already did not enforce the default route at all.
Instead it was always picked up by from the actualy system
configuration. Note that this is the case for assumed-generated
connections and for assuming existing connections.
That means that when NM assumes a connection at startup, it will never
actively manage the default route on that interface. It will only react
on what is present.
(b) For managed devices that have by configuration no default route, still pick up
the default route. That means, that even a device that is managed and
never-default=yes, can have the default route -- if configured externally.
(c) Only during a commit phase (i.e. when we have new configuraiton to be
applied), we enforce the default route or its absence.
(d) During any IP change event from platform, we again pickup whatever
is present. That means if you remove the default route from a managed
interface, NM will not re-add it until anything triggers (c).
This also means, that during the commit phase, we add default routes as
'synced' to the default-route-manager, but the following event from platform,
will change the route entry immediately to 'non-synced'. That is
expected and correct.
When receiving IP changes via platform event, remove all missing
addresses and routes from our internal configurations (such as
wwan, vpn, dhcp).
The effect is that on the next commit, those addresses and routes will
not be re-added as they were explicitly removed by the user.
However on a new DHCP lease or similar events, the addresses will
be added anew.
Another important improvement is that the NMIPxConfig of the active
device reflects when addresses or routes get removed externally. Before
we would continue to expose those entires although they were not
actually configured on the device.
https://bugzilla.gnome.org/show_bug.cgi?id=740443
In the IPv4 case, we check whether we have a direct route to the gateway
also by looking at the configured addresses/subnets. That is correct,
because every IPv4 address also implies a subnet route.
For IPv6, we explicitly add all subnet routes manually (noprefixroute),
hence, we have a direct route exactly if we have it in our list.
Regardless of the configured IPv6 prefixes.
The previous syntax (s/S for synced, n/N for never-default) is confusing.
Indicate 'never-default' by '0', vs. '1'.
Indicated synced/non-synced as '+sync' and '-sync'.
Since 03a5a85d, NMDeviceTeam was trying to use priv->teamd_pid to
decide whether a teamd_dbus_vanished() call indicated "teamd hasn't
been started yet" or "teamd was previously started and has now
exited". But this resulted in a race condition, where at startup, a
device could call g_dbus_watch_name(), then launch teamd (causing
teamd_pid to get set), and then have gdbus report that teamd hasn't
been started yet before the newly-launched teamd managed to grab the
bus name. Since teamd_pid would already be set when
teamd_dbus_vanished() was called, it would decide that this meant
"teamd was previously started and has now exited", so it would call
teamd_cleanup(), killing the just-started teamd process.
Fix this by having teamd_dbus_vanished() check priv->tdc instead,
which doesn't get set until after the first teamd_dbus_appeared()
call.
We forgot to include the BRIDGE, so that bridge
devices got a default priority (route-metric) of 950
Add it between VLAN and MODEM type.
Also return a different metric for UNKNOWN
device types, but these priorities are not
actually expected.
ModemManager needs to have CLOCAL set in the TTY termios configuration, in order
to notify the kernel that modem control lines are not in effect (e.g. so that a
transition to LOW in the DCD input control line doesn't trigger a hangup in the
TTY).
pppd in the other hand, needs CLOCAL unset in order to have proper modem control
lines in effect during the PPP session. So, when pppd starts it will store the
original termios settings, and before exiting it will restore the original
settings in the TTY. In other words, if CLOCAL was set before launching pppd,
CLOCAL will be also set after pppd exits.
Now, in order for this sequence to work correctly, NetworkManager also needs to
make sure that ModemManager is notified about the disconnection only after pppd
has really finished re-configuring the TTY.
https://bugzilla.gnome.org/show_bug.cgi?id=734347
----------------------
Once the patch is applied, we will be making sure that ModemManager is only
notified about the disconnection AFTER pppd has fully exited:
NetworkManager[27589]: <info> (ttyUSB2): device state change: activated -> deactivating (reason 'user-requested') [100 110 39]
Terminating on signal 15
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 10 / phase 'terminate'
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 8 / phase 'network'
Connect time 0.3 minutes.
Sent 56 bytes, received 0 bytes.
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 5 / phase 'establish'
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 11 / phase 'disconnect'
Connection terminated.
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 1 / phase 'dead'
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_exit_notify): cleaning up
NetworkManager[27589]: <warn> pppd pid 27617 exited with error: pppd received a signal
NetworkManager[27589]: <info> (ttyUSB2): modem state changed, 'connected' --> 'disconnecting' (reason: user-requested)
NetworkManager[27589]: <info> (ttyUSB2): modem state changed, 'disconnecting' --> 'registered' (reason: user-requested)
NetworkManager[27589]: <info> (ttyUSB2) modem deactivation finished
NetworkManager[27589]: <info> (ttyUSB2): device state change: deactivating -> disconnected (reason 'user-requested') [110 30 39]
NetworkManager[27589]: <info> (ttyUSB2): deactivating device (reason 'user-requested') [39]
