A bit of a farfetched idea, but here goes... Lately I've been playing with kernel PPPoE, which, if the distribution had built-in support, would run at much lower CPU cost and more straightforward setup than rp-pppoe (although rp-pppoe is one of the easiest things to configure already). Kernel PPPoE involves building PPP over Ethernet support into the kernel, including 'plugin pppoe.so \n name "blah@blah.com" (where this references the appropriate user/password pair in pap-secrets)' in /etc/ppp/options. At this point all one has to do is type 'pppd eth0 defaultroute persist', or if one wants link detection, /usr/sbin/pppd eth0 updetach defaultroute persist lcp-echo-interval 20 lcp-echo-failure 3 There's more to the equation which I haven't worked out yet; pppd seems to give up after five or so tries if the redback servers don't respond, leaving the host permanently down - rp-pppoe continues attempting to connect until it succeeds in connecting, so I'm either missing a pppd option or they're re-running pppd every time it dies (this is probably it). Potential benefits of distribution support for kernel-pppoe: 1) Doesn't depend on an external pppoe package 2) Native to the kernel and our pppd ebuild, nothing else required 3) Much greater CPU efficiency (especially for slower systems) 4) Simpler to configure - would probably only require /etc/conf.d/pppoe or similar and the addition of a new interface configuration method in /etc/conf.d/net (pppoe or adsl instead of dhcp, as is used in bug #24975) 5) Would save a teeny bit of space on the livecd? Dunno about this, but it sounds good on paper. In short, while rp-pppoe remains an excellent PPPoE package (especially in terms of portability across distributions and ease of setup), we could be leveraging the kernel's native support for PPPoE (which it's had for years now) and providing a pseudo-builtin way for users to connect to ADSL. Opinions welcome! Reproducible: Always Steps to Reproduce:
maybe you can come up with a patch?
I think the options you are looking for are "persist maxfail 0". I don't have such a configuration on my hosts nor do I used it before, so I need a working script which uses the standard ppp package, as a start point.
PPPoA support would be achieved the same way in the init scripts - I am using a Conexant AccessRunner PCI DSL modem & it needs the same thing. I installed the kernel module & firmware for my modem by hand & emerged ppp-2.4.3-r1 with the new +atm use flag - it works perfectly with just a few lines in /etc/ppp/options, including "plugin /usr/lib/pppd/2.4.3/pppoatm.so", username & pass in chap-secrets and then simply typing `pppd` I think this feature would be simple for someone more clueful than me to implement, and would be especially useful now - not only are pppoe & ppp-over-atm both in the main kernel tree, but Gentoo's ppp has an "atm" USE flag. I'd be happy to test & I think many others in the UK would also be glad to.
Created attachment 61462 [details] /lib/rcscripts/net.modules.d/pppoe this net module add support for PPPoE. it uses only pppd and kernel support for PPPoE.
hmm, what's the problem actually? I'm running ppp with the pppoe plugin and it works great. But the pppoe net-plugin seems to be a much cleaner way to setup it. But you should add "noproxyarp" to the options IMHO. and: how is the name of the ppp device?
the real ppp device name cannot be influcenced in any way. however, the name of the link can be set. my module sets it to the name of the NIC (e.g. eth0). as for noproxyarp, I don't see why we should disable proxyarp since I do not set it. If the user added proxyarp in /etc/ppp/options, he/she knows what is doing.
Created attachment 61517 [details] /lib/rcscripts/net.modules.d/pppoe A new version that edit /etc/ppp/{pap-secrets,chap-secrets}
Created attachment 61518 [details] support for pap/chap-secrets automatic editing these 2 functions must be added to /lib/rcscripts/net.modules.d/helpers.d/functions this support will also be used in the new ppp module (which replaces the actual /etc/init.d/net.ppp0).
Created attachment 61523 [details] support for pap/chap-secrets automatic editing The 2 functions proven to be 3 :)
Alin, I only asked, because I have special iptables set up for my ppp0 device. Since you have a physical ethernet device (ethX) and a logical ppp device (pppX) you have to setup your firewall rules according to these devices names. So it's ok to have a net.ethX for pppoe, but you have to set a fixed pppX for this device, otherwise your firewall rules will be messed. ;) So just add an option, such as 'pppoe_link_name'.
huh, btw, wouldn't it be better do pass the password via stdin to ppp? It isn't necessary to write it into the pap-secrets. Currently, I'm using the password.so plugin to pass it in my peers/* file.
(In reply to comment #10) I am not aware of such pppd option. Only logical name of the ppp interface can be modified through options and as I said, I already set it to the name of the Ethernet interface. If you know how to force a name on a ppp interface, please let me know. If you have multiple ppp links and cannot use generic interface names such as -i ppp+, you could use /etc/ppp/{ip-up.local,ip-down.local} to alter firewall rules according to your needs. (In reply to comment #11) Indeed, passwordfd.so plugin appears to be a much cleaner approach. uberlord, please let me know what method do you prefer.
I meant the logical pppX device. I have to know this name to setup my firewall. You can see this device via ifconfig: ppp0 Protokoll:Punkt-zu-Punkt Verbindung inet Adresse:XXX.XX.XX.XXX P-z-P:XXX.X.XX.XXX Maske:255.255.255.255 UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:5453 errors:0 dropped:0 overruns:0 frame:0 TX packets:6520 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenl
I meant the logical pppX device. I have to know this name to setup my firewall. You can see this device via ifconfig: ppp0 Protokoll:Punkt-zu-Punkt Verbindung inet Adresse:XXX.XX.XX.XXX P-z-P:XXX.X.XX.XXX Maske:255.255.255.255 UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:5453 errors:0 dropped:0 overruns:0 frame:0 TX packets:6520 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:3 RX bytes:2059404 (1.9 Mb) TX bytes:759693 (741.8 Kb) setting it to the same name as the physical Ethernet device is odd, because my ethX (eth2 in my case) only routes to my DSL-Modem. I need two different network device names! The physical eth2 device is just the link to my modem, while the logical ppp0 device is the route to internet. this is how ppp runs on my system now: /usr/sbin/pppd lock persist holdoff 10 defaultroute ipparam fritzbox linkname ppp0 call fritzbox noauth ktune maxfail 0 hide-password as you can see, 'linkname' sets up the ppp0 device. And that's all I need.
> Indeed, passwordfd.so plugin appears to be a much cleaner > approach. uberlord, please let me know what method do you prefer. hmm. Just an idea: if the user specifies a password in /etc/conf.d/net, then use passwordfd.so, if not do nothing! Then the user has to specify it in pap-secrets by himself. You can document this behaviour in a comment in /etc/conf.d/net.example.
(In reply to comment #13) > I meant the logical pppX device. I have to know this name to setup my firewall. [snip] > as you can see, 'linkname' sets up the ppp0 device. And that's all I need. the linkname option do not set the real name of the interface . the real name of the interface will still be pppX. I *can't* influence the real name of the interface (the one that matters from the iptables perspective).
I have a few issues with these patches 1) the support for automatic editing should remain in the pppoe module until another module requires it 2) please use style consitent with baselayout if .... then ; fi instead of [[ ... ]] && { } [[ -f ${foo} ]] instead of [ -f "${foo} ] 3) pppoe_setup_vars should be in pppoe_start as it's the only place where it's needed - also ensure that the vars are localised 4) suggest changing pppoe_mtu_${iface} to mtu_${iface} and we patch ifconfig/iproute2 modules accordingly 5) 10.112.112.112:10.112.112.113 - is that a hardcoded ip or something special? 6) way too many sed calls - here's how to double backslash in bash foo="${foo//\\\\/\\\\}" I'm also sure that bash can do s/\([/.*]\)/[\1]/g as soon as sometime tells me what it's supposed to do ;)
(In reply to comment #16) > I have a few issues with these patches > > 1) the support for automatic editing should remain in the pppoe module until > another module requires it it will be required by the upcoming ppp module. however I'm seriously thinking to drop it in favor of passwdfd.so plugin usage. > 4) suggest changing pppoe_mtu_${iface} to mtu_${iface} and we patch > ifconfig/iproute2 modules accordingly don't think so. you see, the created ppp device use a slightly smaller MTU than eth interface does. you should not use the passed mtu in other place than pppoe setup. > 5) 10.112.112.112:10.112.112.113 - is that a hardcoded ip or something special? nothing special. we need a phony address for on-demand links. I choosed to use the same thing that rp-pppoe does. > 6) way too many sed calls - here's how to double backslash in bash > foo="${foo//\\\\/\\\\}" > > I'm also sure that bash can do s/\([/.*]\)/[\1]/g as soon as sometime tells me > what it's supposed to do ;) ok, maybe I could replace these with ${foo//.../...}. however, in the event I use passwdfd.so plugin, these are no longer needed.
Created attachment 61597 [details] /lib/rcscripts/net.modules.d/pppoe Changed as requested. Unfortunately passwordfd.so plugin does not work without "nodetach" so I kept my original solution (updating pap/chap-secrets files). I've also rearranged parameters in order of importance.
Created attachment 61598 [details] support for pap/chap-secrets automatic editing Replaced seds as much as possible. Sorry for insisting, but these functions will be used in the future ppp module so it should be declared in /lib/rcscripts/net.modules.d/helpers.d/functions
Created attachment 61599 [details] support for pap/chap-secrets automatic editing ops... missed some spots
Created attachment 61600 [details] /lib/rcscripts/net.modules.d/pppoe discovered that HUP does not kill pppd process. I've replaced with TERM.
Created attachment 61699 [details] support for pap/chap-secrets automatic editing I've tested a bit and discovered that I cannot escape /
Is there any reason why we can't make this a generic ppp module? ppp_plugins_eth0=( "rp-pppoe" ) or ppp_plugins_eth0=( "pppoatm" ) BTW thanks for the chat and the insight an ppp Alin :)
but then don't forget: ppp_plugins_eth0=( "capi" ) since some of the AVM controllers are using DSL via CAPI. I can provide the ppp options for DSL via CAPI if you want.
oh, we don't have a NIC for CAPI based DSL-Controllers. so: ppp_plugins_ppp0=( "capi" ) or: ppp_plugins_controller1=( "capi" ) ;-)
guys, if you wanna make a generic ppp module, keep in mind that pppoe's options should have a precise order (at least some of them). Yesterday I've talked with Roy on chat. He said the module should be initialized by a net.ppp0 module, idea I didn't embraced at that moment. Now I think it is the best thing to separate it from the transport channel (in this case eth0). This information could be passed to pppoe module by a param (e.g. pppoe_eth_interface_ppp0="eth0"). On the matter pppoe vs pppoa, I guess we could rename the module as pppox and let the user decide what plugin should be loaded, but I don't agree we should do it in one generic module for the reasons expressed above and because: a) the name will confuse the user - peeps search for known terms like pppoe and pppoa b) rp-pppoe.so plugin has parameters that are unknown to pppoatm.
(In reply to comment #26) > guys, if you wanna make a generic ppp module, keep in mind that pppoe's options > should have a precise order (at least some of them). We can juggle them if needed > > Yesterday I've talked with Roy on chat. He said the module should be initialized > by a net.ppp0 module, idea I didn't embraced at that moment. > Now I think it is the best thing to separate it from the transport channel (in > this case eth0). This information could be passed to pppoe module by a param > (e.g. pppoe_eth_interface_ppp0="eth0"). Heh - Now I'm starting to think your way as I can't find any way of forcing the ppp interface name - unless we patch ppp :/ > > On the matter pppoe vs pppoa, I guess we could rename the module as pppox and > let the user decide what plugin should be loaded, but I don't agree we should do > it in one generic module for the reasons expressed above and because: > a) the name will confuse the user - peeps search for known terms like pppoe and > pppoa Doucmentation PPP (covers PPPoE, PPPoA, ADSL, etc) > b) rp-pppoe.so plugin has parameters that are unknown to pppoatm. > > Which is a good reason for them to be included as extra options ppp_rp_ppoe_option1_eth0="foo" ppp_options_eth0="option1 foo" The user still has to *know* the option to set it. Therefore, it would be documented at some stage, therefore I still don't see the need for all the parameter options pppd and it's modules can use.
We can also do case "${plugin}" rp-pppoe) # do default pppoe option setup pppatm) # do default pppoa option setup *) # user options? esac I'm really trying to do this inside one module as pppoe, pppoa and others all provide "ppp" and they all use the same binary - so it really just comes down to what options to give it and how we go about it.
ok lets establish a common ground on all possible ppp links. command should begin with "/usr/sbin/pppd persist maxfail 0". this is a requirement (pppd should run until service is taken down with net.ppp0 stop) and it isn't user configurable. next, we should add link information. probably is a good idea to name the link as virtual-ppp0 since we cannot force pppd to allocate a specific pppx to this connection : remotename ${virtifname} linkname ${virtifname} ipparam ${virtifname} if ${user} is not empty, we should add "user ${user}". also update secrets files if ${password} is not empty. after that, all things should be set by optional lines found in array vars like $ppp_options_ppp0 and/or $ppp_options. the following lines should be found in net.example: - usual params but user configurable for what we care: noauth defaultroute - support for on-demand links demand idle 60 10.112.112.112:10.112.112.113 ipcp-accept-remote ipcp-accept-local - lcp-echo examples lcp-echo-interval 15 lcp-echo-failure 3 next part is pppoe only: connect true plugin rp-pppoe.so ( ... optional rp_pppoe_service and rp_pppoe_ac ...) eth0 noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp
uberlord discovered on web that we can set name of the ppp interface by using "unit" parameter. this means that pppd command should start with "/usr/sbin/pppd persist maxfail 0 unit ${iface#ppp}" also, when the link is not on-demand (no idle param), the command line should contain "updetach", which will guarantee that the link is started at the end of ppp_start function.
first of all: I love the idea of a ppp-net-plugin. But after all talk about pppoe vs. pppoa, please don't forget capiplugin.so! CAPI is used for ISDN primarily, but also for some DSL cards from AVM. The options for ppp are only a litte bit different to the rp-pppoe.so plugin. So it should be easy to handle it also. I can provide all informations about it. Furthermore, having CAPI connections handled by ppp (and as such by the net-plugin) would be really great for ISDN users also.
Stefan, please provide here the necessary information about wanted functionality regarding CAPI.
@Alin: ok, I provide the working contents of my peer-file for some AVM hardware we got from AVM. I explain some of the options after. plugin capiplugin.so plugin userpass.so connect "" avmadsl sync mru 1492 mtu 1492 idle 86400 holdoff 60 lcp-echo-interval 10 lcp-echo-failure 3 lcp-max-configure 50 lcp-max-terminate 2 ipcp-accept-remote ipcp-accept-local user <myuserid> password <mypassword> noproxyarp noauth noccp noipx : /dev/null Some explainations: 'avmadsl' tells the capiplugin to use /etc/drdsl/adsl.conf which can be created with net-dialup/drdsl. In 'adsl.conf' there are the defaults for your DSL-Controller. 'drdsl' autodetects controller and vpi/vci settings. So during setup, you run 'drdsl' once and then you have this values in: controller 2 protocol adslpppoe vpi 1 vci 32 'controller' is by default '1'. You can have as many CAPI controllers (ISDN/DSL) as you want. On DSL only boards, you have only "controller 1", as long you don't have some ISDN controller also. On the Combi-Boards with ISDN *and* DSL, ISDN part is controller 1 and DSL is controller 2. '/dev/null' is just the device-dummy for the "modem-device" (/dev/ttySX), because we don't need it. For AVM DSL-Controllers, 'controller', 'protocol' and such (see above) should be taken from 'adsl.conf' (see avmadsl option). For ISDN-Controllers, it should be explicitly specified on commandline, since you don't have that config file (see below). The rest should be obvious. Please emerge net-dialup/capi4k-utils and you will find a really good sample-file for a DSL connection in /etc/ppp/peers/t-dsl and in /etc/ppp/peers/capi-isdn an example for an ISDN connection via CAPI. working CAPI peers file: sync noauth -chap defaultroute plugin userpass.so plugin capiplugin.so controller 1 protocol hdlc #numberprefix 0 number <phonenumber> user <myuserid> password <mypassword> /dev/null So to put the important options together: 1. DSL via CAPI: plugin capiplugin.so avmadsl /dev/null 2. ISDN via CAPI: plugin capiplugin.so controller 1 protocol hdlc numberprefix 0 <- optional number <phonenumber> /dev/null
Created attachment 61844 [details] generic ppp module OK gang - here's my first draft of a generic ppp module. Should work with stable baselayout just fine. Options in /etc/conf.d/net link_ppp0="eth0" # whatever the link is you're using username_ppp0="foo" password_ppp0="bar" mtu_ppp0="1492" # 1492 is supplied as a default by us if not specified pppd_ppp0="what ever options you want" plugins_ppp0=( "pppoe any pppoe options you want" "anotherplugin some more options for this plugin" ) This should work just fine :) However, me may want to put some default options that a plugin needs in the module that the user will always need - I'll leave that for you guys to decide as I have no working ppp enviroment - yet.
Created attachment 61849 [details] pppd module pppd module provides ppp - this makes us more consistent with other modules fixed a minor bug and updated function comments
These are my observations: - I _really_ don't like the fact you throwed away my hard work regarding secrets files. Your solution rewrites them every time you start a ppp connection. No need to tell ya what would happen when you have 2 ppp connections. Again, my solution is complete and if anyone finds a bug in it, I'd be happy to fix it. - "nodetach" should be forbidden - it would block the module. Instead, you should add "updetach" (if "idle" is not set). - remotename should be $iface and ipparam should be removed (no need for it) also, unit should be set after maxfail (it is a forced option after all) - mtu/mru should not have vars of their own. if the user wanna set a different mtu, is free to do it pppd_ppp0. The default mtu (1500) set by pppd is the best default for generic case. Also you should note even if you set 1500 on a PPPoE, the mtu set by pppd would be $(( $mtu_eth0 - 9 )) - if /etc/ppp/options.$iface exists, its name should be appended to command line as "file /etc/ppp/options.$iface"
Created attachment 62051 [details] generic ppp module - "nodetach" should be forbidden - it would block the module. Instead, you should add "updetach" (if "idle" is not set). - remotename should be $iface and ipparam should be removed (no need for it) also, unit should be set after maxfail (it is a forced option after all) - mtu/mru should not have vars of their own. if the user wanna set a different mtu, is free to do it pppd_ppp0. The default mtu (1500) set by pppd is the best default for generic case. Also you should note even if you set 1500 on a PPPoE, the mtu set by pppd would be $(( $mtu_eth0 - 9 )) - if /etc/ppp/options.$iface exists, its name should be appended to command line as "file /etc/ppp/options.$iface" ^^^^^^ All that is done.
(In reply to comment #36) > These are my observations: > - I _really_ don't like the fact you throwed away my hard work regarding > secrets files. Your solution rewrites them every time you start a ppp > connection. No need to tell ya what would happen when you have 2 ppp > connections. Again, my solution is complete and if anyone finds a bug in it, I'd > be happy to fix it. You have 3 sed statements compared to one egrep + mv - which is more efficient? Checking to see if the file needs updating is one more egrep call which is still more efficient. And that's not even thinking about the loop you run to find an available sed seperator. As to re-writing the file every thime ppp is started - so what? Your solution still re-writes the file if it needs to which would affect a running pppd daemon in exactly the same way as mine would.
(In reply to comment #38) > You have 3 sed statements compared to one egrep + mv - which is more efficient? > Checking to see if the file needs updating is one more egrep call which is still > more efficient. Wrong. In the worst case, I have 2 seds. In the best case (nothing changed) I have 1 sed. > And that's not even thinking about the loop you run to find an available sed > seperator. Again, this loop is ran only when something has changed. > As to re-writing the file every thime ppp is started - so what? Your solution > still re-writes the file if it needs to which would affect a running pppd daemon > in exactly the same way as mine would. Wrong again. My solution does not rewrite anything it does not own while yours delete everything else. My variant is a complete solution for _editing_ secrets files. Please use the right tool for the job.
Created attachment 62083 [details] latest one
The last version refuses to work for me, even if the same pppd command line works fine from bash! Here is the output: Plugin rp-pppoe.so loaded. RP-PPPoE plugin version 3.3 compiled against pppd 2.4.3 using channel 38 Using interface ppp0 Connect: ppp0 <--> eth0 Couldn't increase MTU to 1500 Couldn't increase MRU to 1500 sent [LCP ConfReq id=0x1 <magic 0x986a4b62>] rcvd [LCP ConfReq id=0x1 <auth pap> <magic 0xdf6d9e9>] No auth is possible sent [LCP ConfRej id=0x1 <auth pap>] rcvd [LCP ConfAck id=0x1 <magic 0x986a4b62>] rcvd [LCP ConfReq id=0x2 <magic 0xdf6d9e9>] sent [LCP ConfAck id=0x2 <magic 0xdf6d9e9>] Couldn't increase MTU to 1500 Couldn't increase MRU to 1500 sent [LCP EchoReq id=0x0 magic=0x986a4b62] peer from calling number 00:0A:E6:BA:73:4C authorized kernel does not support PPP filtering sent [IPCP ConfReq id=0x1 <addr 217.156.27.36>] rcvd [LCP EchoReq id=0x0 magic=0xdf6d9e9] sent [LCP EchoRep id=0x0 magic=0x986a4b62] rcvd [LCP TermReq id=0x3 "peer refused to authenticate"] LCP terminated by peer (peer refused to authenticate) Couldn't increase MTU to 1500 Couldn't increase MRU to 1500 sent [LCP TermAck id=0x3] Connection terminated. using channel 39 Using interface ppp0 Connect: ppp0 <--> eth0 Couldn't increase MTU to 1500 Couldn't increase MRU to 1500 sent [LCP ConfReq id=0x2 <magic 0x274a40e2>] Modem hangup I am too pissed off to see what the hell changed from the working version. Maybe tomorrow...
Created attachment 62109 [details] draft for ppp chapter of the net.example As you can see I've added 3 options that needs to be implemented. When chat_ppp0 is not empty, a new option should be appended to ${opts}, just before plugins: "connect \"/usr/sbin/chat " + "-T 'first_phone_no' " (if not empty) + "-U 'second_phone_no'" (if not empty) + quoted members of chat_ppp0 + "\""
Created attachment 62123 [details] pppd module This version IS the last one. If you not accept it as is, I will pull myself out of this bug. I'm not used to work for nothing, ya know! Don't worry, all tabs have been replaced with 4 spaces. Changed things: - linkname has been removed. instead we use /var/run/ppp${unit}.pid, which is the real pid file. - user \"${username}\", for some strange reason, refuses to work. removed quotation. - some minor reordering - correct indentation To do: - needs an implementation for handling chat parameters.
Created attachment 62124 [details] pppd net module the previous version still had tabs.
Created attachment 62377 [details] update_secrets_file function implementation using sed -r I've redesigned my original implementation of update_secrets_file function. The new version does not search for s separator anymore and it was tested with every special chars. N.B.: this function will not work if you have double quotes (") or quote (') in username/remotename/password. It could be done, but I don't think it will be useful to anyone.
Created attachment 62505 [details] draft for ppp chapter of the net.example Updated example config file.
Created attachment 62508 [details] pppd net module Updated the net module with following changes: - replace update_secrets_file with my implementation based on sed (modified to work with any chars, including double quotes) - add chat connect script support - add ${link} to pppd options (when pppoe plugin isn't used) - fixed bug when plugins_ppp0 is empty (the old implementation tried to load the plugin named ".so") Stefan, please test it on your ISDN connection and see if I've missed something. Also, you should provide an example of ISDN connection.
Hello, I will attemp to test this module, I have just one question: Should I make net.ppp0 a link to net.lo and delete the original net.ppp0 installed with pppd? Thank you.
of course. I forgot to tell you that ;)
Ok, I got it to work but I have some concerns. I added net.ppp0 in my default runlevel and I noticed a big delay in the boot process. It was trying to bring ppp0 up and it waited until pppd managed to connect. But what will happen if the ISP is down for some reason and pppd cannot connect? The boot process will stay frozen until pppd manages to connect? I realize ofcource this is just for testing now, but it looks promising.
when you start net.ppp0, it will wait till gets connected. at the end of /etc/init.d/net.ppp0 users know the link is up & ready (don't see any reason why it should be otherwise).
I unterstand your logic, I am just saying that if pppd cannot connect and it is in the default runlevel, and configured to try forever, the system will just not boot!
And what do you think it should do? You think is better to remove "updetach" from pppd's options and let other rcscripts think that the net has been started? You are free to set your own "maxfail" if you really want it, but don't complain if you discover once in awhile that pppd has died.
Well, for my needs, I would prefer it if pppd was stared, even if it could not connect imediately, to just keep trying, while continuing the boot process. If I unterstand you correctly, I can achieve this by removing the "updetach" option? I will give it a shot and see how it works.
Ok, it worked. I removed the "updetach" option and commented a couple of lines, and now it behaves like adsl-connect more or less. When I start the service, it detaches immediately and continues booting normaly. That kind of behavior is wanted on PPPoE (and PPPoA?) links, on desktop systems and home servers. I recognise that it cannot be the default behavior if this module is to be a generic ppp module, so I asking, can this be made configurable? Maybe with an entry in /etc/conf.d/net? This is a very good script, and I just try to make you see my point of view as home user. Thank you.
I had this problem with the approach you`ve been suggeting. My password uses special characters. Now, when I entered it in /etc/conf.d/net as password_ppp0="so!me$pass" and then started net.ppp0 I would get a wrong username/password error message. I checked in /etc/ppp/chap-secrets and noticed that the several characters of the password had been trucated after the dollar sign. The password had effectively been turned into something like this : "user@isp.com" ppp0 "somess", so authentication would fail. I solved this (thank to Costas Cavouracis) by inserting a "\" before the dollar sign in /etc/conf.d/net. Nonetheles, I don`t think this should constitute norm behaviour!
(In reply to comment #56) > I had this problem with the approach you`ve been suggeting. My password uses > special characters. Now, when I entered it in /etc/conf.d/net as > > password_ppp0="so!me$pass" So use the following password_ppp0='so!me$pass' The single quotes mean don't "expand" anything - the $ symbol denote pass as a variable otherwise
(In reply to comment #57) Well, I'll be sure to tell him, since he's not in the CC list. Thanks.
ok. I switched to single quotation marks now and removed the '\' character. Hope that works!
Baselayout 1.12 is coming closer to stable, will this pppd module work with it? I'm using it for my dsl pppoe connection over a month now without any problems, and I would like it to stay that way. I would hate to return to rp-pppoe, and this bug hasn't been active a long time now...
It should work as is. Reason I've not been active on getting this into baselayout is for a few reasons 1) I cannot get any pppoe to work on my systems :/ 2) Once 1) is satisfied, it *may* need a patch to change where it stores it's configs, but I can only verify this once I have it basically working. But the code itself should work just fine :) Why don't you try it out with 1.12.0_pre6?
pppd module is in our svn repo, will be in baselayout-1.12.0_pre9
Excelent news!
When is baselayout-1.12.0 expected to be released?
*** Bug 106764 has been marked as a duplicate of this bug. ***
pre9 is now out. Could everyone following this bug please try it out? Hopefully I'll get the doc's merged for pre10
I tried pre9, the pppd module works just fine for my PPPoE ADSL connection, but I reverted to the stable baselayout due to other, unrelated to pppd, problems with baselayout.
I've just tested the pppd net module in sys-apps/baselayout-1.12.0_pre9-r1 with my cell phone and GPRS. To get that working, I prefer (as I've always done this in the past) to do the entire configuration in /etc/ppp/options.ppp0. To get this working with the new pppd module, I have to cheat and add config_ppp0=( "ppp" ) link_ppp0=" " to /etc/conf.d/net. Notice the empty link_ppp0 setting. I suggest making the link_pppX setting optional, as it is not needed when doing the entire configuration in an external file (which is already supported by the pppd module). I'd be happy to make a patch for this, if people agree.
link_ppp0 is a required parameter in almost every type of PPP connections. I think you should use /etc/ppp/options.ppp0 for all the other options but link. Of course, if Roy agrees, the module could be patched to have some parameter like "use_external_config_ppp0=yes", which instead will simply run pppd -f /etc/ppp/options.${iface}
Required, sure - but why treat it specially? I can set all other options in /etc/ppp/options.ppp0, why not allow me to set link there and have all configuration variables in one place as opposed to scattered between two config files with no good reason? All link_ppp0 is used for is appending to the pppd command line...
btw, the pppd module already appends "-f /etc/ppp/options.${iface}" to the pppd command line if that file exists.
(In reply to comment #70) > All link_ppp0 is used for is appending to the pppd command line... nope. For the usual PPP connections, link is the first parameter, but for PPPoE plugin, it must be in a certain place, more exactly after the last parameter of the pppoe plugin. You could argue that link could be safely added to the end of parameters string, but I've seen some pretty annoying incompatibilities between ppp-2.4.2 and ppp-2.4.3, triggered by rp-pppoe package.
(In reply to comment #72) > nope. For the usual PPP connections, link is the first parameter For "normal" PPP connections, I believe the link parameter can be anywhere. > but for PPPoE plugin, it must be in a certain place, more exactly after the last parameter of > the pppoe plugin. Ok - how about making the link_${iface} var required for pppoe connections, but optional for all other types of PPP connections?
This may sound a bit radical, but how about patching pppoe plugin so that it can read the link parameter from anywhere on the command line or the config file? Surely it can't be that hard, and it would solve this issue :)
(In reply to comment #74) > This may sound a bit radical, but how about patching pppoe plugin so that it can > read the link parameter from anywhere on the command line or the config file? no can't do! pppoe plugin cannot read parameters situated before "plugin rp-pppoe.so" anyway. you could require link_${iface} only for pppoe, but I wonder how many bugs will be filled because users forget to set the link in command line. this module was created for making the life easier for its users and to make them dump that rp-pppoe (I'm still amazed why we adopted that bunch of bash scripts when we could write our own).
*** Bug 68934 has been marked as a duplicate of this bug. ***
*** Bug 97972 has been marked as a duplicate of this bug. ***
I tested the ppp module with CAPI (only ISDN connection, DSL not yet). It works. When I run "/etc/init.d/net.ppp0 start" it starts the connection, but then it "hangs". I can ctrl-c it and with "/etc/init.d/net.ppp0 stop" I can stop the connection. Is there anything wrong with my setup? config_ppp0=( "ppp" ) link_ppp0="/dev/null" username_ppp0="XXXXXX" password_ppp0="XXXXXX" pppd_ppp0="sync noauth -chap defaultroute" plugins_ppp0=( "capiplugin controller 1 protocol hdlc number XXXXXXXXXXX" ) the only ugly thing is the link_ppp0 since CAPI don't need special devices. Can this be the default somehow? Furthermore, we need examples in /etc/conf.d/net.example ;-) My next tests are CAPI with AVM DSL-Controllers and of course PPPoE (which should work I guess).
maybe you have nodetach in /etc/ppp/options. launch /etc/init.d/net.ppp0 start in one terminal, copy the command line and try it yourself. if it hangs in terminal, it will hang the net module as well. I don't mind making link_ppp0 optional for connections that don't use pppoe plugin.
well, it works now. Don't know, but I think I had something other than /dev/null before as the link-name while I tested what's needed. With /dev/null it works. Perhaps it's some oddness of the capiplugin.
*** Bug 111196 has been marked as a duplicate of this bug. ***
Coming from Bug 111196. With the current stable version, i'm forced to use the updetach to avoid the problem described in that bug (basically, the pppd process is not killed properly). I want to avoid this bug without using updetach (I don't like to have the system halted until my isp connection comes back). In this situacion, something like killall pppd will work, but i think it is too aggressive to use this in a generic script. Is this problem solved in the current ebuild? I will try it as soon as possible.
killall pppd isn't an acceptable solution. the only way to avoid updetach is to set an on-demand connection (see attached net.example).
(In reply to comment #75) > you could require link_${iface} only for pppoe, but I wonder how many bugs will > be filled because users forget to set the link in command line. this module was > created for making the life easier for its users and to make them dump that > rp-pppoe (I'm still amazed why we adopted that bunch of bash scripts when we > could write our own). Right. I've just switched my dial-up profiles from using /etc/ppp/options.${iface} to being fully defined in /etc/conf.d/net. I hadn't seen attachment #62505 [details] back when I complained about the required link_${iface} var, my fault. In other words, the ppp rcscript network module (as found in sys-apps/baselayout-1.12.0_pre9-r1) does the trick here; good job. :)
(In reply to comment #84) >killall pppd isn't an acceptable solution. >the only way to avoid updetach is to set an on-demand connection (see attached >net.example). I know killall is not an acceptable solution. But to me, the good solution would be to obtain manually the pid of the pppd process in start and use it to kill in the stop. Waiting for pppd to write the ppp0.pid file is the root of the problem i'm describing.
I've now committed the documentation (modified to match our style) into net.example This bug can be closed when baselayout-1.12.0_pre10 is released :)
baselayout-1.12.0_pre10 is released - so this bug is FIXED Please open new bugs for futher issues
When is the stable release of baselayout-1.12.0 expected?
(In reply to comment #88) > When is the stable release of baselayout-1.12.0 expected? How long is a piece of string? heh From my perspective it IS stable and has been for some time now. From others, it's probably bug ridden. If no bugs crop up, or minor issues that we can fix with minor patches then we'll probably go stable mid December. Remember, 30 days have to pass without serious issue before we even consider going stable. Even then we think twice! You want 1.12.0_pre10 to go stable faster? Then test it as much as you can on as many boxes as you can and make bug reports.
(In reply to comment #85) > ... But to me, the good solution would > be to obtain manually the pid of the pppd process in start and use it to kill in > the stop. Waiting for pppd to write the ppp0.pid file is the root of the problem > i'm describing. for "normal" links, pppd starts ppp0 interface after the initial negociation, therefore pid.ppp0 couldn't exist if the link hasn't been brought up yet. for on-demand links, pppd initialize ppp0 with phoney IP settings and waits for trafic on this interface, which will trigger the real connection. since ppp0.pid is created at the same time with ppp0 interface, the pid file will be there the very next moment after running pppd. a generic solution to your problem would be to use "linkname" parameter for this scope (/var/run/ppp-${linkname}.pid is created before ppp interface startup). Roy, are you willing to accept patches? :)
(In reply to comment #90) > a generic solution to your problem would be to use "linkname" parameter for this > scope (/var/run/ppp-${linkname}.pid is created before ppp interface startup). > Roy, are you willing to accept patches? :) Yes, and it's a good solution as I recall you tested that pppd bails with an error if the specified linkname is already in use ...
the promised patches have been submitted in bug #112049
Is this module suitable for manually adding to baselayout-1.11? If so, which files need to be taken from baselayout 1.12 in order to make this work?
(In reply to comment #93) > Is this module suitable for manually adding to baselayout-1.11? No
