From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cunningham, Joel" Subject: NETLINK_ROUTE policy routing questions Date: Tue, 19 Jun 2018 14:17:19 +0000 Message-ID: <34fbd7a6fc0441329af56c07cbb06ea6@garmin.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Daniel Wagner , "connman@lists.01.org" To: "netdev@vger.kernel.org" Return-path: Received: from mail-cys01nam02on0102.outbound.protection.outlook.com ([104.47.37.102]:56544 "EHLO NAM02-CY1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S937442AbeFSORY (ORCPT ); Tue, 19 Jun 2018 10:17:24 -0400 Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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://list= s.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 k= ernel bug. Connman has long-running NETLINK_ROUTE socket which binds with: memset(&addr, 0, sizeof(addr)); addr.nl_family =3D AF_NETLINK; addr.nl_groups =3D 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 set= ters, in particular, we have RTM_NEWROUTE and RTM_DELROUTE with a custom ro= uting 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 RT= M_NEWROUTE/RTM_DELROUTE messages for our custom table. Should NETLINK_ROUT= E 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 CO= NFIG_IP_MULTIPLE_TABLES enabled and when Connman sent RTM_NEWROUTE/DELROUTE= with the custom table, we got NETLINK_ROUTE messages for these actions bei= ng 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 tab= le 254 was a fallback mechanism rather than the setter returning an error. Thanks, Joel