On Thu, Jun 24, 2021 at 08:24:35PM +0800, Rocco Yue wrote: > On Thu, 2021-06-24 at 11:04 +0200, Greg KH wrote: > On Thu, Jun 24, 2021 at 02:13:10PM +0800, Rocco Yue wrote: > >> On Thu, 2021-06-24 at 07:29 +0200, Greg KH wrote: > >>> > >>> Thanks for the explaination, why is this hardware somehow "special" in > >>> this way that this has never been needed before? > >>> > >>> thanks, > >>> > >>> greg k-h > >>> > >> > >> Before kernel-4.18, RAWIP was the same as PUREIP, neither of them > >> automatically generates an IPv6 link-local address, and the way to > >> generate an IPv6 global address is the same. > >> > >> After kernel-4.18 (include 4.18 version), the behavior of RAWIP had > >> changed due to the following patch: > >> @@ static int ipv6_generate_eui64(u8 *eui, struct net_device *dev) > >> + case ARPHRD_RAWIP: > >> + return addrconf_ifid_rawip(eui, dev); > >> } > >> return -1; > >> } > >> > >> the reason why the kernel doesn't need to generate the link-local > >> address automatically is as follows: > >> > >> In the 3GPP 29.061, here is some description as follows: > >> "in order to avoid any conflict between the link-local address of > >> MS and that of the GGSN, the Interface-Identifier used by the MS to > >> build its link-local address shall be assigned by the GGSN. The GGSN > >> ensures the uniqueness of this Interface-Identifier. Then MT shall > >> then enforce the use of this Interface-Identifier by the TE" > >> > >> In other words, in the cellular network, GGSN determines whether to > >> reply to the Router Solicitation message of UE by identifying the > >> low 64bits of UE interface's ipv6 link-local address. > >> > >> When using a new kernel and RAWIP, kernel will generate an EUI64 > >> format ipv6 link-local address, and if the device uses this address > >> to send RS, GGSN will not reply RA message. > >> > >> Therefore, in that background, we came up with PUREIP to make kernel > >> doesn't generate a ipv6 link-local address in any address generate > >> mode. > > > > Thanks for the better description. That should go into the changelog > > text somewhere so that others know what is going on here with this new > > option. > > > > Does changelog mean adding these details to the commit message ? Yes please. > > And are these user-visable flags documented in a man page or something > > else somewhere? If not, how does userspace know about them? > > > > There are mappings of these device types value in the libc: > "/bionic/libc/kernel/uapi/linux/if_arp.h". > userspace can get it from here. Yes, they will show up in a libc definition, but where is it documented in text form what the flag does? thanks, greg k-h
