add pppoe support to systemd-networkd

[zabbal]

Well, subject line does it :)
Would be very handy to setup PPPoE connections in same concise manner as I do with other interfaces, get them exposed to networkctl, track dependencies on underlying eth interface, automatically reestablish connections on timeouts, underlying interface flaps etc.

[poettering]

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

[zabbal]

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?

[dvdhrm]

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

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

[zabbal]

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.

[dvdhrm]

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.

[zabbal]

It's importance is questionable in modern OSs.

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

[arvidjaar]

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

[dvdhrm]

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.

[johannbg]

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

[dvdhrm]

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.

[johannbg]

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

[teg]

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

[poettering]

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

[ravenexp]

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

[carwyn]

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.

[carwyn]

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.

[ht990332]

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.

[CRCinAU]

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

[smurfix]

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?

[teknoraver]

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

[oliv3r]

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?

[ghost]

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

[jonathanunderwood]

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.

[enihcam]

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

[CRCinAU]

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

[jonathanunderwood]

I think the question at this point is about whether, if code was written, it would be accepted?

…

On 19 Jun 2017 14:30, "Steven Haigh" ***@***.***> wrote: Are we at nearly 2 years on, and still no PPPoE support in systemd/networkd? :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#481 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8jchfBnxK3C0_p3a1cz0Gtiac7Qt05ks5sFngOgaJpZM4FRbdT> .

[pimzand]

Booting Fedora 37 with a kernel from Fedora36 makes no difference. There are no changes to pppd other than a rebuild.
So it must be some difference between systemd-networkd versions 250 and 251.

[pimzand]

I believe the related debug message is
"ppp0: link_check_ready(): address fe80::6935:f185:dd8:bf44/128 is not ready."

[rivimey]

I believe this is from the wait-online service... see my post above.

[yuwata]

@pimzand

And it has the side effect that a /64 route is assigned to the ppp interface which should not happen.

That's expected because you enabled the following:

DHCPPrefixDelegation = yes

This is mostly for downstreams, though it can be enabled also on the upstream. Why do you enable it on the upstream?
Please see the example in systemd.network(5):

Example 3. IPv6 Prefix Delegation (DHCPv6 PD)

# /etc/systemd/network/55-dhcpv6-pd-upstream.network
[Match]
Name=enp1s0

[Network]
DHCP=ipv6

# The below setting is optional, to also assign an address in the delegated prefix
# to the upstream interface. If not necessary, then comment out the line below and
# the [DHCPPrefixDelegation] section.
DHCPPrefixDelegation=yes

# If the upstream network provides Router Advertisement with Managed bit set,
# then comment out the line below and WithoutRA= setting in the [DHCPv6] section.
IPv6AcceptRA=no

[DHCPv6]
WithoutRA=solicit

[DHCPPrefixDelegation]
UplinkInterface=:self
SubnetId=0
Announce=no

# /etc/systemd/network/55-dhcpv6-pd-downstream.network
[Match]
Name=enp2s0

[Network]
DHCPPrefixDelegation=yes
IPv6SendRA=yes

# It is expected that the host is acting as a router. So, usually it is not
# necessary to receive Router Advertisement from other hosts in the downstream network.
IPv6AcceptRA=no

[DHCPPrefixDelegation]
UplinkInterface=enp1s0
SubnetId=1
Announce=yes

This will enable DHCPv6-PD on the interface enp1s0 as an upstream interface where the DHCPv6
client is running and enp2s0 as a downstream interface where the prefix is delegated to. The
delegated prefixes are distributed by IPv6 Router Advertisement on the downstream network.

[yuwata]

@pimzand

I believe the related debug message is "ppp0: link_check_ready(): address fe80::6935:f185:dd8:bf44/128 is not ready."

Do you find logs something like the following?

ppp0: Received new foreign address (configured): fe80::6935:f185:dd8:bf44/128

or

ppp0: Received updated foreign address (configured): fe80::6935:f185:dd8:bf44/128

Please provide logs related to the IPv6LL address.

[pimzand]

I reverted to my original ppp.network file, copied systemd-networkd along with a shared library from a Fedora 36 system and it worked again.

I have attached logfiles created using

journalctl -b -u systemd-networkd.service | grep ppp0 | cut -c71-

after booting with systemd-networkd 251 and 250

log-251.txt
log-250.txt

[pimzand]

This is the original ppp.network I reverted to, used with above tests.

[Match]
Type = ppp

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

[Link]
RequiredForOnline = yes

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

[IPv6AcceptRA]
UseDNS = no
UseDomains = no

[pimzand]

If I set IPv6AcceptRA to false in the example above, then systemd-networkd 250 will fail as well.
That's weird, because I don't see any RA taking place, so accepting it or not should not matter.

Here's a similar logfile with IPv6AcceptRA = no

log-250-nora.txt

[yuwata]

I believe the related debug message is "ppp0: link_check_ready(): address fe80::6935:f185:dd8:bf44/128 is not ready."

From log-251.txt,

ppp0: Received new foreign address (configured): fe80::a932:5b01:27f9:41bf/128 (valid forever, preferred forever), flags: tentative,permanent, scope: link
ppp0: Received new foreign address (configured): fe80::a932:5b01:27f9:41bf peer fe80::8238:bcff:fe0b:cd27/128 (valid forever, preferred forever), flags: permanent, scope: link
ppp0: link_check_ready(): address fe80::a932:5b01:27f9:41bf/128 is not ready.

It seems 5d00303 causes the issue.

[pimzand]

@yuwata do we need to create a new issue?
This issue 481 is a discussion about the need to have pppd/pppoe integrated into systemd-networkd.
Will you create the issue, or should I?

[yuwata]

@pimzand Yeah, let's move to new page. Could you open a new issue page?

[pimzand]

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]

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

[CallMeR]

@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

[dirkjonker]

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.

[tnierath]

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)

[rfc1036]

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.

[tnierath]

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.

[pimzand]

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.

[vanaf]

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.

[tnierath]

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