Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
Fixes BMC#25846
|
|
By default, both stdout and syslog messages go to the systemd journal,
which results in duplicate messages being logged.
Thanks to Vinicius Costa Gomes for pointing out this problem.
|
|
This fixes an issue with the TechnologyAdded signal when the first
un-hardblock event occurs:
- when a technology was created, D-Bus registration was done and hardblock
was set to TRUE even if there was no evidence that the technology was
rfkill driven
- when the technology was updated to be rfkill driven, hardblock was already
set to TRUE and thus the technology was not unregistered
- when an rfkill event un-hardblocks the technology, the TechnologyAdded
signal was not sent since the technology was already registered to D-Bus
|
|
Check that the first part of the name is not of zero length before
attempting to calculate the length of the domain part. Also ensure
the domain lenght checking does not run outside of the receive
buffer.
Also add debug messages for ids and lengths in order to pinpoint
any possible problems.
|
|
This fixes 2 issues:
- calling __connman_service_ipconfig_indicate_state() might lead to
restart wispr_portal check, so context should not be freed afterward
but beforehand.
- freeing the context in wispr_manage_message() should not happen since
wispr_manage_message() will return back to wispr_portal_web_result()
where we can still use the context.
Thanks to Julien Massot <jmassot@aldebaran-robotics.com> who reported
the issue and provided logs.
|
|
When autoscan fallback code is started, it sets scanning to true which
in turn marks all networks unavailable except for the ones that are
already connected. When connecting during an ongoing autoscan, the
connection attempt stops autoscan and all unavailable networks are
removed, also the one to be connected.
The fix is to ignore both connected and connecting networks when
marking networks unavailable.
|
|
|
|
The file and function name are printed in debug prints.
|
|
The order of actions is important here.
|
|
We must close the channel when freeing the resolver object,
otherwise we might still receive data when the resolver has been
freed already.
Fixes BMC#25757
|
|
|
|
The file and function names are printed in debug prints.
|
|
Don't override user connected services with the ones selected by the
preferred technology list when SingleConnectedTechnology is enabled.
Do this by checking each connected service sorted in the beginning of
the service list for the userconnect flag.
|
|
Remember whether the service was connected by the user via D-Bus
until the service gets disconnected.
|
|
If SingleConnectedTechnology is enabled in main.conf, disconnect any
previously connected services when the new service enters ready state.
|
|
|
|
|
|
Calling switch_default_service() didn't change the service order since
the services were already sorted that way. Also update the gateway
immediately.
|
|
|
|
Simplify the preferred service selection such that a connected
service is good enough, especially since a connecting service
will also terminate the search for the current preferred one.
|
|
Don't trigger a new autoconnect when neither the default nor the new
service is preferred. Rely on the fact that normal autoconnect selection
mechanism has done the work for us already.
|
|
|
|
|
|
|
|
|
|
The call to g_resolv_cancel_lookup() will do nothing
because we just removed the lookup from the queue.
The fix is to remove the lookup directly and not call
the cancel function.
|
|
If hardblock is on and a new device is inserted and detected as not
hardblocked, then it will be possible to enable/disable it (soft rfkill)
independently to the main hw rfkill switch.
|
|
This fixes the case of cascading rfkill switches: if enabled, hard rfkilling
such technology might generate contradictory events.
1 - first all switches are hardblocked
2 - then one of these switch (usually: device's switch) gets fully unblocked
3 - then this same switch gets removed
Step 2 is in contradiction with step 1, so we need to care about such switch
getting removed by recomputing the hardblocked state.
|
|
|
|
|
|
If rfkill driven, use rfkill soft block/unblock. If not, request the
device to be enabled or disabled.
|
|
|
|
|
|
No need to proceed with softblocked if technology is already hardblocked.
Apply offlinemode and persistant state according to softblocked state.
(saner logic and helped to cleanup code from style point of view too)
|
|
|
|
Useful for coming patches: enabling/disabling technologies will be done
differently whether technology is rfkill driven or not:
- if rfkill driven -> enabled will rely on rfkill states
- if not -> enabled will rely on driver/devices states
|
|
Refactor how a device list is enabled/disabled: this will be useful
for coming patches. Simplify also the code, and remove useless gotos.
|
|
Keep track of the zero-second no proxy callback timeout and remove
it when freeing up the WISPr context.
|
|
|
|
|
|
When soft rfkill is on, wpa_supplicant sets the interface disabled and
sends a state named 'interface_disabled'. Taking this information into
account fixes the following issue:
- disable wifi (user setting) and hard rfkill it
- then un-hard rfkill it, whereafter rfkill states (soft/hard) will go
like this:
* from 1/1 to 0/0
* from 0/0 to 1/0
when 0/0 occurs, connman will request to enable wifi
The problem with this is that enabling wifi takes quite some time and
in between ConnMan will soft block wifi to disable it (according to
previous user setting). Thus it will request to disable wifi but since
enabling is still going on, this request won't do anything. Meanwhile
wpa_supplicant will also catch the soft rfkill event and wpa_supplicant
will set the state to 'interface_disabled', but since it's not handled
properly by ConnMan, the wifi_enable() callback will be called and the
function will assume wifi got enabled.
|
|
|
|
Remove all lookups found in queue when GResolv object is removed.
|
|
We must remove the lookup from lookup queue and query from query queue
before calling user callback. The callback might unref the GResolv which in
turn would remove the lookup/query what we are trying to access after
the callback is returned.
So it is enough to remove the lookup or query entry from queue before
cb is called and then manually remove it after the callback has returned.
|
|
In iptables 1.4.9 module loading gives an error even if the module
is built in. Ignore the loading errors because the missing iptables
support is noticed when trying to get the iptables socket options.
|