Age | Commit message (Collapse) | Author | Files | Lines |
|
The socket was not closed when err < 0 is true.
|
|
Move the configuration part of __connman_session_create() into
session_create_cb(). With this change the policy plugin is able
to do async work to retrieve a configuration.
|
|
In order to be able to pass the user configuration provided through from
the D-Bus Manager.SessionCreate() call to the callback we need to store
the configuration into a local data data structure. This data structure
can then be passed into the callback introduced later on.
|
|
Instead start using enum connman_service_type directly.
|
|
|
|
|
|
This function name was a source of confusion because in a later patch
we introduce connman_session_parse_allowed_bearers() which will
call parse_bearers(). With this change it should be more readable.
|
|
The match_all will be expressed through CONNMAN_SESSION_TYPE_UNKNOWN.
The 'no match' case happens when allowed_bearers is NULL.
|
|
The string is only used when appending the bearer to the D-Bus
message in append_allowed_bearers(). Let's use
__connman_session_type2string() in append_allowed_bearers(). This
saves a bit of memory.
|
|
Instead returning directly a config when create() is called
in policy plugin, use a callback function for handing over a valid
configuration from the plugin to the session core. This prepares
support for asynchronous create call.
|
|
Let's ensure that the policy plugin has all necessary callbacks
installed when connman_session_policy_register() is called. The rest
of the code expects that the create() and destroy() callbacks exist
whenever a plugin is used.
|
|
There is no point in iterating over the list when we always
pick the first element in the list.
|
|
We want to reuse this code snippet for the error case in
__connman_session_create() too.
|
|
The CreateSession D-Bus call should be marked as async call in order
to allow the session core to defer the response.
|
|
|
|
This is needed if manually configured addresses were used and later
DHCP was taken into use. If the manually configured IP information
(address, netmask and gateway) and the information given by DHCP is the
same, DHCP will not set the IP address to the interface.
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
The nat struct was not freed when it is was removed from the hash.
|
|
We copied too much data into addrinfo struct which corrupted
the protocol and channel fields.
Fixes BMC#25726
|
|
If hard rfkilled, a technology will not be exposed through DBus via
GetTechnologies. If hard rfkill status changes, TechnologyAdded and
TechnologyRemoved signals will be sent accordingly.
|