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.
The Huawei cards don't like *any* probing on usb interface #1 (the unsolicited message
port). If anything gets sent to that port, the modem randomly hangs and must be
re-inserted before working again.
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.
The "Auto ethX" connection that the system settings service creates
for each wired device that does not have an existing backing connection
provided by one of the system settings plugins is now read/write when
at least one plugin has the MODIFY capability.
When the user updates the "Auto ethX" connection, the system settings
service will try to move that connection to a plugin, thereby preserving
the user's changes. It will also then save that device's MAC address
and never create an "Auto ethX" connection for it again.
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.
For the moment; until we can optimize the prober. The problem is that a modem
that's not fully powered up and ready to talk looks exactly the same as a tty
that just doesn't support AT commands at all.
Fix a few problems... No plugin should return secrets in the GetSettings method,
which some plugins did. When that was committed in the commit "system-settings:
don't return secrets in the settings", it broke those plugins that didn't implement
GetSecrets. Each plugin can actually use the same code for GetSettings and
GetSecrets, so implement those generically in the NMExportedConnection class and
remove plugin-specific implementations that all did the same thing.
Some cards are just going to need delayed probing if they take
a bit respond to AT commands after being plugged in. We can
optimize further by doing an initial check, waiting a small time
for the response, then checking again at 1s, waiting a small time,
then checking at 2 seconds and waiting for the full timeout for
those devices where --delay is given.
