Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. rtnl sockets breaks with ENOBUFS after endless
NEWROUTE/DELROUTE (Cunningham, Joel)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Jun 2018 15:48:31 +0000
From: "Cunningham, Joel" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: rtnl sockets breaks with ENOBUFS after endless
NEWROUTE/DELROUTE
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netlink-route-ENOBUFS.log
Type: application/octet-stream
Size: 119831 bytes
Desc: netlink-route-ENOBUFS.log
URL:
<http://lists.01.org/pipermail/connman/attachments/20180615/c8fcf8e8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-del-route-verbose.log
Type: application/octet-stream
Size: 142165 bytes
Desc: new-del-route-verbose.log
URL:
<http://lists.01.org/pipermail/connman/attachments/20180615/c8fcf8e8/attachment-0001.obj>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 32, Issue 7
**************************************
