Age | Commit message (Collapse) | Author | Files | Lines |
|
The point here is to create a virtual configuration, which does not come
from a real file. This is a handy way for plugins to be able to provision
services without creating any file on the FS.
In case of a wifi configuration type and if connect is requested, it will
trigger a scan, thus leading to a possible service being provisioned by
such virtual configuration. If so and if connect was requested: the service
will be asked to connect.
|
|
|
|
It simplifies the code removing uselesse variable, moreover such variable
has the same name as an existing label in the same function.
|
|
We trigger autoconnect request in service after the wifi service
has been provisioned. This is useful in headless systems where
there is no user to trigger the connect to provisioned service,
and it might take some time before system autoconnect is run.
|
|
|
|
|
|
|
|
|
|
The inotify code will be used by the core (config.c) and the session
policy plugin. We introduce a new API for file modifcation
notifcation.
We move the factored out code part from the last patch into a new file
and also change the inotify code so that it allows to monitor not only
STORAGEDIR. When registering a new observer, the callee has to tell
which directory should be watched. inotify.c will group the observers
together.
|
|
The inotify code can be reused. So before we introduce a new generic
inotify API, let's factor out in order to simplify the review process.
|
|
|
|
Convert usage of g_slist_append() to g_slist_prepend() where
appropriate. gdbus, dnsproxy, resolver, rtnl, session and session
unit test have ordering requirements and thus not touched.
|
|
|
|
We need the list of provisioned services so that
all the hidden ones can be scanned.
|
|
|
|
|
|
We must not remove the services when connman is stopped.
|
|
Check if we need to remove a service if user removes
an entry from config file.
If user changes entry name in config file, then we
remove the service and then try to provision the service
again because the SSID might still be found.
|
|
We need to know the config file and entry name in next patch
in order to know if the service entry was removed from config
file.
|
|
|
|
|
|
Add a function that sets favorite flag but which does
not touch the ordering of service sequence. This is needed
when we check provisioned config file which traverses the
service sequence. If a proper provisioned service is found,
then it is marked as favorite but in this case we must not
do any ordering of service sequence because we are in the
middle of sequence traversal.
|
|
This is needed so that service can know if the
config file is removed when connmand is not running.
|
|
If the user removes the config file, we disconnect and then
try to remove the corresponding service directory and all
known files (settings and data).
|
|
|
|
Reject provisioning .config file SSID entries that are not in
hexadecimal.
|
|
|
|
This is useful so that user gets information that he needs to
fix the config file.
|
|
All the global settings would reside in /var/lib/connman/settings.
We also migrate global keys from /var/lib/connman/default.profile
to /var/lib/connman/settings for a smooth transition.
|
|
For now if new .config files are added connman will create
new config and but do not provision existing services. This
patch will provision existing service if any config file are
added or modified.
Fixes bug #4880.
|
|
|
|
Config file names are not exposed through D-Bus, so there is no need to
run connman_dbus_validate_ident() on them.
Checking for a readable string still makes sense though.
|
|
|
|
Configs will be protected, unless explicitely set otherwise.
|
|
D-Bus provisions will also be immutable, and will be allowed to overwrite
unprotected configs.
|
|
|
|
They will not be able to overwrite protected configs though.
|
|
|
|
|
|
|
|
|
|
|
|
__connman_config_load_service() function can be used by other parts of
ConnMan core to load service configurations, which can later be used
for service provisioning.
Within config.c, a special field (from_fs) will be used to mark which
configurations originate from the filesystem and which do not. This
information is needed to manage service immutability. Also a special
name "internal" will be used to label the "file" used for non-fs
configurations. A real file will not be created by ConnMan, and it will
be silently ignored if created by someone else. Filesystem storage can
be implemented later if necessary.
|
|
Service config should not be replaced after update (the existing struct
shall be reused).
|
|
|
|
Reflect new and modify *.config to connman config list. with
patch any modified or added .config file will be read by connman
and add these configuration for new provisioning.
|
|
Connman reads the *.config files in STORAGE_DIR during its boot but
it looks only for parameters it is interrested in.
The configuration parameters syntax is complex and it is very
simple to make a mistake without getting connman warnings. This
leads the user to think that connman understands the configuration
file although it doesn't.
This patch is the code that adds warnings to the logs if connman
reads unknown parameters from the *.config files.
|
|
|
|
|
|
|