From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT) External USR 56K Modem. Machine hangs indefinitely when trying to bring up the ppp0 interface when booting the machine Reproducible: Always Steps to Reproduce: 1. Install Operating System (Fresh install or upgrade from 7.0-respin) 2. Configure ppp0 using the Dialup Configuration Utility, such that ppp0 starts with the machine. 3. Reboot the server and machine hangs. Actual Results: Machine hand during the boot sequence. BUT... When I reset the machine boot single user, turn networking off and bring the machine up. Reconfigure the ppp0 connection not to boot with the system. Machine is ok and the same configuration can be used to connect to the internet and disconect manually, it just doesn't work automatically. Expected Results: Machine should boot automatically, ppp0 should be brought up and the machine should dial the internet either immediately or as soon as a non local packet is sent. This problem was encountered when I upgraded from 7.0 to 7.1. I thought that maybe a fresh install would cure the problem, but after the necessary rebuild of the machine the same problem has occured. I have had to install a slower machine with 7.0 and am using this whilst I try out more "permutations", but would like any assistance. The strange thing is when you activate the connect by hand using the debug button in the Dialup Configuration Utility the connect works fine, so why hang on boot? It worked fine in 7.0
Interestingly enough, I am having this problem to, but I haven't migrated to 7.1 yet (still on 7.0). I had been upgrading some packages, one of which is initscripts, and all of a sudden exactly as above is happening to me too. I suspect it is something to do with how the ppp0 interface is coming up.... it's in demand mode too. If I attempt to ping through the interface from another machine on my network, the connection comes up, and then the server will continue to boot. Can't find much in my logs about this though... But it was first thing this morning, I've not had a proper look yet.... Should do tonight though.
I see a similar problem in 7.1 but the dialing is working, its just that if the modem is off for example it spends forever trying to dial. The ppp dialing should be in the background
On mine, the modem is on, but it still seems to hang. There is no dialing, and the process doesn't appear to be in the background (since everything stops till this command completes).
Newbie here, but the problem is still listed as "new" and as i haven't seen a solution for this posted anywhere, i'm submitting this in the hopes that other people find this information helpful. You can skip to the end if all you want to know is how to fix this on your RH7.1 (SeaWolf) installation. Here's WHAT'S HAPPENING & WHY: It's not really a pppd problem, but more of a scripting "oversight" that is not necessarily isolated to the boot sequence. This can be verified by the fact that the ppp dial-up link works fine after boot, and also by manually launching "/etc/init.d/network start" to simulate activating ppp0 (and other interfaces) on boot, thereby invoking the hang. One of the scripts that gets called during the course of executing the init scripts for activating ppp0 at boot time (when "ONBOOT=yes" in the /etc/sysconfig/network-scripts/ifcfg-ppp0 config file) can be found here: "/etc/sysconfig/network-scripts/ifup-ppp" After much tracing & debugging via breakpoints, i found that it was the last command called by this script that was causing the hang. This line (by default) looks like this: exec /usr/sbin/pppd -detach $opts ${MODEMPORT} ${LINESPEED} \ ipparam ${DEVNAME} linkname ${DEVNAME} call ${DEVNAME}\ noauth \ ${PPPOPTIONS} the shell variable expansions looked something like this: lock modem crtscts asyncmap 00000000 defaultroute usepeerdns user myusernameformyisp remotename ppp0 demand ktune idle 600 holdoff 30 /dev/ttyS2 115200 ipparam ppp0 linkname ppp0 call ppp0 noauth all of which were fine. I then tested the pppd call from bash which outputted: local IP address: 10.64.64.64 remote IP address: 10.112.112.112 and then hung, at which point i had to ctrl-c to get my prompt back. However, the man page that (presumably) applies to the version of pppd shipped with 7.1 specifies an "-updetach" option, but does not specify "-detach" as a valid option for pppd. Furthermore, the man page indicates a "-nodetach" option which "Without this option, if a serial device other than the terminal on the standard input is specified, pppd will fork to become a background process." Here's HOW TO FIX (or what worked on my setup): As a privileged user (root), load the file "/etc/sysconfig/network-scripts/ifup-ppp" into your favorite editor and remove the "-detach" command line argument from the exec call to pppd towards the end of the file. Save changes, try again, and all should be well. Alternatively, you can look at the "-updetach" option in the pppd man page if you are so inclined to attempt to make it work with this option. I did not try this myself, so you're on your own. Do i get an honorary RHCE now? Beta-testers needed? >;^þ - gabriel a.k.a. gmelder
In addition to my proposed solution above, you may also need to do the following: Locate the line in /etc/sysconfig/network-scripts/ifup-ppp that reads as: exec /sbin/ppp-watch "${DEVICE}" "$@" (this is line 17 on my installation) and insert a # symbol at the beginning of that line to comment it out. ppp-watch attempts to provide on-demand functionality for a ppp link. Unfortunately, in this script, it only results in a contentious redundancy with pppd's default behavior, which is to wait in the background anyway, like the good little daemon that it is. NEVER give up. LMK what results you all get. - gabriel
I've just had a chance to try all of this. It did indeed fix the problem, at least on my 7.0 install. To re-iterate what the fix is: comment out the ppp-watch line. remove the -detach from the pppd line.
Please verify this with a newer version of Red Hat Enterprise Linux or Fedora Core and reopen it against the new version if it still occurs. Closing as "not a bug" for now.