September 2019 - connman

Connman and IWD - Scanning Network - Update?

by stef204

Hi, With reference to this <https://lists.01.org/pipermail/connman/2018-August/022915.html> and this <https://lists.01.org/pipermail/iwd/2018-August/004751.html> are there any updates or further progress to achieve scanning networks with ConnMan + IWD? Thanks.

3 weeks, 6 days

2
4
0 / 0

Insights on connmand -d

by JH

Could anyone give some insights on what connmand -d differs to connmand -n running by systemctl? From reading the documentation, my understanding is it should be identical except increasing debug level to printing out more debug messages, but the systemd service connmand -n incapable of bringing my LTE modem up makes my wandering what I could get wrong here, could the connman -n service messages be blocked by journal logs? Appreciate anyone helps to fix it, Thank you. Kind regards. On 9/28/19, JH <jupiter.hce(a)gmail.com> wrote: > Hi, > > I thought connmand -d just for running debug mode, then I was puzzled, > if I run systemctl start connman, the LTE cannot be connected, if I > run connmand -d, the LTE modem can be connected on, is it LTE modem > problem or connman problem? > > Thank you. > > Kind regards, > > - jh >

1 month, 2 weeks

2
2
0 / 0

magic connmand -d

by JH

Hi, I thought connmand -d just for running debug mode, then I was puzzled, if I run systemctl start connman, the LTE cannot be connected, if I run connmand -d, the LTE modem can be connected on, is it LTE modem problem or connman problem? Thank you. Kind regards, - jh

1 month, 2 weeks

1
0
0 / 0

[PATCH 0/4] RE: Propose patch for continuous online check for connected services

by aleksandar＠analyticsfire.com

From: Aleksandar Mitev <shondll(a)yahoo.com> Hi Daniel, Following your advice on every commit, I resubmit the patches again. I hope I've got everything sorted out. I agree with the name change, indeed "perpetual" sounds more epic but does not have the necessary semantics. The state diagram in the doc section is updated as well. Best, Aleksandar Aleksandar Mitev (4): gweb: added timeout to socket connections service: perform continuous online checks service: Added a compile config for online check doc: updated state diagram for services README | 10 ++++++ configure.ac | 6 ++++ doc/overview-api.txt | 25 +++++++++----- gweb/gweb.c | 27 +++++++++++++++ src/service.c | 78 +++++++++++++++++++++++++++++++++++++++++--- 5 files changed, 133 insertions(+), 13 deletions(-) -- 2.17.1

1 month, 2 weeks

1
4
0 / 0

[PATCH v2 0/2] Fix connections to VPN servers on local network

by Santtu Lakkala

When VPN server resides on local network, a route via default gateway must not be added for it to remain reachale. Add a check using existing IPv4 helper, and introduce a new helper for IPv6. Santtu Lakkala (2): inet: Add connman_inet_compare_ipv6_subnet() connection: Fix connections to local VPN servers include/inet.h | 1 + src/connection.c | 13 +++++++++++ src/inet.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 75 insertions(+) -- 2.20.1

1 month, 3 weeks

2
3
0 / 0

[PATCH] PrefixLength handling for IPv4 and better error reporting

by Benjamin Cama

Hi, Here are two patches I am using for some time which allow specifying a prefixlen for IPv4 by D-Bus, which I find very handy. The second one also help catching errors. They are a bit old so I do not remember the details, but I hope they help. Regards, Benjamin

1 month, 3 weeks

2
4
0 / 0

[PATCH 0/3] Re: Propose patch for perpetual online check for connected services

by aleksandar＠analyticsfire.com

From: Aleksandar Mitev <shondll(a)yahoo.com> Hi, Thanks for the lively discussion on this proposed change. Taking into account all the notes and concerns I think I came up with a balanced solution: - regular online check is now governed by a compile time optio rather than a runtime one in the configration file - the proposed update to the state machine is disabled by default leaving the current behaviour in place. Btw, please advise on a better use of compile time defines (if you happen to find the current implementation not suiatable) as there are no usual #ifdef..#endif blocks in the project. >On 9/4/19 5:22 PM, Slava Monich wrote: >>> As of v1.37, when a service reaches the READY state, then the online >>> check is started. If it succeeds, the a transition to ONLINE state >>> happens. You are right in thinking that my proposed change will cause >>> a downgrading to READY again, but you see, according to the state >>> machine, another round of online checking will begin, possibly >>> promoting the service back to ONLINE it it ever succeeds (ex. the >>> Internet disruption was temporary). In general, this is a chance for >>> any of the other services in READY state to take over. >> >> Are you sure that another service WILL actually take over when some >> other service is stuck in the READY state? That's the key point. > >I agree. There are many small problems along the road. > Yes, it does happen in our use case (provided the number of failed online checks is reached). >> If such a handover doesn't happen then this transition back to READY is >> useless. It will be just generating additional network traffic and >> that's it. >> >> If handover does indeed happen then it's a major change of behavior and >> must be configurable. We (Sailfish OS) consider READY as of the >> "connected" states. We don't need and don't want to automatically switch >> from WiFi to mobile data if WiFi gets stuck in the READY state. We still >> consider it connected and let the user to turn it off and switch to >> mobile data, if the user notices that it's not actually working. > >Okay, understood. If we going to mess with the current state machine we >need to keep a compact mode. I suppose compile time would be good enough? > >>> Finally, if a failed online check is not reliable enough to determine >>> Internet reachability, then it can be disabled altogether and replaced >>> with a simple ping check (from a separate service) as in the case of >>> mwan3 tool for Openwrt. However, in that case one will miss the >>> checking of DNS working. >>> >>> Please share more details if you think I am missing smth here. >>> >> >> Have you considered the VPN scenario? When VPN is connected, you may not >> be able to run online check for the transport interface - it won't have >> any routes to anything other than local subnet and the VPN server. > >Indeed, VPN can be pretty tricky. This needs a lot of testing. > >@Slava: I highly appreciate your feedback! I haven't used connman with VPN, unfortunately for this is not a use case in our application. So I believe there are a lot of other projects out there that have similar setups to ours - simple in nework topology, but needing a network manager trying its best to keep you connected. Those would really only benefit from the proposed change. Best, Aleksandar Aleksandar Mitev (3): Added timeout to socket connections Added logic to perform perpetual online checks Defined a compile time config of perpetual online check README | 10 ++++++ configure.ac | 6 ++++ gweb/gweb.c | 32 +++++++++++++++++++ src/service.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++--- 4 files changed, 131 insertions(+), 4 deletions(-) -- 2.17.1

1 month, 3 weeks

2
6
0 / 0

[PATCH] agent: Always set driver for queued message.

by Jussi Laakkonen

This addresses the issue of not being able to cancel agent queries in case the query timeouts or when component (e.g., a VPN plugin) has requested something via agent and the component dies when the query is still active. As a result the queries are stacked on top of another if the agent creates new one for every query. It is imperative to always set the driver for the message to be queued via agent.c because otherwise sending cancel request will fail. This is because the cancel request would be sent to a NULL interface as driver is omitted. In this case, following is logged: connman-vpnd[4835]: src/agent.c:send_cancel_request() send cancel req to :1.2951 /org/agent/path/vpnagent iface (null) dbus-daemon[1553]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.3387" (uid=0 pid=4835 comm="/usr/sbin/connman-vpnd -d -n") interface="(unset)" member="Cancel" error name="(unset)" requested_reply="0" destination=":1.2951" (uid=100000 pid=27084 comm="/usr/bin/agent") --- src/agent.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/agent.c b/src/agent.c index 8f7b19ba..d6113af7 100644 --- a/src/agent.c +++ b/src/agent.c @@ -238,12 +238,12 @@ int connman_agent_queue_message(void *user_context, driver = get_driver(); DBG("driver %p", driver); - if (driver && driver->context_ref) { + if (driver && driver->context_ref) queue_data->user_context = driver->context_ref(user_context); - queue_data->driver = driver; - } else + else queue_data->user_context = user_context; + queue_data->driver = driver; queue_data->msg = dbus_message_ref(msg); queue_data->timeout = timeout; queue_data->callback = callback; -- 2.20.1

1 month, 3 weeks

2
1
0 / 0

Is independent control of rfkill possible?

by Messer, David

Hi, I have a device with two wi-fi interfaces, one for AP mode and the other for STA mode. I would like to control the device so one could operate AP or STA individually. The first interface is running hostapd. On the second interface, I would like to run connman. The problem I'm running into has to do with rfkill. If I unblock the wi-fi radio for AP mode, connman sees this event and powers up the wi-fi (STA) technology. Likewise, if I turn off STA mode, connman powers down wi-fi technology which then blocks the radio for AP mode. Is there any way to get around this? Thank you, David

1 month, 3 weeks

2
1
0 / 0

[PATCH 0/2] Fix connections to VPN servers on local network

by Santtu Lakkala

When VPN server resides on local network, a route via default gateway must not be added for it to remain reachale. Add a check using existing IPv4 helper, and introduce a new helper for IPv6. Santtu Lakkala (2): inet: Add connman_inet_compare_ipv6_subnet() connection: Fix connections to local VPN servers include/inet.h | 1 + src/connection.c | 13 +++++++++++ src/inet.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 73 insertions(+) -- 2.20.1

1 month, 3 weeks

2
3
0 / 0

2019

2018

2017

2016

2015

connman September 2019