after emerging the new baselayout my adsl-connection doesn't work anymore. i changed in the /etc/conf.d/net modules_eth1=( "adsl" ) and ipaddr_eth1=( "adsl" ) and ln -s net.eth0 net.eth1 an now when starting with /etc/init.d/net.eth1 i get Code: * Starting eth1 * Bringing up eth1 * eth1 adsl * Starting ADSL for eth1 TIMED OUT i noticed that nothing is called when the script is started. when using /etc/init.d/rp-pppoe start somthing like Code: eth1: link up, 10 Mbps but with the above nothing happens i also updated to rp-pppoe-3.5-r3 but now nothing works anymore i can only establish a adsl-connection with adsl-start and canceling after looking at the /var/log/messages when there show a connection up, else all TIMED OUT Reproducible: Always Steps to Reproduce: 1. 2. 3.
I had the same problem. This is actually a continuation of Bug #59321. The script is trying to feed the pppoe config file to adsl-start via stdin, and it fails. The work-around I use is first to re-emerge back rp-pppoe-3.5-r2, then go to /lib/rcscripts/net.modules.d/adsl, and change the mess on line 81 (where adsl-start is called) to simply /usr/sbin/adsl-start ${adsl_cfgfile_IFACE} and similarly for adsl-stop (line 104). In case you have several network cards, you will need files /etc/ppp/pppoe-eth{0,1,...}.conf, where you will need to setup ETH, USER and PIDFILE accordingly. Or, if you really want to use the same config file, in the same way it is done now, just write the whole mess there to a temporary file, and use it as the config file: local cfg_file=`tempfile` cat ${adsl_cfgfile_IFACE} > ${cfg_file} echo "ETH='${iface}'" >> ${cfg_file} echo "PIDFILE='/var/run/adsl-${iface}.pid'" >> ${cfg_file} [[ -n ${user} ]] && echo "USER=${user}" >> ${cfg_file} /usr/sbin/adsl-start ${cfg_file} local ret=$? rm ${cfg_file} eend ${ret} || return ${ret} (This goes instead of the adsl-start line)
Works for me... but is there already a fix to solve this with rp-pppoe-3.5-r3?
Not as far as I know and baselayout-1.11.4 doesn't help either.
*** Bug 69148 has been marked as a duplicate of this bug. ***
*** Bug 69166 has been marked as a duplicate of this bug. ***
Moshe Kaminsky is right. This is a continuation of Bug #59321. Aron Griffis tried to fix it, but something goes wrong. rp-pppoe-3.5-r3 is patched to work with the baselayout's net scripts, rp-pppoe-3.5-r2 wasn't (See files/rp-pppoe-3.5-netscripts.patch). That patch is the only thing that changed between r2 and r3, so the problem has to be in there somewhere, but I can't find it. In my opinion the problem is that adsl-start always times out. This causes the net script to think something went wrong.
> In my opinion the problem is that adsl-start always times out. Yes, even if I start adsl-start by hand it opens the link and I have a working adsl connection. But adsl-start doesn't exit but prints every second a "." for about a minute. Then I get a TIMEOUT message, the connection is shut down, and adsl-start exits. It seems that somehow adsl-status which is used in /usr/sbin/adsl-start doesn't realize that the connection is etablished and after some time adsl-start kills the adsl-connect process and quits.
Setting the DEBUG variable in adsl-start shows no error on the console as well as in the logs. Possible that the service is messing up in someway or the new netscripts patch is as Andreas mentioned.
While I don't have access to a DSL connection myself, I have taken a look at the scripts and can't see an obvious problem. Has anyone thought to echo the contents of particularly $CONFREAD into a file to see if the reading from an FD works? IMO, that seems to be the most likely cause of the error.
Created attachment 43030 [details, diff] Patch to make rp-pppoe work with baselayout The rp-pppoe needs a couple of more fixes to make it work with the pipe reading required for the netscripts to work.
Created attachment 43031 [details, diff] Patch to read config for adsl_stop The new baselayouts adsl functions need a bit of fixing on the stop part. The patch supplied here does work for me, but maybe the problem should be fixed in /etc/init.d/net.lo. I don't know if other modules require a configuration (See ${mod}_setup_vars lines 355-366 on the start part) for shutting down interfaces.
Created attachment 43032 [details] Ebuild for applying the rcscripts-1.6.4-adsl-patch
Any progress with this?
No clue - Andy submitted the patches he and I worked out to get this working, but they're against an older Baselayout, and I haven't heard any feedback yet, neither from the Gentoo folks directly, nor Andy mentioning they pinged him.
i have this bug now for several weeks and several rp-pppoe verisons.
After emerging baselayout 1.11.6-r1 (i think) and rp-pppoe-3.5-r4, I am still having the connexion "Timed out" message when I boot my cpu even though it does connect to the internet. The problem is that ssh daemon can't start. However, when I type adsl-connect, the connexion is made relatively rapidly and this I have tried quite a few times. Don't know where to look or what piece of info I should give you to help you solve the problem.
I did look at rp-pppoe-3.5-r4 and there is a new patch 3.5-adsl-stop.patch. Lookin at it, I can see it does not address the problem solved with our patch submitted. This bug has been around for several weeks now, still being in status NEW, so I figure nobody from gentoo has looked at it so far, so be patient. Has anyone tryed Andreas Turriff's and my solution/patches submitted. For the rp-pppoe just replace the rp-pppoe-3.5-netscripts.patch in the files-dir with this http://bugs.gentoo.org/attachment.cgi?id=43030. In the baselayout you only need to add one line to make it work (See http://bugs.gentoo.org/attachment.cgi?id=43030 for what to change).
Sorry, but the second link should be http://bugs.gentoo.org/attachment.cgi?id=43031.
Andy, do the patches still apply cleanly? Think we should ping the base system herd directly?
OK, I have applied the patch for rp-pppoe and it did the trick. In boot up sequence, the message "connected" finally appears again so yeah Andreas K patch worked for me. However, the baselayout still is giving me problem to start up eth0 and still sshd still cannot be started.
I'm also having that problem. FWIW, here's what I sent to the user mailing list: I'm having a problem with /usr/sbin/adsl-start from rp-pppoe-3.5-r4 and would like to see if I'm the only one before I file a bug report. Well, my problem is, that the call in line 175 ${exec_prefix}/sbin/adsl-status<(echo"$CONFREAD")>/dev/null2>&1 doesn't return an exit code of 0 and thus, doesn't terminate the loop. When I put "${exec_prefix}/sbin/adsl-status <(echo "$CONFREAD")" in the script, I see the following error message: adsl-status:Linkisdown(can'treadpppoePIDfile.pppoe) When I, at the same time, call /usr/sbin/adsl-status, I get: [16:56:30 alexander@server:~] $ sudo /usr/sbin/adsl-status adsl-status: Link is up and running on interface ppp4 ppp4Protokoll:Punkt-zu-PunktVerbindung In the error message, note the () term: can'treadpppoePIDfile.pppoe It seems, like adsl-status doesn't find the path to the PID file. When I do an 'echo "$CONFREAD"', I see that there's a line 'PIDFILE="/var/run/$CF_BASE-adsl.pid"'. This happens to be the same as I have in /etc/ppp/pppoe.conf (go figure *G*). Right now, I replaced the line ${exec_prefix}/sbin/adsl-status<(echo"$CONFREAD")>/dev/null2>&1 with ${exec_prefix}/sbin/adsl-status>/dev/null2>&1 and this seems to work just fine.
There're 18 people on the CC list of this bug plus the reporter. There're also solutions attached here. What is the reason for the gentoo devs to ignore this bug till now? It was opened one month ago.
we enjoy ignoring people who complain about being ignored
Hi, @alex f: Please be patient. The devs surely are working on this when they have the time for. There are so many unresolved bugs here you can't expect any bug of a ~[arch] masked package to be fixed soon. If you don't know how to put a fixed ebuild in an overlay yourself downgrade rp-pppoe to the latest version marked stable. Poly
I didnt want to sound like I was complaining. I merely wanted to know why it took that long. Ignore is probably the wrong word in that context. Sorry
#20 - file a new bug? I don't think anyone here has a problem with the ethernet interface coming up. #24 - I thought the ~[arch] packages were intended to receive field testing? Andy K - you know whether anything we worked out needs to be changed for the baselayout releases since we looked at this?
Hi, #26 yes and I'm sure everybody who wrote here tested either -r3 or -r4. They failed for me so I went back to stable -r2. Maybe I would have done some testing or even try to provide a fix but as the changes in rp-pppoe are somehow involved with new baselayout I don't wanna mess around with something another person would most likely do a better job than me. Poly
the adsl_stop patch will have to be reviewed by UberLord but it looks fine to me the rp-pppoe patch is not quite right ... the PIDFILE must be dynamic so as to allow for multiple ppp# connections also, can you please post the patch as a diff against our current patches ? it seems like the changes involve setting CONFREAD to the pipe instead of reading it directly ...
I changed the two lines CF_BASE=`basename $CONFIG` PIDFILE="/var/run/$CF_BASE-adsl.pid to a default PIDFILE value, cause basename will not do the trick when working with pipes. It results in files called 63-adsl.pid, but the worse than that, filename will change when piping the config to diffrent rp-pppoe scripts! (e.g. from adsl-start to adsl-connect, when starting manually) I haven't come up with a proper solution for this yet, except for getting rid of the whole piping of config concept. Maybe changing baselayout to work with an unpatched rp-pppoe, would be an easier solution, considering new versions of rp-pppoe to come. Keep in mind that manual starting and stopping should still work, when changing the pppoe.conf.
actually, i lied about that part i just remembered that we define PIDFILE in the pipe that we pass as the config file so it doesnt matter, so when we source the file, PIDFILE is overridden
adsl stopping fixed in CVS We actually need to call adsl_setup_vars in adsl_start and adsl_stop as net.lo doesn't call this anymore. This is because each module is now responsible for setting itself up. Will be in baselayout-1.11.7
Created attachment 44737 [details, diff] Additional patch to make RP-PPPOE play nice with baselayout Updated Andreas Kauer's and my original patch to rp-pppoe to work with Gentoo's latest patches for the package.
awesome ... after grabbing the net modules code from cvs and applying the patch by Andreas Kauer, it worked nicely :) root@home 0 run # /etc/init.d/net.eth0 start * Starting eth0 * Bringing up eth0 * adsl * Starting ADSL for eth0 [ ok ] root@home 0 run # ifconfig eth0 | head -n 2 && ifconfig ppp0 | head -n 2 eth0 Link encap:Ethernet HWaddr 00:10:57:00:21:28 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ppp0 Link encap:Point-to-Point Protocol inet addr:151.203.215.200 P-t-P:10.9.95.1 Mask:255.255.255.255 root@home 0 run # /etc/init.d/net.eth0 stop * Stopping eth0 * Bringing down eth0 * Stopping ADSL for eth0 [ ok ] * Shutting down eth0 ... [ ok ] ive added rp-pppoe-3.5-r5 to cvs with the fixes ... hopefully baselayout-1.11.7 should be in cvs this weekend :) thanks Andreas Kauer and everyone else
1.11.7 is out
*** Bug 74505 has been marked as a duplicate of this bug. ***
Please can someone reopen this bug. During an emerge -u world, my working 3.5-r1 was replaced by 3.5-r5, but unfortunatly it seems that 3.5-r2 and up are causing TIMED OUT on adsl-start or /etc/init.d/rp-pppoe start. I have baselayout 1.11.7-r2, which should be recent enough? - Please, would someone still have the good old 3.5-r1 ebuild file? - Did someone else have similar problems? Thanks.
re-opened as requested
Works fine for me with baselayout-1.11.7-r2 and rp-pppoe-3.5-r5. While shutting down though it says that the connection doesn't appear to be up..can anyone else confirm?
simple solution: dont use the rp-pppoe init.d script if there's a problem with that script, file a new bug
I don't think its a problem with the /etc/init.d/rp-pppoe script either. I use that, it works fine.
I don't use /etc/init.d/rp-pppoe but ADSL is working fine here through /etc/init.d/net.eth0 with baselayout-1.11.7-r2 and rp-pppoe-3.5-r5. But adsl-status is not finding the pid file and thus falsely reports that the link is down. (This is when ppp0 is up and running:) # adsl-status adsl-status: Link is down (can't read pppoe PID file /var/run/adsl.pid.pppoe) # ls -l /var/run/adsl* -rw-r--r-- 1 root root 5 15. Dez 10:17 /var/run/adsl-eth0.pid -rw-r--r-- 1 root root 5 15. Dez 10:17 /var/run/adsl-eth0.pid.pppd -rw-r--r-- 1 root root 5 15. Dez 10:17 /var/run/adsl-eth0.pid.pppoe -rw-r--r-- 1 root root 5 15. Dez 10:17 /var/run/adsl-eth0.pid.start
This bug is still alive, at least with baselayout 1.9.4-r6 and rp-pppoe-3.5-r7. It happens whether I use adsl-start or the init script. Also adsl-connect doesn't work (at least for me), even though a comment said it does. It says: root>adsl-connect /usr/sbin/adsl-connect: line 16: ipchains: command not found <message repeated many times with different lines> The bug didn't happen with rp-pppoe-3.5-r2. Do I have the wrong version of baselayout? I just used the newest x86 version, so if that's the problem I'd say either a newer version of baselayout should be marked stable or newer versions of rp-pppoe should be marked unstable. If that's not the problem, I think the bug should be reopened.
What's the deal here? I said rp-pppoe-3.5-r7 isn't working for me, and only 3.5-r2 works, so I masked everything above 3.5-r2, and now someone's removed 3.5-r2 from the portage tree. That's caused emerge depclean to think ppp isn't needed, which I supposed wasn't necessary so I let it remove it, and now I can't connect to the internet at all so I can't even emerge what I need to fix it. I'm going to have to use the Gentoo CD. I'm telling you: this bug is still a bug. At least keep 3.5-r2 around until it gets fixed. If someone doesn't either re-open it or explain what I'm doing wrong, I'll just have to start a new bug report.
> - Please, would someone still have the good old 3.5-r1 ebuild file? All the ebuilds are at: http://www.gentoo.org/cgi-bin/viewcvs.cgi/
no update and -r7 is still broken
define broken ... there's some misconceptions here ... baselayout-1.9.x -> do not use the init script w/adsl, that wont be fixed baselayout-1.11.x -> net init scripts work fine rp-pppoe (i use it on my router) adsl-start / adsl-stop -> these should work fine regardless of baselayout version
Finally, an explanation. When it is not possible to have only x86 versions of a package installed which mutually work, where they worked in previous versions that have disappeared from portage, it is broken by my definition. rp-pppoe-3.5-r2 should have been left as the newest x86 version along with baselayout-1.9.x, or rp-pppoe-3.5-r7 should have stayed x86 while baselayout-1.11.x became x86. Not a mixture.
the adsl module with baselayout-1.9.x never worked properly
But it did not exhibit this bug until new versions of rp-pppoe.
The point is that adsl-start still doesn't work (for me). It creates the ppp0 interface, but doesn't realize that and then times out. I call that broken. This is caused by the ${P}-gentoo-netscripts.patch, as commenting it in the ebuild solves this problem (tested with -r7, -r9 and -r11). So please someone fix that patch. And just to say it again: I only use adsl-start/-stop to manage the adsl link, no /etc/init.d script.
more than two months later now. I think rp-pppoe is still broken and no activity here. I have rp- pppoe-3.5-r1 and ppp-2.4.3-r8 and baselayout-1.12.0_pre3-r2 and I also get this nasty TIMEOUT when trying to start config_eth0=( "adsl" ) or adsl-start. Ironically some combination with "DEBUG=1 adsl-start" followed by "adsl-start" twice brings up the ppp0 net device. I tried to deactivate the described rp- pppoe-3.5-netscripts.patch by simply commenting it out, but the new portage will not let you do this and complains about a digest verification failure.
*** This bug has been marked as a duplicate of 53954 ***
