EAP-FAST used to require some patches to OpenSSL which aren't always
applied. We can't depend on the supplicant supporting EAP-FAST like
we can for EAP methods that don't require any special support from
external libraries. To ensure the error gets reported correctly and
early, fail the configuration step if EAP-FAST isn't supported by
the supplicant but the connection requests it.
Modems take a bit of time, and ModemManager may not quite be
ready for immediate connect after sending the PIN since the
modem isn't enabled. The specific issue was that MM is still
closing serial ports, so if we try to enable too soon we'll
get an error about serial ports being closed.
BSS info apparently doesn't get updated that often since it's
based on scan information, so instead use the AP info which updates
with every beacon. Using the BSS info caused the signal to
be the same value over long periods of time even when moving far
away from the AP.
Consolidate device creation in the manager object; bluetooth and
modem devices were already handled by it, so it makes sense to do
it all from one place. Furthermore we'll be creating virtual devices
in the manager too. It also reduces indirection (no need to send
device_creator() in the DEVICE_ADDED signal) and makes the code
flow clearer.
All of the information in the configuration files for local caching
dnsmasq or BIND servers are accessible already over the D-Bus
interface, so there's no sensitive information here.
Allows clients to retrieve the reason a device changed to
the given state along with the state itself, preventing
race conditions if the state were retrieved separately
from the reason. Reason codes were not previously
accessible without listening to the StateChanged signal.
We do not want to break other methods, when EAP-FAST specific error condition
is detected: no PAC file provided and automatic PAC provisioning is disabled.
Adds a new "master" property to NMActiveConnection containing the path
of the master NMDevice if the connection has a master.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Speed is gotten via ethtool on 'carrier on' event. If there is a more suitable
netlink event we should use it instead. Nonetheless, it appears to be working
fine with carrier change, because interface speed change does emit carrier offi
and on events.
If the route already exists and the kernel tells us that, we
don't need to do anything. We certainly don't need to warn
about it in the logs.
There was a typo in the IPv6 default route replace function that
ignored a returned error, and thus we didn't suppress the NLE_EXIST
error like we wanted to. Do the same for the IPv4 default route
while we're at it.
Callers of this function have a better idea of they want to
log errors or not. Let them handle it, since they already
do, and having a warning here was causing duplicate log
messages.
Don't set default values for the properties, which didn't allow users to
switch off sending echo-request packets. Rather set defaults in editor
or while completing connection for modems.
On systems without backtrace suport (E.G. uClibc depending on config),
execinfo.h might not be available, breaking the build.
Fix it by only including it if enabled.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We'll use this to request identity and passwords in-band during
the connection attempt instead of sending them all at the
beginning. This should allow better handling of wrong
passwords (since we'll know we need to request them from the
user interactively) and better error codes when things fail.
839c7909 made NM ignore this interface based on faulty
information about what the interface did. It's actually
just a normal network interface that the N900 can use
to talk to the host or whatever. It's a bit annoying
that for the most part it won't be used and that NM will
keep attempting to connect it with DHCP unless the user
changes the connection to be static IP (N900 defaults to
address 192.168.2.15 and expects the computer to be
192.168.2.14 and requires an ifup in it's Xterm app) but
if you have an N900 you're probably more knowledgable
than most.
http://wiki.maemo.org/N900_USB_networking
