The statement
g_return_val_if_reached (NM_MODEM_IP_TYPE_UNKNOWN);
was wrong, because the return type is 'const char *'.
But just refactor nm_modem_ip_type_to_string() to get rid of
the static table and make it a switch statement.
Fixes: 85d9132464
No functional change, a cosmetic thing for now.
We want it set before any routes are added and ensure routes have a valid
ifindex before we pass it to the platform.
In a future NMRouteManager will need to look up the route for a device in
its cache thus we'll need to make sure routes passed to the it have an
appropriate ifindex set.
No functional change, a cosmetic thing for now.
We want it set before any routes are added and ensure routes have a valid
ifindex before we pass it to the platform.
In a future NMRouteManager will need to look up the route for a device in
its cache thus we'll need to make sure routes passed to the it have an
appropriate ifindex set.
Create a NMRouteManager singleton.
Refactor, no functional changes apart from change of log domain from
LOGD_PLATFORM to LOGD_CORE.
Subsequent commit will keep track of the conflicting routes, avoid overwriting
older ones with newer ones and apply the new ones when the old ones go away.
When ipv4=auto and ipv6=auto, we'll first try with the IPv4v6 PDP type, and if
that fails (e.g. if either the modem or the operator doesn't support it), we'll
fallback to trying with IPv4 or IPv6 PDP types (only if may-fail configuration
allows it).
Patch based on a previous implementation by Dan Williams <dcbw@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=733696
It's always user requested -- auto activation never happens on already active
devices. nm_device_release_one_slave() rightly asserts teardown with
(un)configuration does not happen for no reason at all.
https://bugzilla.gnome.org/show_bug.cgi?id=744812
It was confusing to understand the difference between calling nm_device_connection_is_available()
and check_connection_available(), they behaved similar, but not really
the same. Especially nm_device_connection_is_available() would look
first into @available_connetions, and might call check_connection_available()
itself. Whereas @available_connetions was also populated by testing
check_connection_available(). This interrelation makes it hard to
understand when nm_device_connection_is_available() returned true.
Rename nm_device_connection_is_available() to nm_device_check_connection_available()
and remove all direct calls of check_connection_available() in favor of
the wrapper nm_device_check_connection_available().
Now we only call nm_device_check_connection_available() with different
parameters (@flags and @specific_object). We also have the additional
guarantee that specifying more @flags will widen the result and making
a connection "more" available, while specifying a @specific_object will
restrict it.
This also changes behavior in several cases. For example before
nm_device_connection_is_available() for user-requests would always
declare matching connections available on Wi-Fi devices (only)
regardless of the device state. Now the device state gets consistently
considered.
For default-unmanaged devices it also changes behavior in complicated
ways, because before we would put connections into @available_connetions
for every device-state, but nm_device_connection_is_available() had a
special over-ride only for unmanaged-state.
This also fixes a bug, that user can activate an unavailable Wi-Fi
device:
nmcli radio wifi off
nmcli connection up wlan0
Having logging statements in a simple getter (or is_*()) means
you cannot call these functions without cluttering the log.
Another approach would be to add an @out_reason argument, and
callers who actually care log the reason. For now, just get rid
of the messages.
The argument name should express what the caller wants
(he wants to know, whether the connection can be activated
for an internal or external activation request).
Whether that involves checking device-specific overrides, is
not the point -- nm_device_check_connection_compatible() is
also a virtual function with device-specific overrides.
Extend nm_match_spec_*() to support an "except:" prefix to negate
the result of a match. "except:" only works when followed by
an exact match type, for example "except:interface-name:vboxnet0",
but not "except:vboxnet0".
A matching "except:" spec always wins, regardless of other positive
matchings.
NMTestDevice does not invoke dispose(), hence it leaks memory which causes
false warnings in testing.
Some minor refactring to let dispose() clear the fields, but free it
later in finalize(). This avoids memleaks in the NMTestDevice stub.
NMDevice rechecks available connections when the device moves to the
DISCONNECTED state, but connections are not available if the modem is
PIN locked at that time. Available connections were never re-checked
when the modem was then unlocked while in the DISCONNECTED state.
When the modem device is abruptly disconnected,
nm_modem_device_state_changed() calls deactivate_cleanup() with a NULL
device argument and that's perfectly fine.
We should only check the instance type if we know the device is non-NULL.
(NetworkManager:9166): NetworkManager-wwan-CRITICAL **: deactivate_cleanup: assertion 'NM_IS_DEVICE ( failed
With this change, NMConfig is really immutable and all
modifyable parts migrated to NMConfigData.
Another advantage is that components can now subscribe to
NMConfig changes to pickup changes to no-auto-default.
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.
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.
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.
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]
