Currently there are two ways how to create a new ppp interface. Old method
via ioctl(PPPIOCNEWUNIT) and new method via rtnl RTM_NEWLINK/NLM_F_CREATE
which was introduced in v4.7 by commit 96d934c70db6 ("ppp: add rtnetlink
device creation support").
Old method allows userspace to specify preferred ppp unit id or let kernel
to choose some free ppp unit id. Newly created interface by the old method
will always have name composed of string "ppp" followed by ppp unit id.
Userspace later can rename interface via ioctl(SIOCSIFNAME).
New method via rtnl does not allow to specify ppp unit id and kernel always
choose some free one. But allows to specify interface name and therefore
atomically create interface with preferred name.
So based on requirement userspace needs to use either old method or new
method as none currently supports all options.
This change adds a new rtnl attribute IFLA_PPP_UNIT_ID which can be used
for specifying preferred ppp unit id during rtnl RTM_NEWLINK/NLM_F_CREATE
call. And therefore implements missing functionality which is already
provided by old ioctl(PPPIOCNEWUNIT) method.
By default kernel ignores unknown rtnl attributes, so userspace cannot
easily check if kernel understand this new IFLA_PPP_UNIT_ID or if will
ignore it.
Therefore in ppp_nl_validate() first validates content of IFLA_PPP_UNIT_ID
attribute and returns -EINVAL when ppp unit id is invalid. And after that
validates IFLA_PPP_DEV_FD (which returns -EBADFD on error).
This allows userspace to send RTM_NEWLINK/NLM_F_CREATE request with
negative IFLA_PPP_DEV_FD and non-negative IFLA_PPP_UNIT_ID to detect if
kernel supports IFLA_PPP_DEV_FD or not (based on -EINVAL / -EBADFD error
value).
Like in old ioctl(PPPIOCNEWUNIT) method treat special IFLA_PPP_UNIT_ID
value -1 to let kernel choose some free ppp unit id. It is same behavior
like when IFLA_PPP_UNIT_ID is not specified at all. Later userspace can use
ioctl(PPPIOCGUNIT) to query which ppp unit id kernel chose.
As this is a new code kernel does not have to overwrite and hide error code
from ppp_unit_register() when using new rtnl method. So overwrite error
code to -EEXIST only when creating a new interface via old ioctl method.
With this change rtnl RTM_NEWLINK/NLM_F_CREATE can be finally full-feature
replacement for the old ioctl(PPPIOCNEWUNIT) method for creating new ppp
network interface.
Signed-off-by: Pali Rohár <pali@kernel.org>
---
drivers/net/ppp/ppp_generic.c | 29 ++++++++++++++++++++++-------
include/uapi/linux/if_link.h | 2 ++
tools/include/uapi/linux/if_link.h | 2 ++
3 files changed, 26 insertions(+), 7 deletions(-)
@@ -1181,8 +1181,10 @@ static int ppp_unit_register(struct ppp *ppp, int unit, bool ifname_is_set)}ret=unit_set(&pn->units_idr,ppp,unit);if(ret<0){-/* Rewrite error for backward compatibility */-ret=-EEXIST;+if(rewrite_error){+/* Rewrite error for backward compatibility */+ret=-EEXIST;+}gotoerr;}}
@@ -1211,7 +1213,7 @@ static int ppp_unit_register(struct ppp *ppp, int unit, bool ifname_is_set)}staticintppp_dev_configure(structnet*src_net,structnet_device*dev,-conststructppp_config*conf)+conststructppp_config*conf,boolrewrite_error){structppp*ppp=netdev_priv(dev);intindx;
@@ -1249,7 +1251,7 @@ static int ppp_dev_configure(struct net *src_net, struct net_device *dev,ppp->active_filter=NULL;#endif /* CONFIG_PPP_FILTER */-err=ppp_unit_register(ppp,conf->unit,conf->ifname_is_set);+err=ppp_unit_register(ppp,conf->unit,conf->ifname_is_set,rewrite_error);if(err<0)gotoerr2;
@@ -1264,6 +1266,7 @@ static int ppp_dev_configure(struct net *src_net, struct net_device *dev,staticconststructnla_policyppp_nl_policy[IFLA_PPP_MAX+1]={[IFLA_PPP_DEV_FD]={.type=NLA_S32},+[IFLA_PPP_UNIT_ID]={.type=NLA_S32},};staticintppp_nl_validate(structnlattr*tb[],structnlattr*data[],
@@ -1274,6 +1277,15 @@ static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[],if(!data[IFLA_PPP_DEV_FD])return-EINVAL;++/* Check for IFLA_PPP_UNIT_ID before IFLA_PPP_DEV_FD to allow userspace+*detectifkernelsupportsIFLA_PPP_UNIT_IDornotbyspecifying+*negativeIFLA_PPP_DEV_FD.Previouskernelversionsignored+*IFLA_PPP_UNIT_IDattribute.+*/+if(data[IFLA_PPP_UNIT_ID]&&nla_get_s32(data[IFLA_PPP_UNIT_ID])<-1)+return-EINVAL;+if(nla_get_s32(data[IFLA_PPP_DEV_FD])<0)return-EBADF;
@@ -1295,6 +1307,9 @@ static int ppp_nl_newlink(struct net *src_net, struct net_device *dev,if(!file)return-EBADF;+if(data[IFLA_PPP_UNIT_ID])+conf.unit=nla_get_s32(data[IFLA_PPP_UNIT_ID]);+/* rtnl_lock is already held here, but ppp_create_interface() locks*ppp_mutexbeforeholdingrtnl_lock.Usingmutex_trylock()avoids*possibledeadlockduetolockorderinversion,atthecostof
@@ -1320,7 +1335,7 @@ static int ppp_nl_newlink(struct net *src_net, struct net_device *dev,if(!tb[IFLA_IFNAME]||!nla_len(tb[IFLA_IFNAME])||!*(char*)nla_data(tb[IFLA_IFNAME]))conf.ifname_is_set=false;-err=ppp_dev_configure(src_net,dev,&conf);+err=ppp_dev_configure(src_net,dev,&conf,false);out_unlock:mutex_unlock(&ppp_mutex);
@@ -3300,7 +3315,7 @@ static int ppp_create_interface(struct net *net, struct file *file, int *unit)rtnl_lock();-err=ppp_dev_configure(net,dev,&conf);+err=ppp_dev_configure(net,dev,&conf,true);if(err<0)gotoerr_dev;ppp=netdev_priv(dev);
From: Jakub Kicinski <kuba@kernel.org> Date: 2021-08-09 19:25:52
On Sat, 7 Aug 2021 18:37:49 +0200 Pali Rohár wrote:
Currently there are two ways how to create a new ppp interface. Old method
via ioctl(PPPIOCNEWUNIT) and new method via rtnl RTM_NEWLINK/NLM_F_CREATE
which was introduced in v4.7 by commit 96d934c70db6 ("ppp: add rtnetlink
device creation support").
...
Your 2 previous patches were fixes and went into net, this patch seems
to be on top of them but is a feature, so should go to net-next.
But it doesn't apply to net-next given net was not merged into net-next.
Please rebase on top of net-next or (preferably) wait until next week
so that the trees can get merged and then you can repost without causing
any conflicts.
On Monday 09 August 2021 12:25:46 Jakub Kicinski wrote:
On Sat, 7 Aug 2021 18:37:49 +0200 Pali Rohár wrote:
quoted
Currently there are two ways how to create a new ppp interface. Old method
via ioctl(PPPIOCNEWUNIT) and new method via rtnl RTM_NEWLINK/NLM_F_CREATE
which was introduced in v4.7 by commit 96d934c70db6 ("ppp: add rtnetlink
device creation support").
...
Your 2 previous patches were fixes and went into net, this patch seems
to be on top of them but is a feature, so should go to net-next.
Yes
But it doesn't apply to net-next given net was not merged into net-next.
Please rebase on top of net-next or (preferably) wait until next week
so that the trees can get merged and then you can repost without causing
any conflicts.
Better to wait. I would like hear some comments / review on this patch
if this is the correct approach as it adds a new API/ABI for userspace.
set .strict_start_type, please so new attrs get validated better
quoted
static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[],
@@ -1274,6 +1277,15 @@ static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[], if (!data[IFLA_PPP_DEV_FD]) return -EINVAL;++ /* Check for IFLA_PPP_UNIT_ID before IFLA_PPP_DEV_FD to allow userspace+ * detect if kernel supports IFLA_PPP_UNIT_ID or not by specifying+ * negative IFLA_PPP_DEV_FD. Previous kernel versions ignored+ * IFLA_PPP_UNIT_ID attribute.+ */+ if (data[IFLA_PPP_UNIT_ID] && nla_get_s32(data[IFLA_PPP_UNIT_ID]) < -1)+ return -EINVAL;
please use NLA_POLICY_MIN() instead, no need to open-code
quoted
if (nla_get_s32(data[IFLA_PPP_DEV_FD]) < 0)
return -EBADF;
I will look at both issues... and I would like to know what is preferred
way to introduce new attributes in a way that userspace can detect if
kernel supports them or not.
On Mon, Aug 09, 2021 at 09:31:09PM +0200, Pali Rohár wrote:
Better to wait. I would like hear some comments / review on this patch
if this is the correct approach as it adds a new API/ABI for userspace.
Personally I don't understand the use case for setting the ppp unit at
creation time. I didn't implement it on purpose when creating the
netlink interface, as I didn't have any use case.
On the other hand, adding the ppp unit in the netlink dump is probably
useful.
On Tuesday 10 August 2021 17:39:41 Guillaume Nault wrote:
On Mon, Aug 09, 2021 at 09:31:09PM +0200, Pali Rohár wrote:
quoted
Better to wait. I would like hear some comments / review on this patch
if this is the correct approach as it adds a new API/ABI for userspace.
Personally I don't understand the use case for setting the ppp unit at
creation time.
I know about two use cases:
* ppp unit id is used for generating network interface name. So if you
want interface name ppp10 then you request for unit id 10. It is
somehow common that when ppp interface has prefix "ppp" in its name
then it is followed by unit id. Seems that existing ppp applications
which use "ppp<num>" naming expects this. But of course you do not
have to use this convention and rename interfaces as you want.
* Some of ppp ioctls use unit id. So you may want to use some specific
number for some network interface. So e.g. unit id 1 will be always
for /dev/ttyUSB1.
I didn't implement it on purpose when creating the
netlink interface, as I didn't have any use case.
On the other hand, adding the ppp unit in the netlink dump is probably
useful.
On Tue, Aug 10, 2021 at 06:04:50PM +0200, Pali Rohár wrote:
On Tuesday 10 August 2021 17:39:41 Guillaume Nault wrote:
quoted
On Mon, Aug 09, 2021 at 09:31:09PM +0200, Pali Rohár wrote:
quoted
Better to wait. I would like hear some comments / review on this patch
if this is the correct approach as it adds a new API/ABI for userspace.
Personally I don't understand the use case for setting the ppp unit at
creation time.
I know about two use cases:
* ppp unit id is used for generating network interface name. So if you
want interface name ppp10 then you request for unit id 10. It is
somehow common that when ppp interface has prefix "ppp" in its name
then it is followed by unit id. Seems that existing ppp applications
which use "ppp<num>" naming expects this. But of course you do not
have to use this convention and rename interfaces as you want.
Really, with the netlink API, the interface name has to be set with
IFLA_IFNAME. There's no point in adding a new attribute just to have a
side effect on the device name.
* Some of ppp ioctls use unit id. So you may want to use some specific
number for some network interface. So e.g. unit id 1 will be always
for /dev/ttyUSB1.
But what's the point of forcing unit id 1 for a particular interface?
One can easily get the assigned unit id with ioctl(PPPIOCGUNIT).
quoted
I didn't implement it on purpose when creating the
netlink interface, as I didn't have any use case.
On the other hand, adding the ppp unit in the netlink dump is probably
useful.
Yes, this could be really useful as currently if you ask netlink to
create a new ppp interface you have to use ioctl to retrieve this unit
id. But ppp currently does not provide netlink dump operation.
Also it could be useful for this "bug":
https://lore.kernel.org/netdev/20210807132703.26303-1-pali@kernel.org/t/#u
This patch itself makes sense, but how is that related to unit id?
This patch shows why linking unit id and interface name are a bad idea.
Instead of adding more complexity with unit id, I'd prefer to have a
new netlink attribute that says "don't generate the interface name
based on the unit id". That's how the original implementation worked by
the way and I'm really sad I accepted to change it...
But due to how it is used we probably have to deal with it how ppp unit
id are defined and assigned...
On Wednesday 11 August 2021 19:19:18 Guillaume Nault wrote:
On Tue, Aug 10, 2021 at 06:04:50PM +0200, Pali Rohár wrote:
quoted
On Tuesday 10 August 2021 17:39:41 Guillaume Nault wrote:
quoted
On Mon, Aug 09, 2021 at 09:31:09PM +0200, Pali Rohár wrote:
quoted
Better to wait. I would like hear some comments / review on this patch
if this is the correct approach as it adds a new API/ABI for userspace.
Personally I don't understand the use case for setting the ppp unit at
creation time.
I know about two use cases:
* ppp unit id is used for generating network interface name. So if you
want interface name ppp10 then you request for unit id 10. It is
somehow common that when ppp interface has prefix "ppp" in its name
then it is followed by unit id. Seems that existing ppp applications
which use "ppp<num>" naming expects this. But of course you do not
have to use this convention and rename interfaces as you want.
Really, with the netlink API, the interface name has to be set with
IFLA_IFNAME. There's no point in adding a new attribute just to have a
side effect on the device name.
Yes, if you set IFLA_IFNAME then interface has name which you set. But
if IFLA_IFNAME is not set then there is already API/ABI behavior how
this interface name is generated. And all existing ppp software depends
on it.
quoted
* Some of ppp ioctls use unit id. So you may want to use some specific
number for some network interface. So e.g. unit id 1 will be always
for /dev/ttyUSB1.
But what's the point of forcing unit id 1 for a particular interface?
One can easily get the assigned unit id with ioctl(PPPIOCGUNIT).
Same point as ability to assign any other id to objects. It is
identifier and you may want to use specific identifier for specific
objects.
Old ioctl API provides a way how to set this custom unit id. Why should
somebody use new rtnl API if it provides only half of features? Existing
software already use this feature to allow users / administrators to
specify ids as they want.
quoted
quoted
I didn't implement it on purpose when creating the
netlink interface, as I didn't have any use case.
On the other hand, adding the ppp unit in the netlink dump is probably
useful.
Yes, this could be really useful as currently if you ask netlink to
create a new ppp interface you have to use ioctl to retrieve this unit
id. But ppp currently does not provide netlink dump operation.
Also it could be useful for this "bug":
https://lore.kernel.org/netdev/20210807132703.26303-1-pali@kernel.org/t/#u
This patch itself makes sense, but how is that related to unit id?
Now I see, it does not help in this unit id scenario...
This patch shows why linking unit id and interface name are a bad idea.
Yea... It is not a good idea, but it is how ppp is implemented in
kernel since beginning. And it affects both ioctl and rtnl APIs. So we
cannot do anything with it due to backward compatibility :-(
Instead of adding more complexity with unit id, I'd prefer to have a
new netlink attribute that says "don't generate the interface name
based on the unit id". That's how the original implementation worked by
the way and I'm really sad I accepted to change it...
Main issue there is that kernel currently does not provide any way how
to retrieve interface which was created by rtnl call. So matching
interface name by string "ppp" followed by unit id is currently the only
option.
I must admit that ppp rtnl API was designed incorrectly. If it was able
to solve this issue since beginning then this unit id <--> interface
mapping did not have to been implemented in rtnl code path.
But it is too late now, if rtnl API has to be backward compatible then
its behavior needs to be as it is currently.
quoted
But due to how it is used we probably have to deal with it how ppp unit
id are defined and assigned...
On Wed, Aug 11, 2021 at 07:54:49PM +0200, Pali Rohár wrote:
On Wednesday 11 August 2021 19:19:18 Guillaume Nault wrote:
quoted
On Tue, Aug 10, 2021 at 06:04:50PM +0200, Pali Rohár wrote:
quoted
On Tuesday 10 August 2021 17:39:41 Guillaume Nault wrote:
quoted
On Mon, Aug 09, 2021 at 09:31:09PM +0200, Pali Rohár wrote:
quoted
Better to wait. I would like hear some comments / review on this patch
if this is the correct approach as it adds a new API/ABI for userspace.
Personally I don't understand the use case for setting the ppp unit at
creation time.
I know about two use cases:
* ppp unit id is used for generating network interface name. So if you
want interface name ppp10 then you request for unit id 10. It is
somehow common that when ppp interface has prefix "ppp" in its name
then it is followed by unit id. Seems that existing ppp applications
which use "ppp<num>" naming expects this. But of course you do not
have to use this convention and rename interfaces as you want.
Really, with the netlink API, the interface name has to be set with
IFLA_IFNAME. There's no point in adding a new attribute just to have a
side effect on the device name.
Yes, if you set IFLA_IFNAME then interface has name which you set. But
if IFLA_IFNAME is not set then there is already API/ABI behavior how
this interface name is generated. And all existing ppp software depends
on it.
They depend on the ioctl api, which is not going to change.
The netlink api on the other hand is free to avoid propagating mistakes
from the past.
quoted
quoted
* Some of ppp ioctls use unit id. So you may want to use some specific
number for some network interface. So e.g. unit id 1 will be always
for /dev/ttyUSB1.
But what's the point of forcing unit id 1 for a particular interface?
One can easily get the assigned unit id with ioctl(PPPIOCGUNIT).
Same point as ability to assign any other id to objects. It is
identifier and you may want to use specific identifier for specific
objects.
Again, what's the use case? Unit ids are kernel internal identifiers.
The only purpose of setting them from user space was to influence the
name of the ppp device for legacy systems that couldn't do that in a
clean way. But any system with the netlink interface won't need this
work around.
Old ioctl API provides a way how to set this custom unit id. Why should
somebody use new rtnl API if it provides only half of features?
You still haven't provided any use case for setting the unit id in user
space, appart for influencing the interface name. Netlink also allows
to set the interface name and provides much more features (like
creating the device in a different netns).
Existing
software already use this feature to allow users / administrators to
specify ids as they want.
This patch shows why linking unit id and interface name are a bad idea.
Yea... It is not a good idea, but it is how ppp is implemented in
kernel since beginning. And it affects both ioctl and rtnl APIs. So we
cannot do anything with it due to backward compatibility :-(
Sorry, but I still hardly see the problem with the netlink api.
I shouldn't have accepted to let the unit id influence the interface
name, true. But that doesn't seem to be what you're complaining about.
Also, it could be useful to add the unit id in netlink dumps. But we
already agreed on that.
quoted
Instead of adding more complexity with unit id, I'd prefer to have a
new netlink attribute that says "don't generate the interface name
based on the unit id". That's how the original implementation worked by
the way and I'm really sad I accepted to change it...
Main issue there is that kernel currently does not provide any way how
to retrieve interface which was created by rtnl call. So matching
interface name by string "ppp" followed by unit id is currently the only
option.
Yes, that's an old limitation of rtnl. But it's a much more general
problem. A work around is to set the interface name in the netlink
request. I can't see how forcing the unit id could ever help.
I must admit that ppp rtnl API was designed incorrectly. If it was able
to solve this issue since beginning then this unit id <--> interface
mapping did not have to been implemented in rtnl code path.
As I already proposed, we can add an attribute to make the interface
name independant from the unit id.
But it is too late now, if rtnl API has to be backward compatible then
its behavior needs to be as it is currently.
Adding a new attribute is always possible.
quoted
quoted
But due to how it is used we probably have to deal with it how ppp unit
id are defined and assigned...
On Thursday 12 August 2021 11:19:41 Guillaume Nault wrote:
On Wed, Aug 11, 2021 at 07:54:49PM +0200, Pali Rohár wrote:
quoted
On Wednesday 11 August 2021 19:19:18 Guillaume Nault wrote:
quoted
On Tue, Aug 10, 2021 at 06:04:50PM +0200, Pali Rohár wrote:
quoted
On Tuesday 10 August 2021 17:39:41 Guillaume Nault wrote:
quoted
On Mon, Aug 09, 2021 at 09:31:09PM +0200, Pali Rohár wrote:
quoted
Better to wait. I would like hear some comments / review on this patch
if this is the correct approach as it adds a new API/ABI for userspace.
Personally I don't understand the use case for setting the ppp unit at
creation time.
I know about two use cases:
* ppp unit id is used for generating network interface name. So if you
want interface name ppp10 then you request for unit id 10. It is
somehow common that when ppp interface has prefix "ppp" in its name
then it is followed by unit id. Seems that existing ppp applications
which use "ppp<num>" naming expects this. But of course you do not
have to use this convention and rename interfaces as you want.
Really, with the netlink API, the interface name has to be set with
IFLA_IFNAME. There's no point in adding a new attribute just to have a
side effect on the device name.
Yes, if you set IFLA_IFNAME then interface has name which you set. But
if IFLA_IFNAME is not set then there is already API/ABI behavior how
this interface name is generated. And all existing ppp software depends
on it.
They depend on the ioctl api, which is not going to change.
The netlink api on the other hand is free to avoid propagating mistakes
from the past.
quoted
quoted
quoted
* Some of ppp ioctls use unit id. So you may want to use some specific
number for some network interface. So e.g. unit id 1 will be always
for /dev/ttyUSB1.
But what's the point of forcing unit id 1 for a particular interface?
One can easily get the assigned unit id with ioctl(PPPIOCGUNIT).
Same point as ability to assign any other id to objects. It is
identifier and you may want to use specific identifier for specific
objects.
Again, what's the use case? Unit ids are kernel internal identifiers.
The only purpose of setting them from user space was to influence the
name of the ppp device for legacy systems that couldn't do that in a
clean way. But any system with the netlink interface won't need this
work around.
quoted
Old ioctl API provides a way how to set this custom unit id. Why should
somebody use new rtnl API if it provides only half of features?
You still haven't provided any use case for setting the unit id in user
space, appart for influencing the interface name. Netlink also allows
to set the interface name and provides much more features (like
creating the device in a different netns).
quoted
Existing
software already use this feature to allow users / administrators to
specify ids as they want.
This patch shows why linking unit id and interface name are a bad idea.
Yea... It is not a good idea, but it is how ppp is implemented in
kernel since beginning. And it affects both ioctl and rtnl APIs. So we
cannot do anything with it due to backward compatibility :-(
Sorry, but I still hardly see the problem with the netlink api.
The problem is that ppp from rtnl is of the same class as ppp from
ioctl. And if you want to use ppp, you still have to use lot of ioctl
calls as rtnl does not implement them. And these ioctl calls use ppp
unit id, not interface id / interface name.
So in the end you can use RTM_NEWLINK and then control ppp via ioctls.
And for controlling you have to known that ppp unit id.
If you are using ppp over serial devices, you can "simplify" it by
forcing mapping that serial number device matches ppp unit id. And then
you do not have to use dynamic ids (and need for call PPPIOCGUNIT).
With dynamic unit id allocation (which is currently the only option when
creating ppp via rtnl) for single ppp connection you need to know:
* id of serial tty device
* id of channel bound to tty device
* id of network interface
* id of ppp unit bound to network interface
I shouldn't have accepted to let the unit id influence the interface
name, true.
I agree here. But it is too late.
But that doesn't seem to be what you're complaining about.
Also, it could be useful to add the unit id in netlink dumps. But we
already agreed on that.
Yes!
quoted
quoted
Instead of adding more complexity with unit id, I'd prefer to have a
new netlink attribute that says "don't generate the interface name
based on the unit id". That's how the original implementation worked by
the way and I'm really sad I accepted to change it...
Main issue there is that kernel currently does not provide any way how
to retrieve interface which was created by rtnl call. So matching
interface name by string "ppp" followed by unit id is currently the only
option.
Yes, that's an old limitation of rtnl. But it's a much more general
problem. A work around is to set the interface name in the netlink
request. I can't see how forcing the unit id could ever help.
quoted
I must admit that ppp rtnl API was designed incorrectly. If it was able
to solve this issue since beginning then this unit id <--> interface
mapping did not have to been implemented in rtnl code path.
As I already proposed, we can add an attribute to make the interface
name independant from the unit id.
quoted
But it is too late now, if rtnl API has to be backward compatible then
its behavior needs to be as it is currently.
Adding a new attribute is always possible.
I agree, that above proposal with a new attribute which makes interface
name independent from the ppp unit id is a good idea. Probably it should
have been default rtnl behavior (but now it is too late for changing
default behavior).
But prior adding this attribute, we first need a way how to retrieve
interface name of newly created interface. Which we agreed that
NLM_F_ECHO for RTM_NEWLINK/NLM_F_CREATE is needed.
quoted
quoted
quoted
But due to how it is used we probably have to deal with it how ppp unit
id are defined and assigned...
On Thu, Aug 12, 2021 at 04:09:18PM +0200, Pali Rohár wrote:
The problem is that ppp from rtnl is of the same class as ppp from
ioctl. And if you want to use ppp, you still have to use lot of ioctl
calls as rtnl does not implement them. And these ioctl calls use ppp
unit id, not interface id / interface name.
Indeed, the netlink api only replaces ioctl(PPPIOCNEWUNIT). It's
technically feasible to implement other ppp unit ioctls with netlink,
but I didn't do that because:
* some of them make no sense,
* netlink wouldn't bring any advantage over ioctl() for these cases
(and ppp is ioctl-centric anyway, so users will have to write
ioctl() calls no matter what).
If there was a bright future for ppp in sight, I'd certainly work on a
new modern ioctl-less api. But in the current situation, that'd be just
feature duplication and code churn.
So in the end you can use RTM_NEWLINK and then control ppp via ioctls.
And for controlling you have to known that ppp unit id.
If you are using ppp over serial devices, you can "simplify" it by
forcing mapping that serial number device matches ppp unit id. And then
you do not have to use dynamic ids (and need for call PPPIOCGUNIT).
How is dropping a single PPPIOCGUNIT call going to simplify the code
while you have to write netlink message handlers?
With dynamic unit id allocation (which is currently the only option when
creating ppp via rtnl) for single ppp connection you need to know:
* id of serial tty device
* id of channel bound to tty device
* id of network interface
* id of ppp unit bound to network interface
I see you're not working with L2TPv2 :). A few more things you'd need
to add to the list:
* a UDP socket,
* a tunnel id,
* a session id,
* a tunnel file descriptor,
* a session file descriptor,
* a new ioctl() to figure out which channel id is assigned to your
L2TP session,
* a bunch of setsockopt() to configure the whole thing,
* ...
(and I'm not counting the ioctl() calls necessary to set up the channel,
which also apply to your use case).
Really, I'm sorry, but the possibility to drop a single PPPIOCGUNIT
call isn't going to simplify the ppp landscape.
quoted
As I already proposed, we can add an attribute to make the interface
name independant from the unit id.
I agree, that above proposal with a new attribute which makes interface
name independent from the ppp unit id is a good idea. Probably it should
have been default rtnl behavior (but now it is too late for changing
default behavior).
Well, it was the default, until a collegue complained and I accepted to
align the default device name with the original ioctl() behaviour. But
the beauty of netlink is that we can revise this behaviour without
breaking compatibility.
But prior adding this attribute, we first need a way how to retrieve
interface name of newly created interface. Which we agreed that
NLM_F_ECHO for RTM_NEWLINK/NLM_F_CREATE is needed.
Yes, that'd be ideal. That might require quite some work though (I
haven't looked in detail). At last resort, if adding NLM_F_ECHO
support to rtnl proves too hard, it might be possible to add a call to
get the device name associated to a ppp unit file descriptor.
At least know I understand why we had this conversation about
NLM_F_ECHO :).