The info is extracted via SIOCETHTOOL ioctl() syscall using ETHTOOL_GDRVINFO.
This works for most drivers but not all, e.g. for modems. We may figure out how
to get the info for specific devices, and enhance the solution by implementing
specific functions for particular device types later.
Usually if the BT link goes down we'll get some other signal of
failure, like PPP disconnect, or a Bluetooth disconnect. But if
the modem disappears from ModemManager for some reason while its
connected, make sure we clean up everything correctly.
The disconnect request gets sent just as a precaution, but usually when
the device fails the modem is already gone from ModemManager and the
Disconnect() method will fail. Just don't log the failure.
Allows devices to generically request authorization from the manager
for whatever operation they want, and allows us to keep the devices
from including the auth code directly.
DHCPv6 IA_NA assignments do not contain a prefix length, they are for a
single address (/128) only. However, the ISC DHCPv6 client incorrectly
assumes IA_NA assignments come with a implicit prefix length of /64, and
passes this incorrect information on to NetworkManager, which adds this
prefix as a on-link route. This will cause communication failures in
certain networks, for example NBMA networks, and in organisations using
longer prefix lengths than /64 for their LANs. For more discussion
regarding this problem, see RFC 5942 section 5.
This patch makes NM ignore the false prefix length attribute provided by
the ISC DHCPv6 client, instead setting it to a /128 (single address) in
all cases. Note that this does not preclude an on-link prefix from being
added by NM if it is being advertised in the correct way, i.e., by
including a Prefix Information Option with the L flag set in an ICMPv6
Router Advertisement.
For what it's worth I've also sent a patch to ISC to change the hard-
coded implicit prefix length value from /64 to /128 in [ISC-Bugs #29468].
The bug report describes a testing scenario where device is down
and no IPv4 or IPv6 addresses are set up. Then NetworkManager
is started and it decides not to configure DHCPv6 address. This
is caused by code copied from IPv4 that does not work here at
all (and I wonder if it does in IPv4).
In any case, when NetworkManager starts a DHCP client and recieves
an IPv6 address (no addresses are configured at the time), it
*must* send this new IPv6 address to the kernel.
(dcbw)
We should fix the connection takeover code for IPv6 but it's not
a quick fix so in the mean time disable the buggy code and we'll
fix IPv6 takeover cleanly soon.
Bug #676317 describes the following error:
NetworkManager[30151]: <error> [1337348764.559121] [nm-system.c:1121]
nm_system_replace_default_ip6_route(): (eth1): failed to set IPv6 default
route: -7
The above error is caused by NetworkManager assuming default gateways
belong to addresses but failing to setup default gateways for addresses
learned through DHCPv6.
This commit doesn't fix the fundamental issue but can be viewed as an ugly
workaround that gets IPv6 connection up and running. It doesn't fix
the fundamental flaw of binding gateways to IP addresses. They are
configured separately in IPv6 and NM should use lifetimes and allow
default gateway reconfiguration.
If the VPN plugin sends an empty IPv4 or IPv6 config, then treat it
like has-ip4/has-ip6 was FALSE. This way the plugin can just always
claim has-ip6 initially, and then send a blank config if it finds out
later that this particular connection doesn't do IPv6.
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
Even if a VPN is only tunneling IPv4, you might still be connected to
the tunnel endpoint via IPv6. Allow
NM_VPN_PLUGIN_IP4_CONFIG_EXT_GATEWAY to be either an IPv4 or an IPv6
address, and set up an appropriate static route either way.
libnl1 doesn't check the first argument and crashes on NULL.
I got NULL gateway out of rtnl_route_get_gateway() for link local and
multicast routes (fe80::/64, ff00::/8).
If there was an existing dhclient config file, don't leak it when
merging to the new configuration.
Found by Mathieu Trudel-Lapierre <mathieu@canonical.com>
There is are global caches of IPv6 addresses and routes. Only
managed devices are synchronized later. We *may* move
to per-device caches in the future but for now we should
keep the caches up to date.
Introduce logging of individual address and route changes. Rename
process_addr() and process_route() to process_address_change() and
process_route_change() so that it is clear that we react to both
addition and deletion.
Every state change should go through device_set_state(). This
static function provides state change logging. Function
state_to_string is moved up so that we can use it.
Split nm_ip6_device_sync_from_netlink into multiple functions.
It will now call the smaller functions and may disappear entirely
in the future.
To share state between these (and possible future) functions,
move local variables found_linklocal, found_other and dhcp_opts
to NMIP6Device as has_linklocal and has_nonlinklocal and dhcp_opts.
The kernel appears to always add a default route pointing to the router
that sent the RA, regardless of the contents of the RA:
ndisc_router_discovery() calls rt6_add_dflt_router() which calls
ip6_route_add() which calls __ip6_ins_rt() which calls fib6_add() which
calls fib6_add_rt2node(), which calls inet6_rt_notify(RTM_NEWROUTE, rt,
info)
So skip listening for RTM_NEWPREFIX and just rely on NEWROUTE instead.
The config_changed lost its meaning because RTM_NEWPREFIX was the only
case where it was FALSE.
It is bound to autoconnect_inhibit private variable (has opposite meaning).
While 'Autoconnect' is TRUE (default value) the device can automatically
activate a connection. If it is changed to FALSE, the device will not
auto-activate until 'Autoconnect' is TRUE again.
Disconnect() method sets 'Autoconnect' to FALSE. NMPolicy monitors the property
and schedules auto activation when FALSE->TRUE transition is made.
Commit 217c5bf6ac fixed processing of unix
signals: signals are blocked in all threads and a dedicated thread handles the
signals using sigwait().
However, the commit forgot that child processes inherit signal mask as well.
That is why we have to unblock signals for child processes we spawn from NM, so
that they can receive signals.
Instead of using the device's type number, which is a poor measure of
routing priority since it has nothing to do with routing priority,
let's make the decision more explicit.
The code to set up ATM interfaces is actually pretty simple,
so don't bother spawning br2684ctl at all. Just do the
necessary communication with the kernel directly and save
a bunch of code.
Note: this isn't very likely to work as I don't have an
ADSL connection to test with. Testing help appreciated.
This is the "juice" of the patch series. Initial cut at carrier handling
(by polling /sys/class/atm/$iface/carrier) and also support for calling
pppd with the proper command-line to achieve a connection.
Also implement the necessary boilerplate for the NM state machine to
be happy with our device.
This is a "duct tape and gum" implementation, i.e., prefer copy&paste
over proper refactoring, due to limited time, but the foundations are
now there, so we can make it work right slowly-slowly :)
With this patch, you can already test carrier management but not yet
make a complete connection.
Relevant extract from logs:
<info> (ueagle-atm0): carrier now ON (device state 20)
<info> (ueagle-atm0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
This patch adds the settings code (NMSettingAdsl) and the initial
"scaffolding" i.e., a tiny stub version of NMDeviceAdsl and the
udev handler code to get the device detected.
With this patch you should be able to see an atm device being detected
by networkmanager in the logs, although of course it doesn't
do anything useful yet.
Extract from the logs:
[1304668252.341354] [nm-udev-manager.c:562] adsl_add(): adsl_add: ATM Device detected from udev. Adding ..
(ueagle-atm0): failed to look up interface index
(ueagle-atm0): new ADSL device (driver: 'ueagle-atm' ifindex: -1)
(ueagle-atm0): exported as /org/freedesktop/NetworkManager/Devices/2
(ueagle-atm0): now managed
(ueagle-atm0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
(ueagle-atm0): deactivating device (reason: 2).
[1304668252.345102] [nm-system.c:1349] flush_routes(): (ueagle-atm0) failed to lookup interface index
[1304668252.347821] [nm-device.c:3912] nm_device_state_changed(): (ueagle-atm0): device is available,
In this version, we hack the nm-device.c:nm_device_get_priority() to get better priority
instead of changing the DeviceType enum.
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
Finding out interface type from interface name string is fragile. It is easily
broken, e.g. by biosdevname changing interface names to em<n> or p<n>*p<n>.
Sadly, Gentoo network configuration scripts are rather stupid, using format:
variable_${interface|mac|essid|apmac}.
http://www.gentoo.org/doc/en/handbook/2007.0/handbook-x86.xml?full=1#book_part4_chap2
The entries interface|mac|essid|apmac are basically indistinguishable. It's not
possible to say whether 'p1p1' is an interface or SSID, for example.
Fix the current behaviour a bit by checking whether the string is an interface.
If so, and it is not a Wi-Fi one, set the connection type as wired. Else it is
regarded as wireless.
To simplify NMManager and to make use of the new connection provider
functionality, move the logic for when a paired Bluetooth device
is actually usable for network connections or not into the bluez
manager and out of NMManager. The general direction should be towards
moving this sort of logic out of the manager and into the device
specific stuff, like we did with the WiMAX bits, so we can make
stuff into plugins.
Kernel ifindexes are always greater than zero (see dev_new_index()
in net/core/dev.c). Also don't bother warning about ifindex
lookup failures for devices we know aren't kernel network interfaces.
The libertas driver now uses nl80211 for mesh, and wifi-utils chooses to
use wifi-utils-nl80211.
The wifi-utils-nl80211 code does not have implementations for
mesh_get_channel/mesh_set_channel and this breaks mesh networking.
Adding these methods under nl80211 is a little painful.
For now, force use of wifi-utils-wext to restore mesh networking.
The DHCP code usually ignores dhclient state transitions to the
same state it's currently in. This turns out to be wrong, since
dhclient will use the same reason code (which NM uses for the
state value) for operations like RENEW and REBIND. i.e. you'll
see states like this:
BOUND
RENEW (first renew)
RENEW (second renew)
RENEW (third renew)
etc
Therefore to ensure we trigger dispatcher scripts and internal
housekeeping code for renewals we need to make sure we process
these events even though they use the same state as the previous
event.
The DHCP code usually ignores dhclient state transitions to the
same state it's currently in. This turns out to be wrong, since
dhclient will use the same reason code (which NM uses for the
state value) for operations like RENEW and REBIND. i.e. you'll
see states like this:
BOUND
RENEW (first renew)
RENEW (second renew)
RENEW (third renew)
etc
Therefore to ensure we trigger dispatcher scripts and internal
housekeeping code for renewals we need to make sure we process
these events even though they use the same state as the previous
event.
The various nm_ip[46]_config_add_* routines were inconsistent in their
behavior when trying to add a duplicate item: add_address() and
add_route() would add it anyway; add_nameserver() and add_wins() would
g_return_if_fail(); and add_domain() and add_search() would return
silently. Update to use the "return silently" behavior everywhere.
In particular: if we get an RDNSS message listing the same nameserver
twice, don't cause a warning. (rh #820752)
