Fix issues with crappy wifi drivers which send a stream of associate
events before NM can schedule the next activation stage, which actually
scheduled *multiple* next stages. Only allow one stage to be scheduled at
at time, and don't schedule the same stage again if it's already next up
to the plate.
Ignore multiple ports from the same modem device, becuase we can only use one
any exposing more than one in the UI is stupid and useless. This requires some
drunken wandering through the HAL device tree to get the real device that all
the TTYs are owned by.
Second, prefer devices that both HAL and udev think are modems before using
a device that only udev thinks is a modem. This requires that we delay
handling all ttys until HAL has finished sending them, so that if the second
tty is the one HAL thinks is a modem, we use that instead of some other port
that HAL sends first, but which might happen to have udev capabilities.
These devices also need AT+CGREG, they have problems reporting PIN status
correctly the first time, and are schizophrenic about which init strings
are acceptable. Since they provide so many serial ports, filter out
ones we don't care about, and ignore the cdc-ether device that we dont
use yet.
Fake APs created in nm_ap_new_fake_from_connection() didn't get the
right flags due to wrong interpretation of # WPA protos; no protos really
means "all ciphers". Thus the applet wouldn't ask for the right type of
security info if the connection failed; for hidden WPA networks, the applet
would instead ask for WEP keys.
Clean up addition of flags for 'fake' WPA APs in general; pairwise
shouldn't ever include WEP ciphers, and if the connection didn't
include any pairwise or group ciphers, default to "all" as is
expected. Also fix flags for WPA Ad-Hoc networks, since they have
special limitations imposed by the supplicant and drivers.
The first fix didn't cover creating a new adhoc network while already joined
to an existing adhoc network; thus clearing the 'fake' flag wouldn't necessarily
drop the old adhoc network from the scan list, because NM doesn't scan in adhoc
mode, and thus the scan list culling function wouldn't run.
Even if the AP being removed isn't adhoc, it was never found from a scan anyway
(if it had, the fake flag would have been reset) and thus we don't care about
it anymore.
Since NM doesn't scan while associated with an Ad-Hoc BSS (since
scanning in adhoc mode makes most driver quite angry and doesn't
work well anyway) the user-created BSS was never found in the scan
list, and the 'fake' flag wasn't cleared. Thus the BSS stuck
around in NM's scan list forever.
Additionally, ensure that set_current_ap() maintains a reference
to the old AP until after setting the new AP, just in case the same
AP is being set again.
Third, handle IBSS coalescing by always updating the current AP's
address (if it's an Ad-Hoc AP) with the BSSID reported by the card.
The joined Ad-Hoc networks' BSSID will change if the card
coalesces with other stations in the same IBSS, which would make
NM fail to find the currently joined network in the scan list, and
lead to "roamed to (none)" messages and inability to find the
current AP.
Actual Option cards (not cards by other manufacturers that just happen
to use the 'option' driver) are supposed to always use usb interface
0 as the "modem" port, per mail with Option engineering. Only the
"modem" port will emit unsolicited responses like CONNECT which of
course are required to drive the card.
For now, handle multiple serial ports on a vendor/driver basis in the
modem creator function; HAL emits device added signals for the ttys in
random order, so just using the first serial port doesn't work. This was
mainly added for 'hso' devices anyway, for which multiple serial ports are
already handled correctly by the creator.
Fixes a crash with PropertyChanged signals (triggered when using wifi + vpn and
rmmod-ing the driver) where properties_changed_info_destroy() wouldn't get
called on object destruction becuase the GObject finalize method never got
called for the DHCP4Config and IP4Config objects.
We really have wanted to use IFF_LOWER_UP since 2.6.17 for carrier
status, since that's tied to netif_carrier_ok()/netif_carrier_on() in
the kernel. See kernel commit b00055aacdb172c05067612278ba27265fcd05ce
for the introduction of IFF_LOWER_UP.
For now. It doesn't make a lot of sense to have modem probing in udev when
we switch to ModemManager in the future, since ModemManager would have to
re-do pretty much everything the udev-extras prober already did. Thus,
since modem-probe from udev-extras doesn't have much of a future, don't
start using it or requiring it. Move the code into NM instead, but still
use udev for the actual probing.
Previously requiring only v1 was possible, but there are apparently
so many different implementations of v1 that sometimes you have to force
v0 instead.
In combination with udev-extras, this allows automatic detection of modem
capabilties instead of having to keep 10-modem.fdi up-to-date with the hardware
flavor of the week. NMHalManager grabs the originating device of a newly
detected device, passes that to NMManager, which then passes it along to the
device-type-specific creators. The modem creator then asks udev for any
probed modem capabilities, and uses those in perference to any capabilities
HAL reports. HAL capabilities are kept as a fallback.
0.7 requires dbus 1.1 or greater (for system bus activation), so make that
explicit, and remove compat code for D-Bus 0.6 and earlier. Consolidate
the various glib pkgconfig checks into one, since most anything will require
gthread, glib, and gobject anyway. Fixup the docs makefile to be more
automake-compatible and let 'make clean' actually work correctly when
docs are built.
The reconnection timeout would never be canceled, and get rid of the
"disconnected by the system bus" message on exit, which while
technically true was useless due to the pending exit.
Not actually needed, and actually makes securing the daemon harder
from a D-Bus perspective, since both bus names resolve to the same
unique name anyway, and the unique name is what actually gets
matched on inside dbus. Suggestion from Colin Walters.
Since NM is really only a client of the provider's PPP server, and since NM
doesn't have any authentication information to authenticate the remote
peer anyway. Some providers don't set up their servers to allow clients to
ask for authentication from the remote peer either.
