This can happen e.g. when D-Bus limits number of replies and there's
a lot of connections. Then nm_remote_settings_list_connections() won't
return all connections and the connection that was activated can be among
the missing connections.
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.
GValueArray is deprecated as of GLib 2.32, but we need to use it for
dbus-glib stuff. So use the new GLIB_VERSION_MIN_REQUIRED macro to
prevent those warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=669613
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)
When '-nocheck' option was used, NMClient object was created later in the
operation process.
This caused that the callback in nm_client_activate_connection() was not
called. It's fixed by creating NMClient early.
We need to use a workaround for VPN connection state. There is a bug somewhere
causing that vpn-state-changed signal is not issued on active VPN connection.
Debugging showed that D-Bus PropertiesChanged and VpnStateChanged signals are
not processed properly. That's why libnm-glib's VPN connection object is not
updated. The issue may lie in libnm-glib or even in dbus-glib.
I wasn't able to get VpnStateChanged signal via dbus-glib
(dbus_g_proxy_add_signal() and dbus_g_proxy_connect_signal()), however received
the signal successfully using GDBus.
Until the issue is analyzed and fixed, we need to ask for VPN state of active
VPN connection every second in order to show progress and exit correctly.
Some drivers (ipw2x00) support capabilities reporting via nl80211 but
absolutely nothing else. NM was only checking for capabilities
when deciding whether or not to use nl80211 to communicate with the
driver for associated AP, signal strength, and channel info, and that
clearly fails with half-implementations of nl80211 in the kernel.
Instead, match the logic that wpa_supplicant uses to determine whether
to stick with nl80211 or fall back to WEXT. For these drivers
NM will now fall back to WEXT and should return to the behavior we
had with 0.9.2 for these devices.
mac80211 drivers don't like being asked to scan when they are already
scanning, and it's pretty impossible to not race with internal
supplicant scanning. NM requests a scan immediately after the
supplicant interface gets created, and that scan request usually
succeeds. But since the supplicant's scan request method returns
when the kernel *starts* the scan, not when the scan is finished,
a second scan that NM would immediately request in
request_wireless_scan() would often fail as the card was already
scanning.
The second scan was requested immediately becuase the SCAN_INTERVAL_MIN
was zero, which was set to zero to intentionally request two scans
to work around drivers that would fail the first scan because they
are stupid.
Well, let's just penalize stupid drivers by *possibly* making the
initial connection take a few more seconds due to the change of
SCAN_INTERVAL_MIN. But what we're really doing here is not asking
for the second scan right after the first one is requested, since
that will almost always fail for most drivers, but request the
second one after the supplicant says the scan is done.
Second, if for some reason the supplicant reports that the scan failed,
don't make the next scan take longer; just queue it up without backing
off so we can retry the scan sooner.
NMDeviceWifi and a few other things expect the interface will
move from STARTING to READY and then on to other states. But the
state was getting set to the actual supplicant interface state
immediately when the first properties were read (which include
the State property) and thus the READY state got bypassed. But
we also want to read stuff like the capabilities before letting
the interface be used.
So first, ensure the supplicant interface object actually uses the
READY state like its callers expect, and second, don't set the
READY state until we actually know what we need to know about it.
Allows better encapsulation of the functionality of the NMSettings
object that we want to expose to the device class. They don't need
the whole object so to keep things simple and contained we'll just
give them a smaller interface to use.
