Re: kern/54150: COMPAT_50 vs NET_RT_IFLIST

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/54150; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/54150: COMPAT_50 vs NET_RT_IFLIST
Date: Fri, 03 May 2019 02:48:00 +0700

 I think I understand what might be happening here now.
 
 getifaddrs() uses sysctl(net.route.0.0.iflist.0)
 
 That sysctl returns a list of message structures, when we are
 running compatible userland/kernel there will be a sequence of
 RTM_IFINFO ad RTM_NEWADDR messages.
 
 When userland is NetBSD 5, the RTM_IFINFO is replaced by RTM_OOIFINFO
 (which is generated by compat_50_iflist) and RTM_ONEWADDR (which is
 generated by compat_70_iflist_addr)
 
 It is compat_70_iflist_addr as this structure had not changed between
 netbsd 5 and netbsd 7 (the change between netbsd 7 and 8 was the first
 change of that struct)
 
 Of itself, all that is OK.   However, there is another change.  Each
 message is preceded by a header, which starts with a length, type,
 and version.   The length and type are handled by the code above.
 
 Unfortunately, RTM_VERSION altered between NetBSD 5 and NetBSD 7,
 compat_50_iflist() generates a message rith RTM_OVERSION (3) in it, and
 compat_70_iflist_addr() generates a message with RTM_VERSION (4).
 Those are the appropriate values for NetBSD 5 and 7 resp.
 
 But both of those end up appearing in the same sysctl result.
 
 getifaddrs() (all versions - or at least, the NetBSD 5 and later ones,
 which is all Ihave looked at) checks that the version field is
 RTM_VERSION (whichever version is appropriate for the version of
 getifaddrs() in use) and ignores anything that is not.
 
 The NEWADDR messages, which appear as RTMVersion 4 all get ignored by
 a NetBSD 5 getifaddrs(), and those are what contain the interface names
 (plus more).
 
 I suspect that what we need is to make a compat_50_iflist_addr()
 function, identical to compat_70_iflist_addr() except using RTM_OVERSION
 instead of RTM_VERSION (the two could use some common routine to fill in
 all the rest of the details).   However, I have not yet tried it.
 
 kre