[PATCH] fixed noisy error Cannot read /proc/net/pnp Failed to open file
by Vasyl Vavrychuk
This error happend on every boot.
---
src/inet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/inet.c b/src/inet.c
index dcd1ab24..80d96737 100644
--- a/src/inet.c
+++ b/src/inet.c
@@ -3233,6 +3233,9 @@ char **__connman_inet_get_pnp_nameservers(const char *pnp_file)
if (!pnp_file)
pnp_file = "/proc/net/pnp";
+ if (!g_file_test(pnp_file, G_FILE_TEST_EXISTS))
+ goto out;
+
if (!g_file_get_contents(pnp_file, &pnp, NULL, &error)) {
connman_error("%s: Cannot read %s %s\n", __func__,
pnp_file, error->message);
--
2.11.0
1 year, 11 months
rtnl sockets breaks with ENOBUFS after endless NEWROUTE/DELROUTE
by Cunningham, Joel
I'm working with an embedded system and using yocto 2.2, Connman 1.33, and Linux Kernel 4.9.27 from ASOP. I've found an issue where when connecting to a Wi-Fi AP, Connman adds the default route after DHCP and then receives NEWROUTE via the NETLINK_ROUTE socket, this triggers an endless loop of deleting and adding the default route until the socket eventually errors with ENOBUFS and then never receives any more NETLINK_ROUTE messages
I've been going through the changes since 1.33 and can't seem to find anything that would address this loop. It appears possible in git head, but I haven't been able to test it for sure.
Here's the execution flow:
1. netlink_event
2. rtnl_message -> RTM_NEWROUTE (0.0.0.0)
3. rtnl_newroute
4. process_newroute
5. __connman_ipconfig_newroute
6. ipconfig->ops->route_set
7. service.c: service_route_changed
8. service.c: settings_changed
9. __connman_notifier_ipconfig_changed
10. notifier->ipconfig_changed
11. session.c: ipconfig_changed
12. update_routing_table
13. del_default_route
14. __connman_inet_del_default_from_table -> RTM_DELROUTE
15. Return to update_routing_table , add_default_route
16. __connman_inet_add_default_to_table -> RTM_NEWROUTE
For RTM_DELROUTE, it also calls route_unset which is the same service.c: service_route_changed, so both messages cause the same cycle
It's not clear to me why we are deleting the default route and adding it back again when receiveing either NEWROUTE or DELROUTE. Seems like Connman should just update its local state rather than issue RTM_DELROUTE then RTM_NEWROUTE.
I have a couple of logs capturing this. I've added a couple extra debug statements to rtnl.c so I can prove out the ENOBUFS case and this can be seen in netlink-route-ENOBUFS.log at the end. The second log file new-del-route-verbose.log is the output with debug for rtnl.c, inet.c, session.c, connection.c, and service.c. Towards the end of the log, I think journald gets overloaded and drops DBG statements as only connman_info/connman_error are logged
Any insight is appreciated!
Thanks,
Joel
________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
2 years, 1 month
NETLINK_ROUTE policy routing questions
by Cunningham, Joel
Hi,
I've been working through an issue with Connman and NETLINK_ROUTE messages as it relates to policy routing. Background can be seen here: https://lists.01.org/pipermail/connman/2018-June/022846.html
I'm using kernel 4.9.27 from ASOP releases and had a couple of questions of how NETLINK_ROUTE is intended to work and whether or not we are seeing a kernel bug.
Connman has long-running NETLINK_ROUTE socket which binds with:
memset(&addr, 0, sizeof(addr));
addr.nl_family = AF_NETLINK;
addr.nl_groups = RTMGRP_LINK | RTMGRP_IPV4_IFADDR | RTMGRP_IPV4_ROUTE |
RTMGRP_IPV6_IFADDR | RTMGRP_IPV6_ROUTE |
(1<<(RTNLGRP_ND_USEROPT-1));
Connman also creates other short-lived NETLINK_ROUTE sockets to perform setters, in particular, we have RTM_NEWROUTE and RTM_DELROUTE with a custom routing table. Connman uses policy routing to create a session based routing table. When a new interface comes online and has a gateway, Connman adds a default route to a new custom routing table. When this happens, we get a RTM_NEWROUTE message for the main table (254), but we never receive any RTM_NEWROUTE/RTM_DELROUTE messages for our custom table. Should NETLINK_ROUTE sockets bound to RTMGRP_IPV4_ROUTE be receiving updates for custom tables or only table ID < 256?
The other behavior which I ran into was originally my kernel didn't have CONFIG_IP_MULTIPLE_TABLES enabled and when Connman sent RTM_NEWROUTE/DELROUTE with the custom table, we got NETLINK_ROUTE messages for these actions being applied to the main table (254). This was corrected by enabling CONFIG_IP_MULTIPLE_TABLES in the kernel, but I was still just curious if using table 254 was a fallback mechanism rather than the setter returning an error.
Thanks,
Joel
2 years, 1 month
[PATCH 1/4] nat: Fix handle leak
by Peter Meerwald-Stadler
Need to close file handle on error
CID 1393448
---
src/nat.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/nat.c b/src/nat.c
index fb557101..2aac60df 100644
--- a/src/nat.c
+++ b/src/nat.c
@@ -55,8 +55,10 @@ static int enable_ip_forward(bool enable)
if (read(f, &value, sizeof(value)) < 0)
value = 0;
- if (lseek(f, 0, SEEK_SET) < 0)
+ if (lseek(f, 0, SEEK_SET) < 0) {
+ close(f);
return -errno;
+ }
}
if (enable) {
--
2.17.1
2 years, 1 month
[PATCH] ntp: add detailed error msg on adjtimex failure
by Eliott Dumeix
---
src/ntp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ntp.c b/src/ntp.c
index 51ba9aac..44320fcc 100644
--- a/src/ntp.c
+++ b/src/ntp.c
@@ -392,7 +392,7 @@ static void decode_msg(struct ntp_data *nd, void *base, size_t len,
tmx.status |= STA_DEL;
if (adjtimex(&tmx) < 0) {
- connman_error("Failed to adjust time");
+ connman_error("Failed to adjust time: %s (%d)", strerror(errno), errno);
nd->cb(false, nd->user_data);
return;
}
--
2.13.6
2 years, 1 month
Re: How to use OpenConnect and Cisco Secure Desktop with ConnMan (instead of NetworkManager)?
by David Woodhouse
On Tue, 2018-06-12 at 18:07 +0200, scrap(a)mailbox.org wrote:
> Hello together,
>
> in the past I was using NetworkManager and got OpenConnect including
> Cisco's Secure Desktop (CSD) working easily.
>
> Now I switched to the more lightweight ConnMan and have some trouble to
> set up OpenConnect correctly.
>
> --------------------------------------------------------------------------
>
> The first question is: ConnMan's CMST-GUI provides several options for
> possible OpenConnect-VPN types to build the necessary config file. In
> detail these are:
>
> - Provider OpenConnect
> - OpenConnect.ServerCert
> - OpenConnect.CACert
> - OpenConnect.ClientCert
> - OpenConnect.MTU
> - OpenConnect.Cookie
> - OpenConnect.VPNHost
>
> Which type do I have to choose to get OpenConnect working together with CSD?
It's been a while since I paid much attention to ConnMan so I'm not
entirely sure of the current state of the authentication agents.
The way the VPN works is that you *first* authenticate (using the CSD
trojan and your cert and password and anything else), and you are
rewarded with a cookie — literally, an HTTP cookie called "webvpn".
You then take that cookie, along with the IP address of the VPN server
you were talking to (after any load balancing and other redirects), and
its certificate fingerprint (because it might not have been trusted;
you might have accepted it manually).
So there are three pieces of information which are needed to actually
make the connection:
• VPN server address
• Certificate fingerprint
• Cookie
When you compare with your NetworkManager configuration, you are
comparing apples and oranges. That contains the information that you
*start* with — the first server you start authenticating to, things
like usernames and passwords. ConnMan doesn't care about any of that,
or didn't when I last looked. It just needs those three fields listed
above (which are precisely what the NM auth-dialog actually hands off
to NetworkManager itself, behind the scenes).
Somewhere there was a script which runs 'openconnect --authenticate' to
obtain the three relevant fields, and then poke ConnMan to connect
using them. Isn't that still in the ConnMan repo somewhere?
2 years, 1 month
[PATCH 1/1] doc: Update errors returned in Connect and Disconnect methods in Service API.
by Vlad Jahundovics
From: Vlad Jahundovics <vlad.jahundovics(a)actia.se<mailto:vlad.jahundovics@actia.se>>
---
doc/service-api.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/doc/service-api.txt b/doc/service-api.txt index c0d5adbb..1295a9e8 100644
--- a/doc/service-api.txt
+++ b/doc/service-api.txt
@@ -57,8 +57,12 @@ Methods dict GetProperties() [deprecated]
query the missing SSID via the Agent API causing a
WiFi service with the given SSID to be scanned,
created and connected.
+
+ An error message will be generated if no agent is
+ registered before connecting.
Possible Errors: [service].Error.InvalidArguments
+ [service].Error.NotRegistered
void Disconnect()
@@ -77,6 +81,7 @@ Methods dict GetProperties() [deprecated]
as they always stay in idle state.
Possible Errors: [service].Error.InvalidArguments
+ [service].Error.NotConnected
void Remove()
--
2.13.2.windows.1
2 years, 1 month
[PATCH 0/1] Update errors returned in Connect and Disconnect methods in Service API
by Vlad Jahundovics
From: Vlad Jahundovics <vlad.jahundovics(a)actia.se<mailto:vlad.jahundovics@actia.se>>
The patch updates the description of Connect and Disconnect methods in Service API. In particular, it adds more errors which can be returned by those methods.
Vlad Jahundovics (1):
doc: Update errors returned in Connect and Disconnect methods in
Service API.
doc/service-api.txt | 5 +++++
1 file changed, 5 insertions(+)
--
2.13.2.windows.1
2 years, 1 month
Submitting bug to connman
by nick83ola
Hi all,
there's a bug tracker somewhere for connman?
I've found that the current bug tracker is open only to intel employee...
This render submitting bug and patches very difficult.
Regards
Nicola Lunghi
2 years, 1 month
[PATCH v2] rtnl: Bail out if interface name is blacklisted
by Peter Meerwald-Stadler
read_uevent() checks if the interface name is blacklisted, but then
continues to open the corresponding uevent file, and happily sets SERIVCE_TYPE
and DEVICE_TYPE (nullifying the blacklisting)
this leads to the following logging when starting connmand -I wlan0
Ignoring interface wlan0 (filtered)
Adding interface wlan0 [ wifi ]
fix this by bailing out from read_uevent() as soon as we find the device
is blacklisted
---
src/rtnl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/rtnl.c b/src/rtnl.c
index 8080ff01..cba5ef7a 100644
--- a/src/rtnl.c
+++ b/src/rtnl.c
@@ -127,6 +127,7 @@ static void read_uevent(struct interface_data *interface)
if (ether_blacklisted(name)) {
interface->service_type = CONNMAN_SERVICE_TYPE_UNKNOWN;
interface->device_type = CONNMAN_DEVICE_TYPE_UNKNOWN;
+ goto out;
} else {
interface->service_type = CONNMAN_SERVICE_TYPE_ETHERNET;
interface->device_type = CONNMAN_DEVICE_TYPE_ETHERNET;
--
2.17.1
2 years, 1 month
