| Message ID | 20210623113452.5671-1-rocco.yue@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/4] net: if_arp: add ARPHRD_PUREIP type | expand |
On Wed, Jun 23, 2021 at 07:34:49PM +0800, Rocco Yue wrote: > This patch add the definition of ARPHRD_PUREIP which can for > example be used by mobile ccmni device as device type. > ARPHRD_PUREIP means that this device doesn't need kernel to > generate ipv6 link-local address in any addr_gen_mode. > > Signed-off-by: Rocco Yue <rocco.yue@mediatek.com> > --- > include/uapi/linux/if_arp.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h > index c3cc5a9e5eaf..4463c9e9e8b4 100644 > --- a/include/uapi/linux/if_arp.h > +++ b/include/uapi/linux/if_arp.h > @@ -61,6 +61,7 @@ > #define ARPHRD_DDCMP 517 /* Digital's DDCMP protocol */ > #define ARPHRD_RAWHDLC 518 /* Raw HDLC */ > #define ARPHRD_RAWIP 519 /* Raw IP */ > +#define ARPHRD_PUREIP 520 /* Pure IP */ In looking at the patches, what differs "PUREIP" from "RAWIP"? It seems to be the same to me. If they are different, where is that documented? thanks, greg k-h
On Wed, 2021-06-23 at 19:19 +0200, Greg KH wrote: On Wed, Jun 23, 2021 at 07:34:49PM +0800, Rocco Yue wrote: >> This patch add the definition of ARPHRD_PUREIP which can for >> example be used by mobile ccmni device as device type. >> ARPHRD_PUREIP means that this device doesn't need kernel to >> generate ipv6 link-local address in any addr_gen_mode. >> >> Signed-off-by: Rocco Yue <rocco.yue@mediatek.com> >> --- >> include/uapi/linux/if_arp.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h >> index c3cc5a9e5eaf..4463c9e9e8b4 100644 >> --- a/include/uapi/linux/if_arp.h >> +++ b/include/uapi/linux/if_arp.h >> @@ -61,6 +61,7 @@ >> #define ARPHRD_DDCMP 517 /* Digital's DDCMP protocol */ >> #define ARPHRD_RAWHDLC 518 /* Raw HDLC */ >> #define ARPHRD_RAWIP 519 /* Raw IP */ >> +#define ARPHRD_PUREIP 520 /* Pure IP */ > > In looking at the patches, what differs "PUREIP" from "RAWIP"? It seems Thanks for your review. The difference between RAWIP and PUREIP is that they generate IPv6 link-local address and IPv6 global address in different ways. RAWIP: ~~~~~~ In the ipv6_generate_eui64() function, using RAWIP will always return 0, which will cause the kernel to automatically generate an IPv6 link-local address in EUI64 format and an IPv6 global address in EUI64 format. PUREIP: ~~~~~~~ After this patch set, when using PUREIP, kernel doesn't generate IPv6 link-local address regardless of which IN6_ADDR_GEN_MODE is used. @@ static void addrconf_dev_config(struct net_device *dev) + if (dev->type == ARPHRD_PUREIP) + return; And after recving RA message, kernel iterates over the link-local address that exists for the interface and uses the low 64bits of the link-local address to generate the IPv6 global address. The general process is as follows: ndisc_router_discovery() -> addrconf_prefix_rcv() -> ipv6_generate_eui64() -> ipv6_inherit_eui64() > to be the same to me. If they are different, where is that documented? > > thanks, > > greg k-h I tried to find corresponding documents about other device types, but I am sorry I didn't find it. If it is needed, I am willing to provide. Thanks, Rocco
On 6/23/21 9:33 PM, Rocco Yue wrote: > > The difference between RAWIP and PUREIP is that they generate IPv6 > link-local address and IPv6 global address in different ways. > > RAWIP: > ~~~~~~ > In the ipv6_generate_eui64() function, using RAWIP will always return 0, > which will cause the kernel to automatically generate an IPv6 link-local > address in EUI64 format and an IPv6 global address in EUI64 format. > > PUREIP: > ~~~~~~~ > After this patch set, when using PUREIP, kernel doesn't generate IPv6 > link-local address regardless of which IN6_ADDR_GEN_MODE is used. > > @@ static void addrconf_dev_config(struct net_device *dev) > + if (dev->type == ARPHRD_PUREIP) > + return; > > And after recving RA message, kernel iterates over the link-local address > that exists for the interface and uses the low 64bits of the link-local > address to generate the IPv6 global address. > The general process is as follows: > ndisc_router_discovery() -> addrconf_prefix_rcv() -> ipv6_generate_eui64() -> ipv6_inherit_eui64() > please add that to the commit message.
On Thu, Jun 24, 2021 at 11:33:53AM +0800, Rocco Yue wrote: > On Wed, 2021-06-23 at 19:19 +0200, Greg KH wrote: > On Wed, Jun 23, 2021 at 07:34:49PM +0800, Rocco Yue wrote: > >> This patch add the definition of ARPHRD_PUREIP which can for > >> example be used by mobile ccmni device as device type. > >> ARPHRD_PUREIP means that this device doesn't need kernel to > >> generate ipv6 link-local address in any addr_gen_mode. > >> > >> Signed-off-by: Rocco Yue <rocco.yue@mediatek.com> > >> --- > >> include/uapi/linux/if_arp.h | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h > >> index c3cc5a9e5eaf..4463c9e9e8b4 100644 > >> --- a/include/uapi/linux/if_arp.h > >> +++ b/include/uapi/linux/if_arp.h > >> @@ -61,6 +61,7 @@ > >> #define ARPHRD_DDCMP 517 /* Digital's DDCMP protocol */ > >> #define ARPHRD_RAWHDLC 518 /* Raw HDLC */ > >> #define ARPHRD_RAWIP 519 /* Raw IP */ > >> +#define ARPHRD_PUREIP 520 /* Pure IP */ > > > > In looking at the patches, what differs "PUREIP" from "RAWIP"? It seems > > Thanks for your review. > > The difference between RAWIP and PUREIP is that they generate IPv6 > link-local address and IPv6 global address in different ways. > > RAWIP: > ~~~~~~ > In the ipv6_generate_eui64() function, using RAWIP will always return 0, > which will cause the kernel to automatically generate an IPv6 link-local > address in EUI64 format and an IPv6 global address in EUI64 format. > > PUREIP: > ~~~~~~~ > After this patch set, when using PUREIP, kernel doesn't generate IPv6 > link-local address regardless of which IN6_ADDR_GEN_MODE is used. > > @@ static void addrconf_dev_config(struct net_device *dev) > + if (dev->type == ARPHRD_PUREIP) > + return; > > And after recving RA message, kernel iterates over the link-local address > that exists for the interface and uses the low 64bits of the link-local > address to generate the IPv6 global address. > The general process is as follows: > ndisc_router_discovery() -> addrconf_prefix_rcv() -> ipv6_generate_eui64() -> ipv6_inherit_eui64() Thanks for the explaination, why is this hardware somehow "special" in this way that this has never been needed before? thanks, greg k-h
On Wed, 2021-06-23 at 23:15 -0600, David Ahern wrote: On 6/23/21 9:33 PM, Rocco Yue wrote: >> >> The difference between RAWIP and PUREIP is that they generate IPv6 >> link-local address and IPv6 global address in different ways. >> >> RAWIP: >> ~~~~~~ >> In the ipv6_generate_eui64() function, using RAWIP will always return 0, >> which will cause the kernel to automatically generate an IPv6 link-local >> address in EUI64 format and an IPv6 global address in EUI64 format. >> >> PUREIP: >> ~~~~~~~ >> After this patch set, when using PUREIP, kernel doesn't generate IPv6 >> link-local address regardless of which IN6_ADDR_GEN_MODE is used. >> >> @@ static void addrconf_dev_config(struct net_device *dev) >> + if (dev->type == ARPHRD_PUREIP) >> + return; >> >> And after recving RA message, kernel iterates over the link-local address >> that exists for the interface and uses the low 64bits of the link-local >> address to generate the IPv6 global address. >> The general process is as follows: >> ndisc_router_discovery() -> addrconf_prefix_rcv() -> >> ipv6_generate_eui64() -> ipv6_inherit_eui64() >> > > please add that to the commit message. Thanks for your reminding, will do. Thanks, Rocco
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, Rocco
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. And are these user-visable flags documented in a man page or something else somewhere? If not, how does userspace know about them? thanks, greg k-h
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 ? I am willing do it. > 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. But I also failed to find a man page or a description of these device types. Thanks, Rocco
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
On Thu, 2021-06-24 at 14:13 +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. This distinction seems confusing from a kernel standpoint if it only changes how v6 IIDs are determined. Do we really need something that's also reflected to userspace (in struct ifinfomsg -> ifi_type) if the kernel is handling the behavior that's different? Why should userspace care? I'm also curious why this isn't an issue for the ipa/rmnet (Qualcomm) modem drivers. There's probably a good reason, but would be good to know what that is from Alex Elder or Loic or Bjorn... Dan > > 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, > Rocco >
> Does changelog mean adding these details to the commit message ? > > Yes please. > will do. > > > 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? Judging from the changes of ARPHRD_xxx submitted before, I am sorry I could not find the corresponding doucuments to describe their respective behaviors in details. Perhaps the best way to understand their behaviors is to read the code directly. Thanks, Rocco
On Thu, 2021-06-24 at 11:14 -0500, Dan Williams wrote: On Thu, 2021-06-24 at 14:13 +0800, Rocco Yue wrote: >> On Thu, 2021-06-24 at 07:29 +0200, Greg KH wrote: >> >> 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. > > This distinction seems confusing from a kernel standpoint if it only > changes how v6 IIDs are determined. Do we really need something that's Hi Dan, Thanks for your comment, In the cellular network, v6 IID is important, If the device use the link-local address formed by the incorrect IID to send RS message to the network, based on 3GPP, GGSN will not reply solicited RA message. It will lead to the device can get ipv6 address prefix and ipv6 route. Maybe the table below is a little bit clearer three device type: ARPHRD_RAWIP , ARPHRD_PUREIP, ARPHRD_NONE three mode: IN6_ADDR_GEN_MODE_EUI64 , IN6_ADDR_GEN_MODE_NONE, IN6_ADDR_GEN_MODE_STABLE_PRIVACY ipv6 link-local address generate behavior in the kernel: +---------+-------------------+---------------------+----------------+ | | MODE_EUI64 | MODE_STABLE_PRIVACY | MODE_NONE | +---------+-------------------+---------------------+----------------+ | RAWIP | fe80::(eui64-id) | fe80::(privacy-id) | no address gen | +---------+-------------------+---------------------+----------------+ | PUREIP | no address gen | no address gen | no address gen | +---------+-------------------+---------------------+----------------+ | NONE | fe80::(random-id) | fe80::(privacy-id) | no address gen | +---------+-------------------+---------------------+----------------+ ipv6 global address generate behavior in the kernel: +---------+-------------------+---------------------+-------------------+ | | MODE_EUI64 | MODE_STABLE_PRIVACY | MODE_NONE | +---------+-------------------+---------------------+-------------------+ | RAWIP | prefix+(eui64-id) | prefix+(privacy-id) | prefix+(eui64-id) | +---------+-------------------+---------------------+-------------------+ | PUREIP | prefix+(GGSN-id) | prefix+(privacy-id) | prefix+(GGSN-id) | +---------+-------------------+---------------------+-------------------+ | NONE | prefix+(random-id)| prefix+(privacy-id) | prefix+(random-id)| +---------+-------------------+---------------------+-------------------+ > also reflected to userspace (in struct ifinfomsg -> ifi_type) if the > kernel is handling the behavior that's different? Why should userspace > care? > In my opinion, userspace program cares about it because the kernel behaves differently for different device types. userspace can get the device type of the interface through ioctl, such as the following code weblink: https://cs.android.com/android/platform/superproject/+/master:system/netd/server/OffloadUtils.cpp;drc=master;l=41?q=ARPHRD_RAWIP&ss=android%2Fplatform%2Fsuperproject&start=11 > I'm also curious why this isn't an issue for the ipa/rmnet (Qualcomm) > modem drivers. There's probably a good reason, but would be good to > know what that is from Alex Elder or Loic or Bjorn... > > Dan MediaTek and Qualcomm has different hardware or modem design. For the MediaTek platform, device send the RS message that generated by the kernel to the GGSN. Thanks, Rocco
diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h index c3cc5a9e5eaf..4463c9e9e8b4 100644 --- a/include/uapi/linux/if_arp.h +++ b/include/uapi/linux/if_arp.h @@ -61,6 +61,7 @@ #define ARPHRD_DDCMP 517 /* Digital's DDCMP protocol */ #define ARPHRD_RAWHDLC 518 /* Raw HDLC */ #define ARPHRD_RAWIP 519 /* Raw IP */ +#define ARPHRD_PUREIP 520 /* Pure IP */ #define ARPHRD_TUNNEL 768 /* IPIP tunnel */ #define ARPHRD_TUNNEL6 769 /* IP6IP6 tunnel */
This patch add the definition of ARPHRD_PUREIP which can for example be used by mobile ccmni device as device type. ARPHRD_PUREIP means that this device doesn't need kernel to generate ipv6 link-local address in any addr_gen_mode. Signed-off-by: Rocco Yue <rocco.yue@mediatek.com> --- include/uapi/linux/if_arp.h | 1 + 1 file changed, 1 insertion(+)