There's already code for that in our tree, it just needs be be finished off and made woking in networkd.

Excellent! Out of curiosity - what are the plans with regards to login:password for ppp? Is there some sort of http://standards.freedesktop.org/secret-service/ implementation in systemd?

@zabbal We do have a ppp protocol implementation, but no hookup in networkd. Furthermore, no-one is working on this. If you want this, you need to find someone to implement this. I doubt this will get finished anytime soon (there're even proposals to drop the now unused ppp protocol implementation again).

I guess we should close this bug, as I see little use in keeping long-lasting RFEs open. We have TODO for this. But I leave this to @teg.

I'm responsible for the PPP stuff we have so far. I think it is awesome, and love hacking on it. However, people are telling me that this is out of scope of systemd, and I have yet to find a good counterargument to this ("it is fun" seems not to cut it), so it may very well be that this code will not get anywhere. Until a final decision has been made, I'll still keep this on the TODO though, and I think we can close this issue, as it will not be resolved either way anytime soon i think...

people are telling me that this is out of scope of systemd, and I have yet to find a good counterargument to this

Out of curiosity, are there any arguments against having ppp inside systemd? Besides usual whining I mean :)

To me there is 0 difference from dhcp in here:

• there's a protocol on top of ethernet
• information obtained over it is absolutely crucial for interface setup (IP address etc)
• there are billions on systems relying on it

I don't see any major difference between DHCP ethernet frames or PPP ethernet frames in this case: in both case you've got to send/receive few before you can configure interface with proper IP address.

No particular reason against ppp as is, but against including it in systemd. It's importance is questionable in modern OSs.
On the other hand, we haven't worked on supporting external layer-2 modules, either. So this really needs to be discussed once someone start working on it.

It's importance is questionable in modern OSs.

As long as DSL remains popular PPPoE will be of paramount importance.

PPPoE is widely used by pure Ethernet providers, at least in my country; it is not directly related to DSL in any way.

I'm not questioning the importance of PPPoE as is, but whether it belongs into base of a general purpose OS.

Anyway, I don't see the point of discussing this here, as long as no-one commits to writing the code.

@dvdhrm there is no point in writing the code if it wont be accepted anyway. That's just waste of contributors time. You yourself should be quite familiar with that through your kdbus work so it needs to be clear before someone does decide to start working on that code that it will be included or it wont be included due to certain individuals having vague idea how a modern OS should look like or have a solid idea how a modern OS should look like but aren't sharing that idea with anyone or the whole picture of it so individuals cant determine if their contribution will matter in the end or it crosses the that invisible line that has been drawned of what an modern OS should look like.

I said "commits to writing the code", not "submits the code".

IIRC, there is no-one who is even willing to write it, so I see no point in discussing this.

The individual(s) that submit the code, already have committed to write that code so there is in essences no distinction and I thought Tom already expressed his will in committing to that code it but he has not done so because ( some ) people are discouraging him from doing so due to their own vision of how modern os should look like ( and there is no point for him or anyone else to do so until that final "in" or "out" decision has been made since he or anyone else might be wasting their contributed time in doing so if the "final" decision that will be made turns out to be "out").

Dont drag contributes confused on their ears in circles in the gray area forever because of the self dubbed cabal owns inability to make a clear cut in or out decisions, involving their own vision and lack of clarification where the line in the sand is being drawn in that vision and what they deem important or not important in relation to that since individuals don't see that difference or distinction here ( as is clear by zabbal comment ).

Grab a beer, throw a bbq and figure this out, eliminate this gray area, stand firmly behind whatever decision will be made, with clarifications and technical hard facts but dont do what you are doing here ( and by you I mean the self dubbed cabal ) since it leads to wasting everybody's time ( including yours ).

I had a similar issue, I just updated the systemd from mirror and then the IPv4 address of pppoe is lost and all IPv4 traffic is interrupted, but the traffic for IPv6 is fine, systemd version 252.12-1~deb12u1

My IPv6 stop working after IP change too.

This is because pppd try to call "/etc/sysconfig/network-scripts/ip-[up/down/etc...]" scripts, and I'm using fedora and systemd-networkd, these scripts has been removed, so IP change not reflect to interface.

I you have similar issue, you may want to edit scripts in /etc/ppp.

FYI @ all,
For a complete working setup using PPPoE see the above linked issue where i mentioned this thread to auto link it here...
Hope it will benefit some people 🤝

At colaborators: (@rfc1036 et all)
As you see it ain't THAT easy to get it to work without a little more help from systemd side...
Please consider adding at least an option to tell systemd the setup is for PPPoE and let systemd spawn pppd without us needing to write all those services etc i showed in the mentioned issue above...
(No need to implement the ppp protocol etc if you spawn a util right?)

eg. a good candidate would be a Kind=PPPoE mention in a netdev file, with a corresponding [PPPoE] section where the options to use could be setup...

ppp interface again stuck in "configuring" state after upgrading to Fedora 39 which comes with systemd-networkd 254.5.
It worked fine in Fedora 38 with either systemd-networkd 253.7 or 253.12.

[Match]
Type = ppp

[Network]
DHCP = ipv6
LLMNR = no
IPv6AcceptRA = no
KeepConfiguration = yes
DHCPPrefixDelegation = yes

[Link]
RequiredForOnline = yes

[DHCPv6]
UseDelegatedPrefix = yes
UseAddress = no
UseDNS = no

[DHCPPrefixDelegation]
UplinkInterface = :self
Assign = no

Error message: ppp0: link_check_ready(): DHCPv6 IA_PD prefix is assigned, but DHCPv6 protocol is not finished yet.

@yuwata regarding above comment, should I create a new issue, or reopen an existing one that was closed?

@pimzand Please open a new issue with debugging logs. Thank you.

#29979

To follow

Fixed in Fedora systemd-254.7-1.fc39

Can this issue be closed, then? Let's clean up!

This issue started as plea to have pppoe support built in to systemd-networkd, but has turned into a topic for sharing tips and tricks how to work around the fact that that support is missing. As such it is valuable, and it remains valuable because of the frequent changes that break the workarounds.

I would still think that native support would be a good idea. If there is native support for wireguard, then why not for pppoe. But if no one is going to contribute it, and developers are against it, then why not close this issue, and keep posting workaround tips and tricks?

The Wireguard protocol is all implemented in the kernel, with user space basically needed only to set the keys and a few parameters.

PPP implements all signaling in user-space, and reimplementing it would be a huge effort. (Also, there are a lot of quirks required to interoperate with countless other implementations that need to be taken care of, and this would require years on top of an initial implementation.)

So, as it has already been patiently explained, the only thing that systemd-networkd reasonably could do is to call the ppp program. So far I have not seen any proposal about how this would work and which benefits it would have compared to the currently available mechanism, but if somebody has a plausible design in mind then please bring it on.

@rfc1036

So far I have not seen any proposal about how this would work and which benefits it would have compared to the currently available mechanism, but if somebody has a plausible design in mind then please bring it on.

Please see: #481 (comment)