I am using connman v1.33 along with systemd v230 for yocto based project.
Experiencing delay in IP assignment ranging from 20 sec. to 1.5 min.
While used earlier versions previously didn't faced such delays. So by the
time I am finding the exact change in version causing this delay issue.
Just want to check anyone experiencing such delays in IP assignments.
Any suggestions or pointers will be a great help.
Currently, ConnMan uses an http get operation to transition a service from Ready to Online state.
This is implemented in the wispr module, where a hard-coded http url is used:
#define STATUS_URL_IPV4 "http://ipv4.connman.net/online/status.html"
#define STATUS_URL_IPV6 "http://ipv6.connman.net/online/status.html"
Additionally, the http server must return a custom header in the reply: "X-ConnMan-Status"
This is a problem for us, as we are planning to release a product, which must not depend on the ConnMan's http server.
I think we need to make a change to add a config field, which allows the user to:
- provide a custom http URL
- disable http get - automatically transition from Ready to Online state - let the application detect the end-to-end connectivity
I am not sure what to do with the "X-ConnMan-Status" http reply header. Should checking of it be disabled in case the config provides a URL from the user?
I realise that this functionality is also used to detect proxies, so I would keep the current code as default, and provide an optional config field to change wispr URL or disable it.
Does this make sense?
It is an issue we definitely have to address to use ConnMan. I would like to make changes, which would be usable by others too.
After establishing a cellular data via particular apn, does user need to
explicitly update routing tables to make data traffic flow in the MNO
provided ip address route ? or will connman automatically updates once
ofono informs that cellular data connection is established ?
Really appreciate if some one can share the interactions/call flows between
connman/ofono for cellular connectivity.
We would like to propose two extensions to the session API interface of ConnMan. The first extension enables a service differentiation for processes run by the same user. It allows ConnMan to differentiate between bearer usage permissions and the respective priorities based on the requested service type. The second extension enables session-based routing based on source IPs. This mechanism is meant as an alternative means for differentiating between traffic of session API users. Source IP based routing may be used to route traffic from non-local sources, e.g. remote hosts or virtual machines/containers.
1 User service differentiating session API
1.1 State of art
A minimal policy configuration in the session API takes the form
uid=<system user ID>
where a calling process that implements the session API is identified by the user ID it is run as. All processes of the same user share the same list of allowed bearers, and the same priority for choosing between available bearers is applied.
1.2 Advantages of proposed extension
Our extension allows processes to select a service context for which the routing decision is made. Several use cases are enabled through the extension:
(1) An application that implements an interactive webservice, e.g. a Facebook agent, can be configured to use different bearers than a background process running a regular system update mechanism as the same user.
(2) An application that runs different encapsulated services, e.g. a webbrowser executing a Facebook webservice, a device manufacturer's portal site, and an automatic update mechanism, may be configured to use different bearers based on the currently active service.
1.3 Implementation details
The configuration for the extension is lightweight
uid=<system user ID>
where the new parameter service defaults to * (any) if unset. If no default rule exists and the intended service is unknown or not set by the calling process, the session API denies routing.
In order to indicate the intended service, the calling process leverages the option to set parameters during the CreateSession(dict settings, object notifier) method call in the ConnMan Manager API on session establishment, see Figure 1. We propose to introduce a new parameter service for this purpose.
Optionally, this parameter may be changed by a Update(dict settings) request during the session lifetime.
2 Source IP based routing
2.1 State of art
The session API makes the decision which bearer shall be used by a requesting user. It then initiates the following steps
1. It generates a rule that unambiguously attaches a mark <MARK> to every packet originating from the user <UID> (resp. a GID) that passes through the kernel.
iptables -t mangle -A OUTPUT -m owner --uid-owner <UID> -j MARK --set-mark <MARK>
2. It generates a new routing table by the name of <MARK> which is applied for all packets matching the mark value <MARK>
ip rule add fwmark <MARK> table <MARK>
3. It adds a default route to the newly created routing table matching the intended bearer <BEARER>.
ip route add default via XXX dev <BEARER> table <MARK>
UID/GID based differentiation is only applicable for traffic generated at the local system.
2.2 Advantages of proposed extension
Our extension allows the session API based to route alternatively based on the source IP of a packet. Several use cases are enabled through the extension:
(1) The host implementing the ConnMan session API may act as a service aware router to an entire network. For example, different hosts in the network may use different outgoing network connections.
(2) If the host implements virtual machines/containers that are connected through a Linux bridge, the session API can route their traffic according to the intended policies.
In order to enable these scenarios, hosts/virtual machines/containers require authenticated access to the system DBus. Alternatively, using the user service differentiation proposed above, an application running on the host (e.g. a webportal), may enable routing on behalf of the remote machine.
2.3 Implementation details
The configuration for the extension is lightweight
uid=<system user ID>
where the new parameter SourceIP carries one or more IP addresses. If the parameter is omitted, UID/GID-based routing is applied (backward compatible). If a single IP is given, routing for all bearers uses this IP address for differentiation, otherwise the number of IPs must match the number of bearers. If the nth bearer from the list of allowed bearers is selected, the nth IP is used.
In the first step of the route establishment, the iptables rule is changed to
iptables -A PREROUTING -t mangle -j MARK --set-mark <MARK>
if source IP based routing is to be used. Note that the rule is added to a different chain than the original user-based routing.
What do you think about our proposal?
From: Lukasz Nowak <lnowak(a)tycoint.com>
changes from v1:
- added documentation
- split firewall and session changes into separate commits
- cosmetic updates after v1 review
Adding a new feature to the sessions, which allows applications to direct
routed traffic to a specific network interface.
This requires that multiple default routes with gateways are set up, one
for each interface. And then iproute and iptables rules need to be added
to direct traffic based on source ip address, to the correct routing table.
Applications can use bind before connect mechanism, to bind sockets to
The application side can be tested with:
ping -I <interface_ip> <target_ip>
Use case for this is to have multiple network interfaces available for
external traffic at the same time. It can be used to validate that a full
path to an external server is working properly, by maintaining multiple
tcp connections, one for each interface.
Lukasz Nowak (7):
session: fix default route for ppp services
session: add allowed interface config parameter
client: add session allowed interface config
firewall: add fwmark based on source ip address
session: add source ip rule
client: add session source ip rule
doc: session multi-interface routing
client/commands.c | 39 ++++++++++++
doc/session-api.txt | 22 +++++++
doc/session-overview.txt | 31 +++++++++
include/session.h | 2 +
src/connman.h | 3 +-
src/firewall-iptables.c | 11 +++-
src/firewall-nftables.c | 5 +-
src/session.c | 161 +++++++++++++++++++++++++++++++++++++++++++++--
8 files changed, 264 insertions(+), 10 deletions(-)
I looked at connman source code. The "dhcp-failed" service error property
is defined, but is NOT actually plugged. Should this be a bug? or this
property need to be removed? I am looking for this service dhcp-failed
property as part of collecting network telemetry data. I hope this is a bug
so that I can change the code to make it plugged. Thanks!
Passing 0 as timeout to g_timeout_add_seconds() is equivalent to g_idle_add()
According to glib documentation "the first call of the timer may
not be precise for timeouts of one second."
src/service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/service.c b/src/service.c
index 8480350..043a7a0 100644
@@ -4001,7 +4001,7 @@ void __connman_service_auto_connect(enum connman_service_connect_reason reason)
- autoconnect_timeout = g_timeout_add_seconds(0, run_auto_connect,
+ autoconnect_timeout = g_idle_add(run_auto_connect,
Dear Connman Experts,
Can you please answer these questions ?
a) Does connman support per application level DNS ? If so, can someone
point to respective connman interfaces/API's ?
For Ex:- If i have 2 Cellular data sessions (for different APN's) can i
tell my APP1 to use DNS2 for data connection over APN1 , and APP2 do use
DNS1 for Data connection over APN2 ?
b) Does connman support VLAN interface? If so, can someone point to
respective connman interfaces/API's ?
I am pretty new to connman/ofono, does Connman support Multiple APN data
connections with ofono plug in ? If so, How the routing works , what
API/interfaces we can use to switch between different connections?
For Ex: If i have a USB0 dev interface which listens to APN0 , what API i
can use to switch USB0 to APN1 ?