This bug wants to solve 2 problems of the new pppd net module: 1) some users are unhappy about forced updetach option. They want that /etc/init.d/net.ppp0 start to return immediately Solution: move updetach to pppd_ppp0 2) /var/run/${iface}.pid is created only after the ppp interface goes up. That makes pppd's process impossible to stop when interface wasn't started Solution: force "linkname ${iface}", which will force creation of /var/run/ppp-${iface}.pid Patches will follow shortly.
Created attachment 72560 [details, diff] pppd.diff Patch to be applied to the /lib/rcscripts/net.modules.d/pppd
Created attachment 72561 [details, diff] net.example.diff Patch to be applied to /etc/conf.d/net.example
Created attachment 72573 [details, diff] enables pppd module to use IN_BACKGROUND env var (requires above pppd patch) This enables pppd module to use the IN_BACKGROUND=true|false var set by deamons when restarting scripts. So the if-ip|down ppp scripts need to do this last. export IN_BACKGROUND="true" /etc/init.d/net.$iface start|stop This basically informs the rc system that the interface is up/down, and when this flag is set not start|stop daemons that control interface status, such as ifplugd, netplugd, wpa_supplicant and now pppd.
First two patches are included in pre10-r1
Created attachment 72605 [details, diff] new pppd.diff I've tested baselayout-1.12_pre10-r1 patched with this. If I set ppp0 without updetach and modify ip-up script to run: export IN_BACKGROUND=true "/etc/init.d/net.$1" start exit 0 the service reach the status "started" but ppp0 interface doesn't get any IP settings, despite the fact that the PPP protocol negociated them! I'm sure it isn't pppd's fault (commenting the net.ppp0 start line solve the problem). P.S. Do not forget to apply the pppoa part of the attached patch. I've forgot that PPPoA links need kernel support as well ;)
Created attachment 72608 [details, diff] new pppd.diff Corrected typos & indentation
Created attachment 72644 [details, diff] pppd-wrapper This patch goes in /lib/rcscripts/net.modules.d/helpers.d Fixes - dns_search_* being merged if no other options Addes - pppd-wrapper to be called by pppd ip-up should export these env vars dns_nameservers_$iface="1.2.3.4 5.6.7.8" Then it should run /lib/rcscripts/net.modules.d/helpers.d/pppd-wrapper up $iface ip-down should run /lib/rcscripts/net.modules.d/helpers.d/pppd-wrapper down $iface I still think that pppd should be patched to accept a metric n parameter so it can set the route metrics to n for subnet and defaultroute.
Created attachment 72645 [details, diff] New patch
(In reply to comment #7) > I still think that pppd should be patched to accept a metric n parameter so it > can set the route metrics to n for subnet and defaultroute. No one force you to use "defaultroute" pppd option in the first place. The pppd man page clearly states that you should use /etc/ppp/ip-up if you wanna set other kind of routes than the simple "ip route add default dev ppp0". Besides, specifying this option could result, depending on the context, in replacing the current default route. As for subnet part, what subnet? All point-to-point links have as (pseudo)netmask 255.255.255.255 . What could we possibly gain from such minor improvement? Wanna let user tune its routes? Fine. The proper way of doing this is by not using "defaultroute" pppd parameter at all and let user set its own routes through routes_ppp0. You still want to modify metrics of the already-defined-by-pppd routes? Why not run: ip route | grep "dev $iface" | xargs ip route replace metric $metric in pppd-wrapper?
(In reply to comment #9) > (In reply to comment #7) > > I still think that pppd should be patched to accept a metric n parameter so it > > can set the route metrics to n for subnet and defaultroute. > > No one force you to use "defaultroute" pppd option in the first place. You mis-understood. Apply the metric to the default route (if specified) and replace the added subnet route If you add an address 192.168.0.2/24 then you get a route to the 192.168.0.0/24 network in your routing table - with a metric. We need to change that metric. > > You still want to modify metrics of the already-defined-by-pppd routes? Why not run: > ip route | grep "dev $iface" | xargs ip route replace metric $metric > in pppd-wrapper? Could do - that relies on having iproute2 installed. We need to cater for ifconfig as well
pppd will add at least 1 and at most 2 routes: - a host route (netmask 255.255.255.255) to peer (always created) - a default route through $iface (controlled by defaultroute option) those are the _only_ IP routes that pppd could create by itself. I'm sure we both agree that we could find solutions to alter those routes regardless the tool we use ("route" or "ip route"). Now, what about routes_ppp0? Are these going to be supported by pppd or not?
Created attachment 72807 [details, diff] Patch to be applied to pppd net module Please apply the attached patch to pppd net module.
Created attachment 72808 [details] /etc/ppp/ip-up This file will be in the next version of net-dialup/ppp. I know you said that peeps use to copy /etc/init.d/net.lo to net.${iface} but right now net-dialup/ppp install a /etc/init.d/net.ppp0 script . I must be able to see if this is the old script installed by net-dialup/ppp or is the new net.lo baselayout script.
Created attachment 72809 [details] /etc/ppp/ip-down This file will be installed by the new net-dialup/ppp
Created attachment 72810 [details] /lib/rcscripts/net.modules.d/helpers.d/pppd-wrapper This is a rough version of how pppd-wrapper should look like. The add route and change metric part should be improved by adding support for ifconfig net module as well.
Created attachment 72868 [details, diff] New pre10-r1 patch OK, I've got a new patch which forces pppd-wrapper to recall /etc/init.d/net.$iface start|stop - this is so we go through the whole process at least once. This is needed as pppd is like ifplugd + dhcp in a way. I've fixed the interface selection, so ppp0 resolv.conf should now get merged successfully.
Created attachment 72885 [details, diff] New pre10-r1 patch Forget to merge mrness's changes We now test /proc/net/pppoe - if it's not there then we mobprobe pppoe - if that fails then we throw an error and abort. If anyone knows of a similar test for pppoatm then I'd be grateful for a patch :)
1) I've found that pppoatm module does create following files under proc fs: /proc/net/atm/{devices,pvc,svc,vc} 2) pppd needs some indentation cleanups. Please replace tabs with spaces and correct indentation. 3) Your patch is a strange one. It patches files in ${ROOT}/lib/rcscripts but also a file in ${S} dir of the baselayout-1.12_pre10-r1. The following could be due to the fact that this patch is incomplete/incorrect. 3.1) If I specify "updetach", the pppd module is somewhat working first time it connects (if it gets disconnected once, it behaves as explained in 3.2) but with this lines in log: ... pppd[19237]: Script /etc/ppp/ip-up started (pid 19266) rc-scripts: WARNING: "net.ppp0" has already been started. pppd[19237]: Script /etc/ppp/ip-up finished (pid 19266), status = 0x1 ... pppd[19237]: script /etc/ppp/ip-down, pid 19679 rc-scripts: ERROR: "net.ppp0" has not yet been started. pppd[19237]: Script /etc/ppp/ip-down finished (pid 19679), status = 0x1 ... 3.2) when net.ppp0 is started without "updetach", the ppp0 interface has no IP settings after startup. Specifications for the pppd net module: - the net.ppp0 should be marked as "started" only by ip-up script, regardless if it is processed in foreground or background. - between inactive/starting state and started state, under no circumstances baselayout should alter IP settings of ppp0 interface. The only settings allowed to be touched are IP routes but only on ip-up execution. - the ip-down script must mark net.ppp0 as "inactive"
(In reply to comment #18) > 1) I've found that pppoatm module does create following files under proc fs: > /proc/net/atm/{devices,pvc,svc,vc} Cool - we can use if [[ ! -d /proc/net/atm ]]; then modprobe etc > > 3) Your patch is a strange one. It patches files in ${ROOT}/lib/rcscripts but > also a file in ${S} dir of the baselayout-1.12_pre10-r1. The following could be > due to the fact that this patch is incomplete/incorrect. Sorry, the patch was supposed to be applied after baselayout was installed. I'll prepare a patch for the ebuild then. > > 3.1) If I specify "updetach", the pppd module is somewhat working first time it > connects (if it gets disconnected once, it behaves as explained in 3.2) but with > this lines in log: > ... > pppd[19237]: Script /etc/ppp/ip-up started (pid 19266) > rc-scripts: WARNING: "net.ppp0" has already been started. > pppd[19237]: Script /etc/ppp/ip-up finished (pid 19266), status = 0x1 > ... > pppd[19237]: script /etc/ppp/ip-down, pid 19679 > rc-scripts: ERROR: "net.ppp0" has not yet been started. > pppd[19237]: Script /etc/ppp/ip-down finished (pid 19679), status = 0x1 > ... I suppose I could test to see if net.$iface is marked inactive (so we can re-enter) or starting/started (so we don't re-enter) so we don't get that message in the logs > > 3.2) when net.ppp0 is started without "updetach", the ppp0 interface has no IP > settings after startup. Probably because /lib/rscripts/conf.d/env_whitelist didn't get patched. > > > Specifications for the pppd net module: > - the net.ppp0 should be marked as "started" only by ip-up script, regardless > if it is processed in foreground or background. OK. In that case we need to background completely, so when pppd returns we always exit otherwise there will be "races". So you'll never see "got IP address x.x.x.x.x" > - between inactive/starting state and started state, under no circumstances > baselayout should alter IP settings of ppp0 interface. The only settings allowed > to be touched are IP routes but only on ip-up execution. Depends on user config. If user a dumbass and does config=( "192.168.0.2/24" "ppp" "10.1.1.1/24" ) Then we let them. We make no exceptions > - the ip-down script must mark net.ppp0 as "inactive" > It does. I'll prepare a new patch after I get to work, this time for the build.
(In reply to comment #19) > > Specifications for the pppd net module: > > - the net.ppp0 should be marked as "started" only by ip-up script, regardless > > if it is processed in foreground or background. > > OK. In that case we need to background completely, so when pppd returns we > always exit otherwise there will be "races". So you'll never see "got IP address > x.x.x.x.x" Then we must mark net.ppp0 as started without calling /etc/init.d/net.ppp0 start in pppd-wrapper. Otherwise "updetach" looses its meaning (updetach == "make sure the ppp0 is started before returning from /etc/init.d/net.ppp0 start").
(In reply to comment #20) > (In reply to comment #19) > > > Specifications for the pppd net module: > > > - the net.ppp0 should be marked as "started" only by ip-up script, regardless > > > if it is processed in foreground or background. > > > > OK. In that case we need to background completely, so when pppd returns we > > always exit otherwise there will be "races". So you'll never see "got IP address > > x.x.x.x.x" > > Then we must mark net.ppp0 as started without calling /etc/init.d/net.ppp0 start > in pppd-wrapper. Otherwise "updetach" looses its meaning (updetach == "make sure > the ppp0 is started before returning from /etc/init.d/net.ppp0 start"). So you'll have to patch pppd to it does not return until it's run the scripts instead of returning before it runs then like it does currently.
but this is what updetach means! return only after the connection starts and ip-up is executed.
Created attachment 72938 [details, diff] New pre10-r1 patch Addresses all mrness's issues
(In reply to comment #22) > but this is what updetach means! return only after the connection starts and > ip-up is executed. But the point is pppd returns control back to the calling net.ppp0 after it gets a connection, but *before* it runs any scripts. In this new patch, we force going to background regardless of the updetatch option.
IMO, waiting for the end of ip-up is a must. What would be the point of "updetach" if user will not have a proper configured ppp0 interface (including routes) at the end of /etc/init.d/net.ppp0 start? Really, this must be solved one way or the other, even if it means execution of /etc/init.d/net.ppp0 from pppd-wrapper would go away!
I've already told you what the solution is - get pppd to return when it has connected and run the scripts. I'm not going to loop endlessly until the scripts have been "run".
1) You are right. When updetach is selected, pppd will launch ip-up and detach without waiting ip-up to end. However this is not as bad as it sounds because the ppp0 interface was already setup by pppd (IP link & address). 2) Unfortunately ip-up still manage to erase IP settings from ppp0. Are you aware that RC_INTERFACE_KEEP_CONFIG doesn't appear anywhere else than pppd-wrapper and env_whitelist? 3) Some changes need to be made to pppd net module: --- pppd.orig 2005-11-15 23:01:15.000000000 +0200 +++ pppd 2005-11-15 23:27:51.000000000 +0200 @@ -247,9 +247,9 @@ mark_service_inactive "net.${iface}" local quiet="--quiet" [[ ${RC_VERBOSE} == "yes" ]] && quiet="" - start-stop-daemon --start ${quiet} --exec /usr/sbin/pppd \ - --pidfile "/var/run/ppp-${iface}.pid" -- ${opts} - eend $? || mark_service_starting "net.${iface}" && return 1 + eval start-stop-daemon --start ${quiet} --exec /usr/sbin/pppd \ + --pidfile "/var/run/ppp-${iface}.pid" -- ${opts} + eend $? || mark_service_starting "net.${iface}" if [[ " ${opts} " == *" updetach "* ]]; then local addr=$( interface_get_address "${iface}" ) The reasons are: a) eval is requested because of opts="user '"${username}"' ${opts}" (line 168 in pppd) b) pppd_start should not return anything but should simply exit gracefully (with 0) - if it returns 0, the baselayout will set the routes; else it will display the red exclamation points. Since ppp0 have already an address for updetach case, I don't see any reason why we shouldn't display it. Another minor thing is what I believe to be RC_VERBOSE abuse. What does this flag mean? "baselayout should display in detail what it does" or "we will display stdout/stderr of every used programs"? The output of pppd is very ugly, not to mention meaningless for rookies.
Created attachment 72992 [details, diff] New pre10-r1 patch Addresses all the above issues options have been moved into an array, removed the need for eval statements :) chat options may be broken as I've changed from using eval foo="foo_$ifvar[@]" to t="foo_${ifvar}[@]"; foo="${!t}" - that's the one part I cannot yet test
it works! (\me opens the champagne) you could bump it to _pre11 from where I stand. ;)
Does that include the chat phonenumber stuff?
Created attachment 73062 [details, diff] net.example.diff Not so fast. I still have some changes. :) The attached net.example.diff corrects pppd_ppp0 array in net.example. Given the last changes, elements in this array should not be quoted. Also, I could replace the symlink test in ip-up/ip-down with something like: if [[ $foe == "yes" && -f "/lib/rcscripts/net.modules.d/helpers.d/pppd-wrapper" ]] ; then where $foe is an env var exported by the pppd net module. What do you think?
(In reply to comment #30) > Does that include the chat phonenumber stuff? nope. I cannot test that (my tests were on a PPPoE link).
Created attachment 73143 [details] final pppd module OK, I've backed out one of my changes. This means we keep the current net.example. A few more tweaks have also been made. This module has been comitted to our svn repo, and will appear in baselayout-1.12.0_pre11
What do you say about last paragraph in comment #31?
I doubt that pppd passes all env vars it inherits to it's child processes. Also, I'm not that keen on the idea.
baselayout-1.12.0_pre11 contains the new pppd module
