On Tuesday 10 August 2021 16:38:32 Chris Fowler wrote:
Isn't the UNIT ID the interface number? As in 'unit 100' will give me ppp100?
If you do not specify pppd 'ifname' argument then pppd argument 'unit 100'
will cause that interface name would be ppp100.
But you are free to rename interface to any string which you like, even
to "ppp99".
But this ppp unit id is not interface number. Interface number is
another number which has nothing with ppp unit id and is assigned to
every network interface (even loopback). You can see them as the first
number in 'ip -o l' output. Or you can retrieve it via if_nametoindex()
function in C.
... So if people are really using pppd's 'unit' argument then I think it
really make sense to support it also in new rtnl interface.
I have it running on over 1000 interfaces. I use PPP in a P-t-P VPN scenario between a central server and remote network devices. Iuse the unit id to identify a primary key in a database for that connection. This is calculated as 1000+N = UNIT ID.
I use 1000 because I've also used PPP on the same system with modem boards for demand dial PPP connections. The up and down scripts executed by PPP are written in C and allow a system where if the VPN link is down, the remote can dial and obtain the same IP addressing via modem. We don't use modems that often now due to reliability issues. It has been harder obtaining clean lines in the US.
The C program also applies routes that are defined in the database. That search is based on the IP assigned, not the unit id.
Chris
________________________________
From: Guillaume Nault <redacted>
Sent: Tuesday, August 10, 2021 11:39 AM
To: Pali Rohár <pali@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>; Paul Mackerras <redacted>; David S. Miller <davem@davemloft.net>; linux-ppp@vger.kernel.org <redacted>; netdev@vger.kernel.org <redacted>; linux-kernel@vger.kernel.org <redacted>
Subject: Re: [PATCH] ppp: Add rtnl attribute IFLA_PPP_UNIT_ID for specifying ppp unit id
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 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.
From: James Carlson <hidden> Date: 2021-08-10 18:45:23
On 8/10/21 1:16 PM, Pali Rohár wrote:
On Tuesday 10 August 2021 16:38:32 Chris Fowler wrote:
quoted
Isn't the UNIT ID the interface number? As in 'unit 100' will give me ppp100?
If you do not specify pppd 'ifname' argument then pppd argument 'unit 100'
will cause that interface name would be ppp100.
But you are free to rename interface to any string which you like, even
to "ppp99".
But this ppp unit id is not interface number. Interface number is
another number which has nothing with ppp unit id and is assigned to
every network interface (even loopback). You can see them as the first
number in 'ip -o l' output. Or you can retrieve it via if_nametoindex()
function in C.
Correct; completely unrelated to the notion of "interface index."
... So if people are really using pppd's 'unit' argument then I think it
really make sense to support it also in new rtnl interface.
The pppd source base is old. It dates to the mid-80's. So it predates
not just rename-able interfaces in Linux but Linux itself.
I recall supported platforms in the past (BSD-derived) that didn't
support allowing the user to specify the unit number. In general, on
those platforms, the option was accepted and just ignored, and there
were either release notes or man page updates (on that platform) that
indicated that "unit N" wouldn't work there.
Are there users on Linux who make use of the "unit" option and who would
mourn its loss? Nobody really knows. It's an ancient feature that was
originally intended to deal with systems that couldn't rename interfaces
(where one had to make sure that the actual interface selected matched
up with pre-configured filtering rules or static routes or the like),
and to make life nice for administrators (e.g., making sure that serial
port 1 maps to ppp1, port 2 is ppp2, and so on).
I would think and hope most users reach for the more-flexible "ifname"
option first, but I certainly can't guarantee it. It could be buried in
a script somewhere or (god forbid) some kind of GUI or "usability" tool.
If I were back at Sun, I'd probably call it suitable only for a "Major"
release, as it removes a publicly documented feature. But I don't know
what the considerations are here. Maybe it's just a "don't really care."
--
James Carlson 42.703N 71.076W [off-list ref]
On Tue, Aug 10, 2021 at 02:11:11PM -0400, James Carlson wrote:
On 8/10/21 1:16 PM, Pali Rohár wrote:
quoted
On Tuesday 10 August 2021 16:38:32 Chris Fowler wrote:
quoted
Isn't the UNIT ID the interface number? As in 'unit 100' will give me ppp100?
If you do not specify pppd 'ifname' argument then pppd argument 'unit 100'
will cause that interface name would be ppp100.
But you are free to rename interface to any string which you like, even
to "ppp99".
But this ppp unit id is not interface number. Interface number is
another number which has nothing with ppp unit id and is assigned to
every network interface (even loopback). You can see them as the first
number in 'ip -o l' output. Or you can retrieve it via if_nametoindex()
function in C.
Correct; completely unrelated to the notion of "interface index."
quoted
... So if people are really using pppd's 'unit' argument then I think it
really make sense to support it also in new rtnl interface.
The pppd source base is old. It dates to the mid-80's. So it predates not
just rename-able interfaces in Linux but Linux itself.
I recall supported platforms in the past (BSD-derived) that didn't support
allowing the user to specify the unit number. In general, on those
platforms, the option was accepted and just ignored, and there were either
release notes or man page updates (on that platform) that indicated that
"unit N" wouldn't work there.
Are there users on Linux who make use of the "unit" option and who would
mourn its loss? Nobody really knows. It's an ancient feature that was
originally intended to deal with systems that couldn't rename interfaces
(where one had to make sure that the actual interface selected matched up
with pre-configured filtering rules or static routes or the like), and to
make life nice for administrators (e.g., making sure that serial port 1 maps
to ppp1, port 2 is ppp2, and so on).
I would think and hope most users reach for the more-flexible "ifname"
option first, but I certainly can't guarantee it. It could be buried in a
script somewhere or (god forbid) some kind of GUI or "usability" tool.
If I were back at Sun, I'd probably call it suitable only for a "Major"
release, as it removes a publicly documented feature. But I don't know what
the considerations are here. Maybe it's just a "don't really care."
I'm pretty sure someone, somewhere, would hate us if we broke the
"unit" option. The old PPP ioctl API has been there for so long,
there certainly remains tons of old tools, scripts and config files
that "just work" without anybody left to debug or upgrade them.
We can't just say, "starting from kernel x.y.z the unit option is a
noop, use ifname instead" as affected people surely won't get the
message (and there are other tools beyond pppd that may use this
kernel API).
But for the netlink API, we don't have to repeat the same mistake.
On Wednesday 11 August 2021 19:38:11 Guillaume Nault wrote:
On Tue, Aug 10, 2021 at 02:11:11PM -0400, James Carlson wrote:
quoted
On 8/10/21 1:16 PM, Pali Rohár wrote:
quoted
On Tuesday 10 August 2021 16:38:32 Chris Fowler wrote:
quoted
Isn't the UNIT ID the interface number? As in 'unit 100' will give me ppp100?
If you do not specify pppd 'ifname' argument then pppd argument 'unit 100'
will cause that interface name would be ppp100.
But you are free to rename interface to any string which you like, even
to "ppp99".
But this ppp unit id is not interface number. Interface number is
another number which has nothing with ppp unit id and is assigned to
every network interface (even loopback). You can see them as the first
number in 'ip -o l' output. Or you can retrieve it via if_nametoindex()
function in C.
Correct; completely unrelated to the notion of "interface index."
quoted
... So if people are really using pppd's 'unit' argument then I think it
really make sense to support it also in new rtnl interface.
The pppd source base is old. It dates to the mid-80's. So it predates not
just rename-able interfaces in Linux but Linux itself.
I recall supported platforms in the past (BSD-derived) that didn't support
allowing the user to specify the unit number. In general, on those
platforms, the option was accepted and just ignored, and there were either
release notes or man page updates (on that platform) that indicated that
"unit N" wouldn't work there.
Are there users on Linux who make use of the "unit" option and who would
mourn its loss? Nobody really knows. It's an ancient feature that was
originally intended to deal with systems that couldn't rename interfaces
(where one had to make sure that the actual interface selected matched up
with pre-configured filtering rules or static routes or the like), and to
make life nice for administrators (e.g., making sure that serial port 1 maps
to ppp1, port 2 is ppp2, and so on).
I would think and hope most users reach for the more-flexible "ifname"
option first, but I certainly can't guarantee it. It could be buried in a
script somewhere or (god forbid) some kind of GUI or "usability" tool.
If I were back at Sun, I'd probably call it suitable only for a "Major"
release, as it removes a publicly documented feature. But I don't know what
the considerations are here. Maybe it's just a "don't really care."
I'm pretty sure someone, somewhere, would hate us if we broke the
"unit" option. The old PPP ioctl API has been there for so long,
there certainly remains tons of old tools, scripts and config files
that "just work" without anybody left to debug or upgrade them.
We can't just say, "starting from kernel x.y.z the unit option is a
noop, use ifname instead" as affected people surely won't get the
message (and there are other tools beyond pppd that may use this
kernel API).
But for the netlink API, we don't have to repeat the same mistake.
ifname is not atomic (first it creates ppp<id> interface and later it is
renamed) and have issues. Due to bug described here:
https://lore.kernel.org/netdev/20210807160050.17687-1-pali@kernel.org/
you may get your kernel into state in which it is not possible to create
a new ppp interface. And this issue does not happen when using "unit"
argument.
To fix above issue it is needed to migrate pppd from ioctl API to rtnl.
But this would be possible only after rtnl API starts providing all
features, including specifying custom "unit" argument...
I hit above problem, so now I'm migrating all pppd setups from "ifname"
to "unit" option.
On Wed, Aug 11, 2021 at 08:04:01PM +0200, Pali Rohár wrote:
On Wednesday 11 August 2021 19:38:11 Guillaume Nault wrote:
quoted
On Tue, Aug 10, 2021 at 02:11:11PM -0400, James Carlson wrote:
quoted
On 8/10/21 1:16 PM, Pali Rohár wrote:
quoted
On Tuesday 10 August 2021 16:38:32 Chris Fowler wrote:
quoted
Isn't the UNIT ID the interface number? As in 'unit 100' will give me ppp100?
If you do not specify pppd 'ifname' argument then pppd argument 'unit 100'
will cause that interface name would be ppp100.
But you are free to rename interface to any string which you like, even
to "ppp99".
But this ppp unit id is not interface number. Interface number is
another number which has nothing with ppp unit id and is assigned to
every network interface (even loopback). You can see them as the first
number in 'ip -o l' output. Or you can retrieve it via if_nametoindex()
function in C.
Correct; completely unrelated to the notion of "interface index."
quoted
... So if people are really using pppd's 'unit' argument then I think it
really make sense to support it also in new rtnl interface.
The pppd source base is old. It dates to the mid-80's. So it predates not
just rename-able interfaces in Linux but Linux itself.
I recall supported platforms in the past (BSD-derived) that didn't support
allowing the user to specify the unit number. In general, on those
platforms, the option was accepted and just ignored, and there were either
release notes or man page updates (on that platform) that indicated that
"unit N" wouldn't work there.
Are there users on Linux who make use of the "unit" option and who would
mourn its loss? Nobody really knows. It's an ancient feature that was
originally intended to deal with systems that couldn't rename interfaces
(where one had to make sure that the actual interface selected matched up
with pre-configured filtering rules or static routes or the like), and to
make life nice for administrators (e.g., making sure that serial port 1 maps
to ppp1, port 2 is ppp2, and so on).
I would think and hope most users reach for the more-flexible "ifname"
option first, but I certainly can't guarantee it. It could be buried in a
script somewhere or (god forbid) some kind of GUI or "usability" tool.
If I were back at Sun, I'd probably call it suitable only for a "Major"
release, as it removes a publicly documented feature. But I don't know what
the considerations are here. Maybe it's just a "don't really care."
I'm pretty sure someone, somewhere, would hate us if we broke the
"unit" option. The old PPP ioctl API has been there for so long,
there certainly remains tons of old tools, scripts and config files
that "just work" without anybody left to debug or upgrade them.
We can't just say, "starting from kernel x.y.z the unit option is a
noop, use ifname instead" as affected people surely won't get the
message (and there are other tools beyond pppd that may use this
kernel API).
But for the netlink API, we don't have to repeat the same mistake.
ifname is not atomic (first it creates ppp<id> interface and later it is
renamed) and have issues. Due to bug described here:
https://lore.kernel.org/netdev/20210807160050.17687-1-pali@kernel.org/
you may get your kernel into state in which it is not possible to create
a new ppp interface. And this issue does not happen when using "unit"
argument.
This is specific to the ioctl api. Netlink doesn't have this problem.
To fix above issue it is needed to migrate pppd from ioctl API to rtnl.
It would have helped a lot if you had explained that before.
But this would be possible only after rtnl API starts providing all
features, including specifying custom "unit" argument...
You can already simulate the "unit" option by setting the interface
name as "ppp${unit}" and retrieving the kernel assigned id with
ioctl(PPPIOCGUNIT). What's wrong with that?
I hit above problem, so now I'm migrating all pppd setups from "ifname"
to "unit" option.
Why did you write 3125f26c51482 ("ppp: Fix generating ppp unit id when
ifname is not specified") then?
On Thursday 12 August 2021 11:28:47 Guillaume Nault wrote:
On Wed, Aug 11, 2021 at 08:04:01PM +0200, Pali Rohár wrote:
quoted
On Wednesday 11 August 2021 19:38:11 Guillaume Nault wrote:
quoted
On Tue, Aug 10, 2021 at 02:11:11PM -0400, James Carlson wrote:
quoted
On 8/10/21 1:16 PM, Pali Rohár wrote:
quoted
On Tuesday 10 August 2021 16:38:32 Chris Fowler wrote:
quoted
Isn't the UNIT ID the interface number? As in 'unit 100' will give me ppp100?
If you do not specify pppd 'ifname' argument then pppd argument 'unit 100'
will cause that interface name would be ppp100.
But you are free to rename interface to any string which you like, even
to "ppp99".
But this ppp unit id is not interface number. Interface number is
another number which has nothing with ppp unit id and is assigned to
every network interface (even loopback). You can see them as the first
number in 'ip -o l' output. Or you can retrieve it via if_nametoindex()
function in C.
Correct; completely unrelated to the notion of "interface index."
quoted
... So if people are really using pppd's 'unit' argument then I think it
really make sense to support it also in new rtnl interface.
The pppd source base is old. It dates to the mid-80's. So it predates not
just rename-able interfaces in Linux but Linux itself.
I recall supported platforms in the past (BSD-derived) that didn't support
allowing the user to specify the unit number. In general, on those
platforms, the option was accepted and just ignored, and there were either
release notes or man page updates (on that platform) that indicated that
"unit N" wouldn't work there.
Are there users on Linux who make use of the "unit" option and who would
mourn its loss? Nobody really knows. It's an ancient feature that was
originally intended to deal with systems that couldn't rename interfaces
(where one had to make sure that the actual interface selected matched up
with pre-configured filtering rules or static routes or the like), and to
make life nice for administrators (e.g., making sure that serial port 1 maps
to ppp1, port 2 is ppp2, and so on).
I would think and hope most users reach for the more-flexible "ifname"
option first, but I certainly can't guarantee it. It could be buried in a
script somewhere or (god forbid) some kind of GUI or "usability" tool.
If I were back at Sun, I'd probably call it suitable only for a "Major"
release, as it removes a publicly documented feature. But I don't know what
the considerations are here. Maybe it's just a "don't really care."
I'm pretty sure someone, somewhere, would hate us if we broke the
"unit" option. The old PPP ioctl API has been there for so long,
there certainly remains tons of old tools, scripts and config files
that "just work" without anybody left to debug or upgrade them.
We can't just say, "starting from kernel x.y.z the unit option is a
noop, use ifname instead" as affected people surely won't get the
message (and there are other tools beyond pppd that may use this
kernel API).
But for the netlink API, we don't have to repeat the same mistake.
ifname is not atomic (first it creates ppp<id> interface and later it is
renamed) and have issues. Due to bug described here:
https://lore.kernel.org/netdev/20210807160050.17687-1-pali@kernel.org/
you may get your kernel into state in which it is not possible to create
a new ppp interface. And this issue does not happen when using "unit"
argument.
This is specific to the ioctl api. Netlink doesn't have this problem.
netlink does not have problem with implementing ifname option
atomically. That is why I started looking at netlink how to avoid
problems with renaming. As on some systems I see that some udev rules or
NetworkManager tries to query newly created interfaces, but based on
name (not id). So early renaming cause issues to these tools...
But netlink is affected by above bug when "ifname" is not specified.
quoted
To fix above issue it is needed to migrate pppd from ioctl API to rtnl.
It would have helped a lot if you had explained that before.
quoted
But this would be possible only after rtnl API starts providing all
features, including specifying custom "unit" argument...
You can already simulate the "unit" option by setting the interface
name as "ppp${unit}" and retrieving the kernel assigned id with
ioctl(PPPIOCGUNIT). What's wrong with that?
This is possible to implement. But then unit part from "ppp${unit}"
would not match PPPIOCGUNIT number - like it is currently. And it is
something which applications expect. Basically there is no difference
between ppp interface created by ioctl and ppp interface created by
rtnl. You can use other rtnl commands on ppp interface created by ioctl
and also you can use other ppp ioctls on ppp interface created by rtnl.
But I understand your arguments. You are looking at ppp unit id as some
internal kernel number; which should probably stay in kernel.
My point of view is that this is legacy identifier bound to the every
ppp network interface, and which is exported to userspace. And because
there is API for userspace how userspace can force particular id for
particular ppp interface, it means that userspace have full control how
these ids are generated. Even it is "internal" kernel number. And it
does not matter how are ppp interfaces created, via which method. It is
bounded to every ppp interface independently how ppp was created.
By this design, userspace application may choose to create mapping
between /dev/ttyUSB<N> and ppp unit <id> by having <N> == <id>.
This ppp unit id is used for some operations, so it is required to know
it. And if application is doing e.g. above assumption (it does not use
PPPIOCGUNIT, but derive ppp unit id from /dev/ttyUSB* name) which
current ioctl API allows, then this application cannot be migrated from
ioctl to rtnl API without rewriting code which uses above assumption.
I'm not saying if this is a good or bad idea, just I'm describing what
ioctl API allows and what does not. (And yes, in my opinion it is a bad
idea, but ppp is designed to allow it).
If I was designing ppp again, I would have probably used interface id as
ppp unit id...
quoted
I hit above problem, so now I'm migrating all pppd setups from "ifname"
to "unit" option.
Why did you write 3125f26c51482 ("ppp: Fix generating ppp unit id when
ifname is not specified") then?
Well, I hope that this kernel fix propagates into kernels used on
affected machines. But it will take some time. And until it happens this
migration is needed. Lets say it is workaround for unspecific time
period.
On Thu, Aug 12, 2021 at 03:48:45PM +0200, Pali Rohár wrote:
On Thursday 12 August 2021 11:28:47 Guillaume Nault wrote:
quoted
On Wed, Aug 11, 2021 at 08:04:01PM +0200, Pali Rohár wrote:
quoted
ifname is not atomic (first it creates ppp<id> interface and later it is
renamed) and have issues. Due to bug described here:
https://lore.kernel.org/netdev/20210807160050.17687-1-pali@kernel.org/
you may get your kernel into state in which it is not possible to create
a new ppp interface. And this issue does not happen when using "unit"
argument.
This is specific to the ioctl api. Netlink doesn't have this problem.
netlink does not have problem with implementing ifname option
atomically. That is why I started looking at netlink how to avoid
problems with renaming. As on some systems I see that some udev rules or
NetworkManager tries to query newly created interfaces, but based on
name (not id). So early renaming cause issues to these tools...
But netlink is affected by above bug when "ifname" is not specified.
As disscussed in another part of the thread, let's fix that with a new
netlink attribute.
quoted
quoted
To fix above issue it is needed to migrate pppd from ioctl API to rtnl.
It would have helped a lot if you had explained that before.
quoted
But this would be possible only after rtnl API starts providing all
features, including specifying custom "unit" argument...
You can already simulate the "unit" option by setting the interface
name as "ppp${unit}" and retrieving the kernel assigned id with
ioctl(PPPIOCGUNIT). What's wrong with that?
This is possible to implement. But then unit part from "ppp${unit}"
would not match PPPIOCGUNIT number - like it is currently. And it is
something which applications expect. Basically there is no difference
between ppp interface created by ioctl and ppp interface created by
rtnl. You can use other rtnl commands on ppp interface created by ioctl
and also you can use other ppp ioctls on ppp interface created by rtnl.
But the application knows if it created the ppp device with a specified
unit id or not. So it knows if an ioctl(PPPIOCGUNIT) call is necessary
to get the unit id. And if we allow the interface name to be unrelated
to the unit id, the application will also know that, because it
explicitely requested it.
But I understand your arguments. You are looking at ppp unit id as some
internal kernel number; which should probably stay in kernel.
Well, it has to be exported, but it should be opaque to user space
(appart from the ioctl() api which is established behaviour).
My point of view is that this is legacy identifier bound to the every
ppp network interface, and which is exported to userspace. And because
there is API for userspace how userspace can force particular id for
particular ppp interface, it means that userspace have full control how
these ids are generated. Even it is "internal" kernel number. And it
does not matter how are ppp interfaces created, via which method. It is
bounded to every ppp interface independently how ppp was created.
By this design, userspace application may choose to create mapping
between /dev/ttyUSB<N> and ppp unit <id> by having <N> == <id>.
This ppp unit id is used for some operations, so it is required to know
it. And if application is doing e.g. above assumption (it does not use
PPPIOCGUNIT, but derive ppp unit id from /dev/ttyUSB* name) which
current ioctl API allows, then this application cannot be migrated from
ioctl to rtnl API without rewriting code which uses above assumption.
Migrating such application requires writing the netlink code for the new
api. How could a simple ioctl(PPPIOCGUNIT) call prevent such migration?
BTW, using PPPIOCGUNIT is much cleaner an more robust that parsing the
device name, so it's a win in any case. And the application is still
able to name the ppp interface ppp<N> to keep things simple for its
users.
I'm not saying if this is a good or bad idea, just I'm describing what
ioctl API allows and what does not. (And yes, in my opinion it is a bad
idea, but ppp is designed to allow it).
If I was designing ppp again, I would have probably used interface id as
ppp unit id...
With all the building blocks we have now in the Linux kernel, there's
much more that I'd change. But the landscape and constraints were
obviously very different at the time.
quoted
quoted
I hit above problem, so now I'm migrating all pppd setups from "ifname"
to "unit" option.
Why did you write 3125f26c51482 ("ppp: Fix generating ppp unit id when
ifname is not specified") then?
Well, I hope that this kernel fix propagates into kernels used on
affected machines. But it will take some time. And until it happens this
migration is needed. Lets say it is workaround for unspecific time
period.
On Thursday 12 August 2021 20:26:45 Guillaume Nault wrote:
On Thu, Aug 12, 2021 at 03:48:45PM +0200, Pali Rohár wrote:
quoted
On Thursday 12 August 2021 11:28:47 Guillaume Nault wrote:
quoted
On Wed, Aug 11, 2021 at 08:04:01PM +0200, Pali Rohár wrote:
quoted
ifname is not atomic (first it creates ppp<id> interface and later it is
renamed) and have issues. Due to bug described here:
https://lore.kernel.org/netdev/20210807160050.17687-1-pali@kernel.org/
you may get your kernel into state in which it is not possible to create
a new ppp interface. And this issue does not happen when using "unit"
argument.
This is specific to the ioctl api. Netlink doesn't have this problem.
netlink does not have problem with implementing ifname option
atomically. That is why I started looking at netlink how to avoid
problems with renaming. As on some systems I see that some udev rules or
NetworkManager tries to query newly created interfaces, but based on
name (not id). So early renaming cause issues to these tools...
But netlink is affected by above bug when "ifname" is not specified.
As disscussed in another part of the thread, let's fix that with a new
netlink attribute.
+1
quoted
quoted
quoted
To fix above issue it is needed to migrate pppd from ioctl API to rtnl.
It would have helped a lot if you had explained that before.
quoted
But this would be possible only after rtnl API starts providing all
features, including specifying custom "unit" argument...
You can already simulate the "unit" option by setting the interface
name as "ppp${unit}" and retrieving the kernel assigned id with
ioctl(PPPIOCGUNIT). What's wrong with that?
This is possible to implement. But then unit part from "ppp${unit}"
would not match PPPIOCGUNIT number - like it is currently. And it is
something which applications expect. Basically there is no difference
between ppp interface created by ioctl and ppp interface created by
rtnl. You can use other rtnl commands on ppp interface created by ioctl
and also you can use other ppp ioctls on ppp interface created by rtnl.
But the application knows if it created the ppp device with a specified
unit id or not. So it knows if an ioctl(PPPIOCGUNIT) call is necessary
to get the unit id. And if we allow the interface name to be unrelated
to the unit id, the application will also know that, because it
explicitely requested it.
quoted
But I understand your arguments. You are looking at ppp unit id as some
internal kernel number; which should probably stay in kernel.
Well, it has to be exported, but it should be opaque to user space
(appart from the ioctl() api which is established behaviour).
quoted
My point of view is that this is legacy identifier bound to the every
ppp network interface, and which is exported to userspace. And because
there is API for userspace how userspace can force particular id for
particular ppp interface, it means that userspace have full control how
these ids are generated. Even it is "internal" kernel number. And it
does not matter how are ppp interfaces created, via which method. It is
bounded to every ppp interface independently how ppp was created.
By this design, userspace application may choose to create mapping
between /dev/ttyUSB<N> and ppp unit <id> by having <N> == <id>.
This ppp unit id is used for some operations, so it is required to know
it. And if application is doing e.g. above assumption (it does not use
PPPIOCGUNIT, but derive ppp unit id from /dev/ttyUSB* name) which
current ioctl API allows, then this application cannot be migrated from
ioctl to rtnl API without rewriting code which uses above assumption.
Migrating such application requires writing the netlink code for the new
api. How could a simple ioctl(PPPIOCGUNIT) call prevent such migration?
BTW, using PPPIOCGUNIT is much cleaner an more robust that parsing the
device name, so it's a win in any case. And the application is still
able to name the ppp interface ppp<N> to keep things simple for its
users.
You are right and I agree with you that application with PPPIOCGUNIT is
more robust.
The point here is that there is application (pppd) which allows
specifying custom unit id as an option argument. Also it allows to call
external applications (at some events) with sharing file descriptors.
And it is one of the options how to touch part of ppp connection via
external scripts / applications. You start pppd for /dev/ttyUSB<N> with
unit id <N> and then in external script you use <N> for ioctls. And I do
not know if there is a way how to retrieve unit id in those external
scripts. There was already discussion about marking all file descriptors
in pppd as close-on-exec and it was somehow rejected as it will broke
custom scripts / applications which pppd invokes on events. So looks
like that people are using these "features" of pppd.
Option "unit" in pppd specifies ppp unit id. And if new API (rtnl) would
not provide equivalent for allowing to specify it then migrating pppd
from ioctl to rtnl is not possible without breaking compatibility.
As you already described, we can simulate setting default interface name
in pppd application. But above usage or any other which expose pppd API
to other application is not possible to simulate.
So I think we need to first decide or solve issue if rtnl ppp API should
provide same functionality as ioctl ppp API. If answer is yes, then some
kind of specifying custom ppp unit id is required. If answer is no (e.g.
because we do not want ppp unit id in rtnl API as it looks legacy and
has issues) then rtnl ppp API cannot be used by ppp as it cannot provide
all existing / supported features without breaking legacy compatibility.
I see pros & cons for both answers. Not supporting legacy code paths in
new code/API is the way how to clean up code and prevent repeating old
historic issues. But if new code/API is not fully suitable for pppd --
which is de-facto standard Linux userspace implementation -- does it
make sense to have it? Or does it mean to also implement new userspace
part of implementation (e.g. pppd2) to avoid these legacy / historic
issues? Or... is not whole ppp protocol just legacy part of our history
which should not be used in new modern setups? And for "legacy usage" is
current implementation enough and it does not make sense to invest time
into this area? I cannot answer to these questions, but I think it is
something quite important as it can show what should be direction and
future of ppp subsystem.
quoted
I'm not saying if this is a good or bad idea, just I'm describing what
ioctl API allows and what does not. (And yes, in my opinion it is a bad
idea, but ppp is designed to allow it).
If I was designing ppp again, I would have probably used interface id as
ppp unit id...
With all the building blocks we have now in the Linux kernel, there's
much more that I'd change. But the landscape and constraints were
obviously very different at the time.
quoted
quoted
quoted
I hit above problem, so now I'm migrating all pppd setups from "ifname"
to "unit" option.
Why did you write 3125f26c51482 ("ppp: Fix generating ppp unit id when
ifname is not specified") then?
Well, I hope that this kernel fix propagates into kernels used on
affected machines. But it will take some time. And until it happens this
migration is needed. Lets say it is workaround for unspecific time
period.
On Thu, Aug 12, 2021 at 09:04:40PM +0200, Pali Rohár wrote:
The point here is that there is application (pppd) which allows
specifying custom unit id as an option argument. Also it allows to call
external applications (at some events) with sharing file descriptors.
And it is one of the options how to touch part of ppp connection via
external scripts / applications. You start pppd for /dev/ttyUSB<N> with
unit id <N> and then in external script you use <N> for ioctls. And I do
not know if there is a way how to retrieve unit id in those external
scripts. There was already discussion about marking all file descriptors
in pppd as close-on-exec and it was somehow rejected as it will broke
custom scripts / applications which pppd invokes on events. So looks
like that people are using these "features" of pppd.
Potential external pppd scripts, that depend on the unit id, may be a
valid use case for letting the netlink api define this identifier (if
pppd ever gets netlink support).
Option "unit" in pppd specifies ppp unit id. And if new API (rtnl) would
not provide equivalent for allowing to specify it then migrating pppd
from ioctl to rtnl is not possible without breaking compatibility.
As you already described, we can simulate setting default interface name
in pppd application. But above usage or any other which expose pppd API
to other application is not possible to simulate.
If the pppd project is interested in adding support for the netlink
api, then I'm fine with adding this feature. I just want to make sure
that it'll have a real world use case.
So I think we need to first decide or solve issue if rtnl ppp API should
provide same functionality as ioctl ppp API. If answer is yes, then some
kind of specifying custom ppp unit id is required. If answer is no (e.g.
because we do not want ppp unit id in rtnl API as it looks legacy and
has issues) then rtnl ppp API cannot be used by ppp as it cannot provide
all existing / supported features without breaking legacy compatibility.
I see pros & cons for both answers. Not supporting legacy code paths in
new code/API is the way how to clean up code and prevent repeating old
historic issues. But if new code/API is not fully suitable for pppd --
which is de-facto standard Linux userspace implementation -- does it
make sense to have it? Or does it mean to also implement new userspace
part of implementation (e.g. pppd2) to avoid these legacy / historic
issues? Or... is not whole ppp protocol just legacy part of our history
which should not be used in new modern setups? And for "legacy usage" is
current implementation enough and it does not make sense to invest time
into this area? I cannot answer to these questions, but I think it is
something quite important as it can show what should be direction and
future of ppp subsystem.
PPP isn't legacy, but very few people are interested in working on and
maintaining the code.
Do you have plans for adding netlink support to pppd? If so, is the
project ready to accept such code?
BTW, sorry for the delay.
On Monday 16 August 2021 18:11:14 Guillaume Nault wrote:
On Thu, Aug 12, 2021 at 09:04:40PM +0200, Pali Rohár wrote:
quoted
The point here is that there is application (pppd) which allows
specifying custom unit id as an option argument. Also it allows to call
external applications (at some events) with sharing file descriptors.
And it is one of the options how to touch part of ppp connection via
external scripts / applications. You start pppd for /dev/ttyUSB<N> with
unit id <N> and then in external script you use <N> for ioctls. And I do
not know if there is a way how to retrieve unit id in those external
scripts. There was already discussion about marking all file descriptors
in pppd as close-on-exec and it was somehow rejected as it will broke
custom scripts / applications which pppd invokes on events. So looks
like that people are using these "features" of pppd.
Potential external pppd scripts, that depend on the unit id, may be a
valid use case for letting the netlink api define this identifier (if
pppd ever gets netlink support).
quoted
Option "unit" in pppd specifies ppp unit id. And if new API (rtnl) would
not provide equivalent for allowing to specify it then migrating pppd
from ioctl to rtnl is not possible without breaking compatibility.
As you already described, we can simulate setting default interface name
in pppd application. But above usage or any other which expose pppd API
to other application is not possible to simulate.
If the pppd project is interested in adding support for the netlink
api, then I'm fine with adding this feature. I just want to make sure
that it'll have a real world use case.
quoted
So I think we need to first decide or solve issue if rtnl ppp API should
provide same functionality as ioctl ppp API. If answer is yes, then some
kind of specifying custom ppp unit id is required. If answer is no (e.g.
because we do not want ppp unit id in rtnl API as it looks legacy and
has issues) then rtnl ppp API cannot be used by ppp as it cannot provide
all existing / supported features without breaking legacy compatibility.
I see pros & cons for both answers. Not supporting legacy code paths in
new code/API is the way how to clean up code and prevent repeating old
historic issues. But if new code/API is not fully suitable for pppd --
which is de-facto standard Linux userspace implementation -- does it
make sense to have it? Or does it mean to also implement new userspace
part of implementation (e.g. pppd2) to avoid these legacy / historic
issues? Or... is not whole ppp protocol just legacy part of our history
which should not be used in new modern setups? And for "legacy usage" is
current implementation enough and it does not make sense to invest time
into this area? I cannot answer to these questions, but I think it is
something quite important as it can show what should be direction and
future of ppp subsystem.
PPP isn't legacy, but very few people are interested in working on and
maintaining the code.
Do you have plans for adding netlink support to pppd? If so, is the
project ready to accept such code?
Yes, I have already some WIP code and I'm planning to send a pull
request to pppd on github for it. I guess that it could be accepted,
specially if there still would be backward compatibility via ioctl for
kernels which do not support rtnl API. One of the argument which can be
used why rtnl API is better, is fixing issue: atomic creating of
interface with specific name.
But pppd is maintained by Paul (already in loop), so I hope we could
hear some feedback.
On Mon, Aug 16, 2021 at 06:23:55PM +0200, Pali Rohár wrote:
On Monday 16 August 2021 18:11:14 Guillaume Nault wrote:
quoted
Do you have plans for adding netlink support to pppd? If so, is the
project ready to accept such code?
Yes, I have already some WIP code and I'm planning to send a pull
request to pppd on github for it. I guess that it could be accepted,
I guess you can easily use the netlink api for cases where the "unit"
option isn't specified and fall back to the ioctl api when it is. If
all goes well, then we can extend the netlink api to accept a unit id.
But what about the lack of netlink feedback about the created
interface? Are you restricted to use netlink only when the "ifname"
option is provided?
specially if there still would be backward compatibility via ioctl for
kernels which do not support rtnl API.
Indeed, I'd expect keeping compatiblitity with old kernels that only
have the ioctl api to be a must (but I have no experience contributing
to the pppd project).
One of the argument which can be
used why rtnl API is better, is fixing issue: atomic creating of
interface with specific name.
On Tuesday 17 August 2021 18:05:25 Guillaume Nault wrote:
On Mon, Aug 16, 2021 at 06:23:55PM +0200, Pali Rohár wrote:
quoted
On Monday 16 August 2021 18:11:14 Guillaume Nault wrote:
quoted
Do you have plans for adding netlink support to pppd? If so, is the
project ready to accept such code?
Yes, I have already some WIP code and I'm planning to send a pull
request to pppd on github for it. I guess that it could be accepted,
I guess you can easily use the netlink api for cases where the "unit"
option isn't specified and fall back to the ioctl api when it is. If
all goes well, then we can extend the netlink api to accept a unit id.
But what about the lack of netlink feedback about the created
interface? Are you restricted to use netlink only when the "ifname"
option is provided?
Exactly, this is how I wrote my WIP code...
quoted
specially if there still would be backward compatibility via ioctl for
kernels which do not support rtnl API.
Indeed, I'd expect keeping compatiblitity with old kernels that only
have the ioctl api to be a must (but I have no experience contributing
to the pppd project).
quoted
One of the argument which can be
used why rtnl API is better, is fixing issue: atomic creating of
interface with specific name.
On Tuesday 17 August 2021 18:21:55 Pali Rohár wrote:
On Tuesday 17 August 2021 18:05:25 Guillaume Nault wrote:
quoted
On Mon, Aug 16, 2021 at 06:23:55PM +0200, Pali Rohár wrote:
quoted
On Monday 16 August 2021 18:11:14 Guillaume Nault wrote:
quoted
Do you have plans for adding netlink support to pppd? If so, is the
project ready to accept such code?
Yes, I have already some WIP code and I'm planning to send a pull
request to pppd on github for it. I guess that it could be accepted,
I guess you can easily use the netlink api for cases where the "unit"
option isn't specified and fall back to the ioctl api when it is. If
all goes well, then we can extend the netlink api to accept a unit id.
But what about the lack of netlink feedback about the created
interface? Are you restricted to use netlink only when the "ifname"
option is provided?
Exactly, this is how I wrote my WIP code...
Sorry for a long delay (I forgot about it). Now I created pull request
for pppd https://github.com/ppp-project/ppp/pull/354 which adds support
for creating ppp interface via rtnetlink. rtnetlink is used only when
ppp unit id was not provided and interface name was provided.
quoted
quoted
specially if there still would be backward compatibility via ioctl for
kernels which do not support rtnl API.
Indeed, I'd expect keeping compatiblitity with old kernels that only
have the ioctl api to be a must (but I have no experience contributing
to the pppd project).
quoted
One of the argument which can be
used why rtnl API is better, is fixing issue: atomic creating of
interface with specific name.
On Sat, Jul 09, 2022 at 02:09:06PM +0200, Pali Rohár wrote:
On Tuesday 17 August 2021 18:21:55 Pali Rohár wrote:
quoted
On Tuesday 17 August 2021 18:05:25 Guillaume Nault wrote:
quoted
On Mon, Aug 16, 2021 at 06:23:55PM +0200, Pali Rohár wrote:
quoted
On Monday 16 August 2021 18:11:14 Guillaume Nault wrote:
quoted
Do you have plans for adding netlink support to pppd? If so, is the
project ready to accept such code?
Yes, I have already some WIP code and I'm planning to send a pull
request to pppd on github for it. I guess that it could be accepted,
I guess you can easily use the netlink api for cases where the "unit"
option isn't specified and fall back to the ioctl api when it is. If
all goes well, then we can extend the netlink api to accept a unit id.
But what about the lack of netlink feedback about the created
interface? Are you restricted to use netlink only when the "ifname"
option is provided?
Exactly, this is how I wrote my WIP code...
Sorry for a long delay (I forgot about it). Now I created pull request
for pppd https://github.com/ppp-project/ppp/pull/354 which adds support
for creating ppp interface via rtnetlink. rtnetlink is used only when
ppp unit id was not provided and interface name was provided.
Interesting work. Thanks for working on it!
quoted
quoted
quoted
specially if there still would be backward compatibility via ioctl for
kernels which do not support rtnl API.
Indeed, I'd expect keeping compatiblitity with old kernels that only
have the ioctl api to be a must (but I have no experience contributing
to the pppd project).
quoted
One of the argument which can be
used why rtnl API is better, is fixing issue: atomic creating of
interface with specific name.