Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add pppoe support to systemd-networkd #481

Closed
zabbal opened this issue Jul 3, 2015 · 33 comments

Comments

@zabbal
Copy link

commented Jul 3, 2015

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

This comment has been minimized.

Copy link
Member

commented Jul 3, 2015

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

@zabbal

This comment has been minimized.

Copy link
Author

commented Jul 6, 2015

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

This comment has been minimized.

Copy link
Member

commented Jul 9, 2015

@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

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2015

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

@teg teg closed this Jul 9, 2015

@zabbal

This comment has been minimized.

Copy link
Author

commented Jul 9, 2015

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

This comment has been minimized.

Copy link
Member

commented Jul 9, 2015

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

This comment has been minimized.

Copy link
Author

commented Jul 9, 2015

It's importance is questionable in modern OSs.

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

@arvidjaar

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2015

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

@dvdhrm

This comment has been minimized.

Copy link
Member

commented Jul 9, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2015

@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

This comment has been minimized.

Copy link
Member

commented Jul 9, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2015

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

This comment has been minimized.

Copy link
Member

commented Jul 9, 2015

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

@ravenexp

This comment has been minimized.

Copy link

commented Sep 28, 2015

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

@carwyn

This comment has been minimized.

Copy link

commented Oct 18, 2015

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

This comment has been minimized.

Copy link

commented Oct 18, 2015

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.

@hussamT

This comment has been minimized.

Copy link

commented Mar 31, 2016

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

This comment has been minimized.

Copy link

commented Jul 30, 2016

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

This comment has been minimized.

Copy link

commented Aug 31, 2016

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

This comment has been minimized.

Copy link

commented Feb 10, 2017

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

This comment has been minimized.

Copy link

commented Apr 24, 2017

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

This comment has been minimized.

Copy link

commented May 14, 2017

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

@jonathanunderwood

This comment has been minimized.

Copy link

commented May 21, 2017

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

This comment has been minimized.

Copy link

commented Jun 19, 2017

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

This comment has been minimized.

Copy link

commented Jun 19, 2017

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

@jonathanunderwood

This comment has been minimized.

Copy link

commented Jun 19, 2017

@oliv3r

This comment has been minimized.

Copy link

commented Jun 20, 2017

As I mentioned before, @teg said he'd pick it up, but I guess that is not going to happen?

For those interested, right now, I'm doing it with a few other scripts via systemd as can be seen but have an issue left as can be seen in #5972. If people are curious I can put the full content up in a gist.

@CRCinAU

This comment has been minimized.

Copy link

commented Jun 20, 2017

The problem as I see it, is that you either do it all, or none at all. If there is a decision to only support the most common network types and ignore everything else, then we should really encourage networkd to be abandoned. Leave it for other networking subsystems that are much more advanced, much more mature, and able to actually get the job done with a minimum of fuss.

Leaving networking in a half-assed state only encourages other 'solutions' to be left in a half assed state.

@virtualdxs

This comment has been minimized.

Copy link

commented Sep 25, 2017

@oliv3r Please do post it. I'm trying to set up a PPPoE over VLAN connection but netctl doesn't work for it because the VLAN interface starts as up even if I say no ip so it won't start a PPPoE connection on the VLAN interface.

@moralrebuild

This comment has been minimized.

Copy link

commented Jan 3, 2018

lacking PPoE support makes bringing up the VPN over it much difficult. Saying the Wireguard over PPP over Ethernet, the systemd service (e.g: systemctl enable wg-quick@wg0)doesn't work at all. have to manually add the ugly code in following way:

sudo sh -c 'printf "\nwg-quick up wg0" >> /etc/ppp/ip-up.d/0clampmss'

@CRCinAU

This comment has been minimized.

Copy link

commented Jan 3, 2018

So 2 1/2 years on, and such basic functionality is still not progressing.

Considering the new NBN in Australia has about 70% of connections using PPPoE........ This means everyone still has to use NetworkManager to do PPPoE connections - even on small router based setups.

I guess the "not a problem for me" ethos still reigns supreme.

@smurfix

This comment has been minimized.

Copy link

commented Jan 3, 2018

sudo sh -c 'printf "\nwg-quick up wg0" >> /etc/ppp/ip-up.d/0clampmss'

Umm, no. You can do this with a couple of dependencies, esp. one on sys-devices-virtual-net-ppplink.device @enihcam. "ppplink" here refers to the network device created by pppd, which you can name with an ifname ppplinkstanza in the config file. Likewise you can / should make your pppd service depend on the existence of the physical interface or VLAN it's running on (if you're using pppoe).

Also, you can bring up your wireguard stack independently. It'll magically start working as soon as the route to the target is established. While systemd might need to know about wireguard's peer states, that's a problem for a different issue, esp. since wg doesn't yet have a way to report state changes via netlink.

This means everyone still has to use NetworkManager to do PPPoE connections

What's wrong with (or indeed difficult about) a .service file that starts pppd directly? You don't need NetworkManager for that. Likewise, if you have an uplink.network file it'll auto-configure the link for you, no buggy ppp shell scripts required.

So, to sum up, while setting up pppoe is certainly annoying and the kind of mess systemd-networkd is supposed to fix in the first place, starting it up is mostly manageable. Which is probably the reason it's not fixed yet. :-/

The main problem I have with the current state of affairs is that ppp transmits DNS and IPv6 state that's hard/impossible to teach systemd-networkd/resolved about. IPv6 support is kindof important …

Thus, @teg no it's not out of scope IMHO. Would you be willing to take the code that's been written so far, add what's missing, and patch it into current systemd? Or make it available for somebody else to do so?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.