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. Re: rtnl sockets breaks with ENOBUFS after endless
NEWROUTE/DELROUTE (Daniel Wagner)
2. NETLINK_ROUTE policy routing questions (Cunningham, Joel)
3. RE: rtnl sockets breaks with ENOBUFS after endless
NEWROUTE/DELROUTE (Cunningham, Joel)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Jun 2018 07:44:09 +0200
From: Daniel Wagner <[email protected]>
To: "Cunningham, Joel" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: rtnl sockets breaks with ENOBUFS after endless
NEWROUTE/DELROUTE
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 06/18/2018 09:03 PM, Cunningham, Joel wrote:
>> $ ip route add ...
>
> In attempting to reproduce this with 'ip route', I discovered that
> Connman's custom IP policy table was empty (ip route list table 256)
> and further that in my embedded system's kernel,
> CONFIG_IP_MULTIPLE_TABLES (IP policy routing) was set to 'n'. I'm
> guessing the kernel in this mode, applied the routes to the default
> table rather than a custom one.
Don't know this either, but from your report it sounds like this is the
case.
> With CONFIG_IP_MULTIPLE_TABLES, we do still get a RTM_NEWROUTE (for
> the default table) when adding the default gateway to our custom table,
> which causes an del/add cycle, but no RTM_DELROUTE is reported for the
> default table when we remove the default route from our custom table and
> no additional RTM_NEWROUTE when adding back to our custom table, thus
> preventing a loop.
>> One additional thing that is not clear to me is why our
> NETLINK_ROUTE socket isn't receiving RTM_NEWROUTE/RTM_DELROUTE messages for
> the custom
> table. Maybe custom tables aren't reported to RTMGRP_IPV4_ROUTE?
Hmm, this inconsistency is strange. Maybe this is a bug in the kernel?
>> Hmm, withouth looking at the code, I would probably do the table id
>> matching only for the policy tables in the session code. But if you think it
>> simpler to add it ipconfig.c just send a patch. It's hard to tell without
>> seeing
>> the patch :)
>
> Even though my occurrence of this was resolved by enabling IP policy
> routing, to me it seems that Connman should be ignoring route changes
> for tables it's not using, so there's still a bug.
Agreed, so far it didn't pop up because we never saw this oscillating
behavior. If the kernel starts to send also the missing RTM message we
need to fix this.
At this stage we should ask the netdev mailing list about what you
observed. If this is the desired behavior or not.
Thanks,
Daniel
------------------------------
Message: 2
Date: Tue, 19 Jun 2018 14:17:19 +0000
From: "Cunningham, Joel" <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Daniel Wagner <[email protected]>, "[email protected]"
<[email protected]>
Subject: NETLINK_ROUTE policy routing questions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 3
Date: Tue, 19 Jun 2018 14:19:40 +0000
From: "Cunningham, Joel" <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: rtnl sockets breaks with ENOBUFS after endless
NEWROUTE/DELROUTE
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> -----Original Message-----
> From: Daniel Wagner [mailto:[email protected]]
>
> At this stage we should ask the netdev mailing list about what you observed.
> If this is the desired behavior or not.
I have posted to netdev and CC'd connman list. Following along here:
https://marc.info/?l=linux-netdev&m=152941785126244&w=2
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.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 32, Issue 10
***************************************
