From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson To: passt-dev@passt.top Subject: Re: [PATCH 17/18] tests: Correct determination of host interface name in tests Date: Wed, 20 Jul 2022 12:47:57 +1000 Message-ID: In-Reply-To: <20220719210552.45329b70@elisabeth> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7546145198002608670==" --===============7546145198002608670== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2022 at 09:05:52PM +0200, Stefano Brivio wrote: > On Tue, 19 Jul 2022 16:20:45 +1000 > David Gibson wrote: >=20 > > On Fri, Jul 15, 2022 at 03:21:40PM +1000, David Gibson wrote: > > > By default, passt itself attaches to the first host interface with a > > > default route. However, when determining the host interface name the t= ests > > > implicitly select the *last* host interface: they use a jq expression w= hich > > > will list all interfaces with default routes, but the way output detect= ion > > > works in the scripts, it will only pick up the last line. > > >=20 > > > If there are multiple interfaces with default routes on the host, and t= hey > > > each have a different address, this can cause spurious test > > > failures. =20 > >=20 > > It seems this change is not enough to always fix the tests when there > > are multiple default routes. I'm still sometimes getting failures, > > now because passt itself doesn't seem to be picking the interface > > with the first default route. > >=20 > > I'm wondering if this is because ip(8) is sorting the output, not just > > presenting it in the same order that the underlying netlink interface > > does. >=20 > I don't see that happening at least in my environment (and I also can't > see any code that would sort it, that pretty much comes from > rtnl_dump_filter_l() in lib/libnetlink.c). >=20 > The netlink "filter", though, is slightly different. For IPv4: >=20 > $ strace -e sendto ip route show >/dev/null > sendto(3, [{{len=3D36, type=3DRTM_GETROUTE, flags=3DNLM_F_REQUEST|NLM_F_DUM= P, seq=3D1658257027, pid=3D0}, {rtm_family=3DAF_INET, rtm_dst_len=3D0, rtm_sr= c_len=3D0, rtm_tos=3D0, rtm_table=3DRT_TABLE_UNSPEC, rtm_protocol=3DRTPROT_UN= SPEC, rtm_scope=3DRT_SCOPE_UNIVERSE, rtm_type=3DRTN_UNSPEC, rtm_flags=3D0}, {= {nla_len=3D8, nla_type=3DRTA_TABLE}, RT_TABLE_MAIN}}, {len=3D0, type=3D0 /* N= LMSG_??? */, flags=3D0, seq=3D0, pid=3D0}], 156, 0, NULL, 0) =3D 156 >=20 > $ strace -e sendto ./passt -f > sendto(5, {{len=3D28, type=3DRTM_GETROUTE, flags=3DNLM_F_REQUEST|NLM_F_DUMP= , seq=3D0, pid=3D0}, {rtm_family=3DAF_INET, rtm_dst_len=3D0, rtm_src_len=3D0,= rtm_tos=3D0, rtm_table=3DRT_TABLE_MAIN, rtm_protocol=3DRTPROT_UNSPEC, rtm_sc= ope=3DRT_SCOPE_UNIVERSE, rtm_type=3DRTN_UNICAST, rtm_flags=3D0}}, 28, 0, NULL= , 0) =3D 28 > [...] >=20 > and, while I don't think the FIB trie is actually descended in a > different way, we might still have a slightly different result from the > kernel (if I recall correctly, I didn't check right now). >=20 > But letting that aside for a moment: if you have two default routes, I > suppose they have different metrics. If not, what's the intended usage? Yes, there are two different metrics. I was thinking after I sent this that we should sort by metric. > If yes, we should probably implement a sorting logic in passt, so that > the route with the lowest metric is picked, and then adjust the jq > expression to also pick that one. Agreed. I'll see if I can implement this. Up to you whether you drop this patch or I just do another update on top of it. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --===============7546145198002608670== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ0FBZEZpRUVvVUx4V3U0L1dz MGRCK1h0Z3lwWTRnRXdZU0lGQW1MWGJOWUFDZ2tRZ3lwWTRnRXcKWVNKSERoQUFyWkQxMGJ1WDNa SmVZRkVnc1pIUWVaNWVHdGxnbVM4TG41cVZ6amlybmdzdEdVb0g4cWQxam9FQQpBUGtNeHZ0RG0x R2lCRlJpRlV1UUxoUlB5RjlyNTNrL1BDTzNyNXJDc1dZd2hqWG52SmNzY2RRaS8yek9xQmltCi9Q NExGL3R5UGhIamprcGl6N0lkSUo2VVBWSGJ6eDUvaXUzY2szM1FFRHhyRFZ4Zk95Mm5XRkZ0WEVN QVhGV1MKbnFwQ1hRc1VVUkw2YVA0dWtObXNMdTNnQUxmWVVEMFdNeHE1SFRBekZCcHRWM0RRQlB6 VWltZ0xlUHdoWFlvWQpnem5HTEdVajN2VFlDT2JpQWplRkxYM1F5V2xtb0k5RFp1TEN1K2tTeTdR MlJVcHp4NXBMemJRSm90ZzhtSWs3CjRveEJyVk9ab0huUTRqcURMU05WbWcvRFo3TGU4UW5tYkZB VGwxcEF4eEtFUHBkZG5UYUxqS1N5L0ZpL1owOWQKOVBQbVpjZmM2WTBSL1VhQUg4Z3RuTjJrWEZB L1BBTGZUNFI2Z1FnZXMrbUFvNlBwZHIyMS9wWHFvQ3U1YUYwNgpTd0FtUkVPREl3TFR4N0xUczBK M2xpMUpLam42ZUg2ODJYK0pxSzA0aU5ZY3dXZlhxeTAzdlVPeHdTZ25Jb05OCkpDakQ3M2RSYy9N MU9iYzdkKzhQdDZUa3QzNCtvbXNqeWh0YW1xY29GdnlINmZnUU53SEc0aW5BV3NJMzIvQ2IKSVJD RktCeTVORXR5R0l2Z1g1NmVZNUpiaTltUG81OGZGZmNHUFQyNUo1SDduNmpOSC9HYUo5VVZ5RjN3 dm5jcApWeENNQ1NZTEtST04raHBRVDI3MVFhemY3MEVXVUx3M0ZUTCtzYmpjbjZ5TTU4YXBrVlE9 Cj14aysrCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============7546145198002608670==--