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 ).

Chill, chill. I wrote all the code so far, and I expect I'll be the one to write the rest of the code if we decide we want it (so if anyone's time is wasted it is mine). But I haven't made up my mind which way we'll go on this, and I'm open to being convinced either way...

I still think we should do pppoe, actually. i don't think the stuff is on its way out.

PPPoE is definitely not on its way out. Fiber optic providers are using it in my country.

I use a minimal fedora install as a router connecting via pppoe over VSDL (most new UK home ISP connections are VDSL/pppoe now). Having a networkd alternative to NetworkManager for these small server home setups would be very useful. NetworkManager breaks a lot and has too many hard wired parameters for this scenario.

To be honest, for small home server/router type use cases NM is too big. The build you want is more like a cloud image with a few extra network bits. Embedded type deployments on the end of VDSL lines would also fit this use case.

Most connections are pure pppoe (not DSL/ADSL/VDSL) where I live. The ISP connects a network cable to your building->your PC and you authenticate by establishing a pppoe connection.
pppoe support in systemd would be really great.
Just because pppoe is on its way out in many countries doesn't mean it is not still used in others. It is a large world out there.

So urrrm.... Has anything happened on this? I use CentOS 7 as my main router - and seems that the big reason for staying with the legacy 'network' script is that it actually understands ppp links (ie pppoe).

Seems like a major hole in functionality....

PPPoE is not going away and we need at least some integration between pppd and systemd-networkd and -resolved. How would the latter get told about the name server info that's transmitted by PPP?

The majority of the ISP uses PPPoE for both VDSL and Fiber.
Most of the time you don't notice it just because the router does it for you, but it doesn't mean that it's obsolete :)

Just throwing in a 'me too', as I switched to systemd-networkd for my networking a while ago, having switched to an ISP that does PPPOE over fiber, im stuck in manual managing mode things.As @poettering mentioned, pppoe does seem sensible to have. So @teg when will this be on your radar again?

I had like this too. I hope it does get implemented soon.

There is immense value for uk residents in bringing pppoe to neteorkd: all home dsl/fibre providers here are using pppoe as far as I understand.

Here is a question:
If systemd-networkd does not support PPPoE, how to make systemd-networkd-wait-online.service wait for ppp0?

I have few services depends on PPPoE, but for workaround I can only hack the services by adding

/usr/lib/systemd/systemd-networkd-wait-online -i ppp0 -q

and this is not elegant. 😞

Are we at nearly 2 years on, and still no PPPoE support in systemd/networkd? :)

Fedora just released systemd-networkd-251.9-587.fc37.x86_64.
Issue is now fixed out of the box for Fedora users.

@pimzand

Could you please share your latest ppp configuration file?

I want to use your latest configuration content to compare with mine.

I've run into some issues recently, probably with my configuration. Here is my configuration:

[Match]
Name=pppoe-out1
Type=ppp

[Network]
LLMNR=no

[IPv6AcceptRA]
DHCPv6Client=always
UseDNS=no

[CAKE]
Bandwidth=50M
OverheadBytes=38
MPUBytes=84
UseRawPacketSize=yes
FlowIsolationMode=triple
NAT=yes
PriorityQueueingPreset=diffserv4

[Link]
RequiredForOnline=no

So, systemd-networkd 252 with PR #25551 works again, just like systemd-networkd 250.8. I still need IPv6AcceptRA = yes, otherwise the interface is still stuck in state "configuring".

@pimzand I have the same issue for which I reported an issue #26681

Setting IPv6AcceptRA=yes gets the device into the "configured" state, but it will send pointless router solicitations as my internet provider doesn't do any router advertisements.

question: the pppd.service + ppp0.network setup mostly works, however, internal lan.network (s) are not picking up on the default DNS servers (resolvectl has them), which they ideally would transmit per router advertisement/dhcp to the clients, is this normal/expected behavior? I'm on systemd 247 (debian)

Yes. You need to integrate pppd (with a script in /etc/ppp/ip-up.d/) with whatever DNS server you are using, and this is beyond the scope of the systemd units.

That can't be it. I'm currently talking about the basic scenario where I just (want to) use my ISP's DNS servers, not running my own servers. The IPv6 ones automatically get added to networkd/resolved as expected (via ppp0.network), or at least they show up associated with the ppp0 interface when querying resolvectl. Even the IPv4 one's can be added by exploiting resolvectl's resolvconf emulation mode (via symlinking), so the problem is only that the lan.network / interface doesn't pick up on these when it sends out router advertisements / dhcp on its link to the clients. It's not the end of the world, but I'm looking at the configs posted here and they all seem to use statically defined DNS servers too.

It's not unlikely that your ISP DNS servers are being passed using IPCP.
In that case, your pppd.service will know about them, but systemd-networkd will probably not.

If we are talking about IPv6 DNS servers it is totally out of pppd scope. It is totally under systemd-networkd scope.

https://systemd.network/systemd.network.html#EmitDNS=1
" If DNS= is empty, DNS servers are read from the [Network] section. If the [Network] section does not contain any DNS servers either, DNS servers from the uplink interface specified in UplinkInterface= will be used. "

I think UplinkInterface= is the thing you are looking for.

@vanaf Yes, but it doesn't work as described in the man page for me. I suspect that it maybe be a timing issue, see: "Note that this information is acquired at the time the lease is handed out, and does not take uplink interfaces into account that acquire DNS server information at a later point." On the other hand, the prefix is transmitted correctly. The only thing that works for me is to hard code DNS= in the [Network] section of lan.network.

To be clear, I'm on systemd 247, so it doesn't have the ability to specifically define the UplinkInterface= but automatic selection should find the ppp0 one, since it's the only one with associated DNS servers. At the very least, the observed behavior runs counter to systemd 247's stated behavior in the old 247 man page as well.

When my provider assigns me a new IPv6 address, devices continue to use the old address, and IPv6 doesn't work. How can I decrease the lifetime of the assigned IPv6 address?

When I restart the systemctl restart systemd-networkd service, the default gateway of the ipv4 network disappears. Contents of my ppp.network file:

[Match]
Type=ppp

[Network]
DHCP=ipv6
LLMNR=no
IPv6AcceptRA=yes
KeepConfiguration=static
DefaultRouteOnDevice=no

[Link]
RequiredForOnline = no

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

[IPv6AcceptRA]
UseDNS = no
UseDomains = no

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)