| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to an extremely subtle bug in tracking the autoconnect state from
connman on through to iwd, iwd was incorrectly being sent zero-initialized
default data as the autoconnect value.
In particular, what happened is as follows:
- A new iwd_network is created for the iwd.Network that appears, which
also creates an associated connman_network. In the process of creating
the connman_network, the iwd plugin receives a callback that correctly
sets the cm_autoconnect state of the iwd_network.
- Connman's Service.Connect() function is called via D-Bus, which calls
into the iwd plugin, which in turn calls iwd.Network.Connect() over
D-Bus.
- The connection completes and the following fire:
- iwd.KnownNetwork created event, which is supposed to initialize the
cm_autoconnect state to that of the iwd_network, but this does not
occur since the iwd_network does not yet have a KnownNetwork
associated, so it remains uninitialized
- PropertyChanged event on the corresponding iwd.Network object,
with the new KnownNetwork property value, springing the trap set
earlier by synchronizing the zero-initialized
iwd_known_network.cm_autoconnect state to the iwd KnownNetwork
In practice, this looks like:
-> net.connman.iwd.Network.Connect() on /net/connman/iwd/0/3/0000000000000000000000_psk
<- RequestPassphrase()
-> (passphrase)
-> Set('AutoConnect', False) on /net/connman/iwd/0000000000000000000000_psk
This was found by investigating why my computer was not automatically
connecting to some networks after coming out of sleep, and finding that
the iwd AutoConnect setting was false on those networks while connman
thought it was true (in fact, this was the case! The connman iwd plugin
thought otherwise).
Reproduction:
connmanctl> agent on
Agent registered
connmanctl> config wifi_9cb6d0f7daaf_00000000_managed_psk --remove
connmanctl> connect wifi_9cb6d0f7daaf_00000000_managed_psk
Agent RequestInput wifi_9cb6d0f7daaf_00000000_managed_psk
Passphrase = [ Type=psk, Requirement=mandatory ]
Passphrase? 00000000
Connected wifi_9cb6d0f7daaf_00000000_managed_psk
$ busctl get-property net.connman.iwd /net/connman/iwd/00000000_psk net.connman.iwd.KnownNetwork AutoConnect
b false
Then sleep the machine and observe that the network is not automatically
reconnected.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
On WPA3-SAE authentication, wpa_supplicant goes directly from
authenticating to disconnected state if the key was invalid.
The above is currently not handled and the `connect-failed` error is
reported on such cases. In order to make the client agent prompt for a
new password, we need to handle this transition and report the
`invalid-key` error.
|
| |
|
|
|
|
|
| |
It is no more possible to connect to a secure network, after entering
an invalid passphrase format, for example 64 characters.
In this case, the user agent still needs to be called, to request a new
passphrase.
|
| | |
|
| |
|
|
|
| |
When a service is manually removed, the associated network, at driver
side, needs to be forgotten, to remove the corresponding known network.
|
| |
|
|
|
|
|
|
|
|
|
| |
For Broadcom BCM4356 chipset with brcmfmac driver, changing from AP mode
to station mode returns -EBUSY if the wireless interface is a member of
a bridge.
To resolve the issue, the wireless interface is removed from the tether
bridge before changing the mode rather than after.
Fixes: 648ed549f0ac ("iwd: Add support for tethering")
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the signal strength reported by connman being lower when using iwd
compared to wpa_supplicant.
In the wifi plugin for wpa_supplicant, the signal strength is calculated
as follows:
strength = 120 + g_supplicant_network_get_signal(supplicant_network);
if (strength > 100)
strength = 100;
The g_supplicant_network_get_signal() function returns the signal
strength in dBm. This means the signal strength calculation in connman
for wpa_supplicant treats -20 dBm or higher as 100% signal strength.
The iwd plugin is changed to use the same calculation but as iwd returns
returns the signal strength as 100 * dBm, it needs to be divided by 100
to get the same dBm value as wpa_supplicant.
|
| |
|
|
| |
Fixes: 648ed549f0ac ("iwd: Add support for tethering")
|
| |
|
|
|
|
|
|
| |
In ssid_init(), the pointer members of GSupplicantSSID *ssid was
initialised to point to members of a connman_network, which get
freed and replaced, causing ssid's pointers to point to freed heap
memory. To mitigate this, these members are duplicated and then
freed and along with ssid when no longer needed.
|
| |
|
|
|
| |
Only reachable networks, with a significant signal strength, shall be
marked as available.
|
| |
|
|
|
|
|
|
| |
During a failing connection on a secure network with no passphrase,
agent_request_passphrase() crashes, trying to manipulate the value
of the "WiFi.Passphrase" key, which is null.
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
|
| |
|
|
|
| |
The station shall be searched in stations table instead of networks.
Fixes: 8371114aaef9 ("iwd: Hookup manual scan trigger")
|
| |
|
|
|
| |
When the tethering mode is started, a WiFi AP is created using the fixed
channel 1 (2412 MHz). Add a way to configure the channel.
|
| |
|
|
|
|
| |
connman_technology is an opaque type but has all the parameters to handle
the connection. Those parameters are only used in wifi tethering
one and not in other technologies
|
| |
|
|
|
|
|
| |
Before connecting to a new network, the currenty connected one shall be
disconnected, what always failed with "Operation timeout" error, as
the disconnection seemed not completed, cm_network_disconnect
returning -EINPROGRESS on success.
|
| |
|
|
|
|
| |
The Method, Address, Netmask and Gateway attributes of IPv4/6 Service
property were not flushed at network disconnection, because its
associating state was not reset.
|
| |
|
|
|
|
|
| |
The Interface, Address and MTU attributes of Ethernet Service property
were not retrieved because the interface index was specified to late
(at network connection instead of creation), preventing the access
to the corresponding ipconfig.
|
| |
|
|
|
|
|
|
| |
Instead of reporting EINVAL report EALREADY to return correct
information back to the caller. This way caller knows that the call was
not to a wrong identifier but the VPN has already been requested to
shut down. The error eventually translates to InProgress D-Bus message
back to the caller.
|
| |
|
|
|
|
|
|
|
|
|
| |
Refactor connect_reply() to be extendable for more fine grained error
handling.
Add handling of ENOLINK error that is reported back by vpnd when a VPN
cannot be connected because connmand is in offline state. ENOLINK is to
be handled as any other error causing the VPN state not to change later
on that in turn would cause the cb_data->callback() never getting
called.
|
| |
|
|
|
|
|
| |
There is little point in trying to handle out of memory
situation. Most GLib function do fail with calling abort() when memory
allocation fails, e.g. g_strdup(). So fail hard when allocation the
iwd data structures.
|
| |
|
|
|
|
|
|
|
| |
Implement WPA3-SAE authentication on connman side using wpa_supplicant
backend.
Initially based on Tizen project:
https://review.tizen.org/git/?p=platform/upstream/connman.git
|
| |
|
|
|
|
|
|
| |
Ensure homogeneity of config options management by replacing
connman_option_get_string() by connman_setting_get_string(), and
removing irrelevant option.h header file.
Fix a memory leak on vendor class id option.
|
| |
|
|
|
|
|
| |
g_memdup got marked as depricated in favor for g_memdup2 since GLib
v2.68 which is the very same version g_memdup2 was introduced. We
don't want to increase the minium GLib version to latest greatest
hence open code this function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the user ask explicitly to connect to a network and the operations
fails for any reason the ConnMan core will go from either idle or
connected to failure state. In failure state the core will call
connman_network_disconnect() which will be propagated to iwd.
ConnMan will set the AutoConnect flag on KnownNetwork on
bootup/discovery. iwd tries interpretes this as request to connect
now. If this is not possible, e.g. out of reach, iwd response with an
failure. This disables the auto connect mode of iwd.
So the simplest thing here is not to tell the core the connect fails,
instead just don't do anything if auto connect is enabled. This keeps
the auto connect of iwd working and ConnMan's state machine doesn't
care either.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating a new know network object, check if we have already a
registered network object with the autoconnect flag. If we find one,
update the value of the known network object.
During the initial D-Bus API discovering, ConnMan will create the
network objects first. This means the core will see the new network
and will try to use iwd's auto connect mode. Also ConnMan will set the
AutoConnect flag for the (ConnMan's) known networks. At this point
though, the plugin has not yet discovered the known networks object
from the D-Bus API. Thus, the initial AutoConnect value could be lost.
In theory this is not necessary but it is possible that ConnMan's
state and iwd state do not match, e.g. the user has disabled the
autoconnect via iwdctl.
This can lead to the situation where ConnMan thinks the AutoConnect
flag has been set but it is not and hence iwd's auto connect is not
enabled and hence no auto connect.
|
| |
|
|
|
|
|
|
|
|
| |
gcc points out the destination buffer has the same size the specified
bound for the string:
warning: ‘__builtin_stpncpy’ specified bound 16 equals destination size [-Wstringop-truncation]
Let's make sure we do not overflow the buffer (should not happen as
the names are provide by the kernel and hence should fit).
|
| |
|
|
|
|
|
|
|
| |
Return the service_ident with "Transport" keyword given to
get_property(). Plugin tracks the transport and this is can be used
elsewhere as well.
It is important to free the service_ident after notifying provider about
state change as the service_ident is used for IPv6 checks when disconnecting.
|
| |
|
|
|
|
|
| |
The error text indicates that it could not start AccessPoint mode when
it is actually trying to stop AccessPoint mode.
Fixes: 648ed549f0ac ("iwd: Add support for tethering")
|
| |
|
|
|
|
|
|
|
| |
To avoid staying stuck in "Operation aborted" error state when
connecting, the disconnecting status shall be reset by each disconnect
callback, whatever network is involved, even if not previously
connected.
Fixes: dd86f09107e8 ("wifi: Always disconnect connection completely")
|
| |
|
|
|
|
|
| |
Check the involved network validity in disconnect callback, to avoid
side effects, as crashing, when processing an already released one.
Fixes: dd86f09107e8 ("wifi: Always disconnect connection completely")
|
| |
|
|
|
|
| |
Before being able to connect to a new network, finish disconnecting
the old connection. The wifi->network object can change while the
disconnect_callback is scheduled.
|
| |
|
|
|
|
|
|
|
| |
When the BSS expiration age is under the long scanning interval, the
list of available networks will periodically lose the unconnected (but
still present) ones, and only be repopulated after next scan.
Setting the BSS expiration age to match the long scanning interval
prevents this undesirable behaviour.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For Broadcom BCM4356 chipset with brcmfmac driver, the IFF_LOWER_UP flag
did not always change state in wifi_newlink() but remained set when
changing from STA mode to AP mode. This resulted in handle_tethering()
not being called to add the wireless interface to the tether bridge.
To resolve the issue, always call handle_tethering() as long as the
IFF_LOWER_UP flag is set instead of only when IFF_LOWER_UP changes
from unset to set. The handle_tethering() function already has checks
in place to avoid adding the wireless interface to the tether bridge
more than once.
|
| |
|
|
|
|
| |
gcc complains 'struct vpn_route' is declared within the code section.
By declaring it at the begin of the function we can also avoid the
additional helper variables.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When adding connection check also SplitRouting value and set it
accordingly via provider. Process the SplitRouting variable also when
VPN property changes.
Use the new inet.c functions to get network, netmask and gateway for
VPNs that are split routed that have no other routes set. In that case
add the network route as split routed VPNs must have at least a single
route to VPN network. Check that for non-split routed VPNs the default
route is added and prevent adding default route for split routed VPNs.
Improve check_route() by also checking that the split routed VPN has
more than the default route set. A VPN cannot be set split routed if it
does not have at least one route set.
Always do a route check when changing split routing value via D-Bus. The
check is to make sure that when set as split routed the VPN has at least
one network route set. If not, the functionality described above will
add one.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding broadcast address for VPNs is not permitted by "ip route" and it
messes up the use of getifaddrs() for getting the destination address.
Adding broadcast address for P2P connections is also unnecessary. This
change adds a simple boolean to toggle whether the address change
concerns a VPN or any other service, to toggle adding of IFA_BROADCAST.
Naturally this only affects IPv4 VPNs.
The issue fixed here is easy to reprocude by connecting a VPN, then
checking the destination address with ioctl() using SIOCGIFDSTADDR flag for
IFF_POINTOPOINT type interface, and then using getifaddrs() for the same
interface by checking the ifa_flags for flag IFF_POINTOPOINT to get the
destination address.
The toggle for P2P/VPN connections is saved in struct connman_ipaddress,
and is set with new function connman_ipaddress_set_p2p() to avoid
API/ABI breakage.
Also changed connman_inet_clear_ipv6_address() to use the struct
connman_ipaddress as other set/clear_ipv4/6_address functions do.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the D-Bus docs, dbus_pending_call_set_notify "sets a
notification function to be called when the reply is received or the
pending call times out".
Thus, we should not expect any further calls to the registered function
than the one that was triggered. If the idea is wait for a longer
period of time, this can be done with increasing the timeout. Meanwhile,
the possible causes of a timeout is the other party not sending it at
all, which in my testing was possible to be achieved by crashing the
other process.
If we let the callback function just return without unref-ing the
pending call, we get a memory leak.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the D-Bus docs, dbus_pending_call_set_notify "sets a
notification function to be called when the reply is received or the
pending call times out".
Thus, we should not expect any further calls to the registered function
than the one that was triggered. If the idea is wait for a longer
period of time, this can be done with increasing the timeout. Meanwhile,
the possible causes of a timeout is the other party not sending it at
all, which in my testing was possible to be achieved by crashing the
other process.
If we let the callback function just return without unref-ing the
pending call, we get a memory leak.
If vpnd crashes before sending connmand a reply to GetConnections, the
particular vpn_connection data structure will have both connect_pending
set to true, and call set to the pending call that would not receive any
response anymore, and a re-established vpnd process would not attempt
a reconnection.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConnMan crashes happens in cancel_host_resolv in plugins/vpn.c. It
seems that the function gets called twice on the same data.
cancel_host_resolv is called from 2 places - from remove_result and from
connection_destroy. remove_result is called from resolv_result
indirectly - through g_timeout_add_seconds(0,...). In connection_destroy
it is called directly as part of the cleanup routine.
I managed to trigger a situation where remove_result was called and the
resolv structure was cleaned and freed, and after that (due to me
killing connman-vpnd in an unfortunate moment), connection_destroy
kicked in and attempted to access data in resolv (NULL) pointer.
To fix the issue, I add a user_data structure element representing the
event ID of the scheduled resolv structure removal function. The
cancel_host_resolv function would then check if the resolv removal
function was scheduled, and would remove it from the loop, so it does
not get executed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change in stragety how ConnMan is driving the auto connect
strategy. Instead relying only on ConnMan doing the auto connect and
disabling all auto connects on the know networks object, we pass
through the autoconnect setting from ConnMan to iwd and rely on iwd to
initiate the initial connect. We have to do this because iwd will
disable scaning if auto connect is disabled.
Luckily ConnMan is able to synchronize itself on state changes from
the external daemons. No internal changes are necessary for ConnMan.
The only changes needed are inside the iwd plugin. We need to store
services' autoconnect status in the iwd_network and iwd_know_network
data structure. This is due the fact know networks are decoupled from
the network objects. So we can't do a reverse lookup. Thus we store
the autoconnect state in iwd_network object and update on any possible
chance the autoconnect variable. If the known_networks' auto_connect
and services' autoconnect do not match do a property change on the
iwd's known_network D-Bus object.
|
| |
|
|
|
|
|
|
|
|
| |
Cisco wireless controllers seem to send the disconnect code 1
sometimes. It could be a very dirty way to get the client moving to a
different AP.
Anyway, the '1' case was added as precaution and doesn't have any real
bug report behind it. So let's drop it as we had two independent
reports that ConnMan is not doing the right thing.
|
| |
|
|
|
|
|
| |
gcc complains with format-overflow for the DBG statement for the
bridge argument. Let's move the DBG after the initial checks to avoid
the complain and also make the output more helpful. If we see it in
the log, the bridge has been created.
|
| |
|
|
|
|
|
|
|
| |
wpa_supplicant is able to offload the 4-way handshake into the driver.
In this case the 4WAY_HANDSHAKE state is skipped and therefore the
current mechanism to detect a wrong password doesn't work any more. This
patch extends the detection mechanism to also work with the offloading
feature. The status code 16 is relatively generic, so this can lead to
false positives.
|
| |
|
|
|
|
|
|
| |
connman_device_set_scanning() marks all networks as unavailable during
the scan period. The iwd plugin needs mark the network available
again.
Fixes: 6b391cfd294d ("iwd: Synchronize station scanning property with scan state")
|
| |
|
|
|
|
|
|
| |
Release the scan_pending reply after scanning has stopped.
By synchronizing the scanning property of a iwd station with connman
device, it can call the __connman_technology_scan_stopped function so
that the scan_pending is removed from the list.
|
| |
|
|
|
|
|
|
| |
gcc reports with:
plugins/iwd.c: In function ‘tech_enable_tethering_cb’:
plugins/iwd.c:575:15: warning: ‘iwdap’ may be used uninitialized in this function [-Wmaybe-uninitialized]
575 | g_free(iwdap->bridge);
|
| |
|
|
|
|
|
| |
The connman_network_set_strength() setter is not propagating the new
value.
Reported-by: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently all connection attempts are reported as
CONNMAN_NETWORK_ERROR_CONNECT_FAIL. When the user enters an wrong
passphrase the upper layers wont reset the passphrase unless
CONNMAN_NETWORK_ERROR_INVALID_KEY is reported. This prevents the user
to enter a new passphrase.
Unfortunately, when the passphrase is correct but the connect attempt
fails with 'Failed', ConnMan will reset the passphrase. But this
behavoir is way better then not being able to provide the correct
passphrase.
Reported-by: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com>
|
