I'm getting an error modeprobe: can't locate char-major-108 when trying to login to my ISP using PAP.
I'm only using Intel.
This is merely pppd's support for the 2.3 kernel -- the fact that you are getting this message means that pppd will still work if you upgrade.
Upgrade what? I'm trying to log on and CAN'T. I only thing I see that prevents me from logging on is this message. Could you please be a little more explicit on a solution. Maybe the question sould be "can pppd dial into a ISP that uses PAP" every thing looks like I can connect fine but I get dropped. Then is see the message that I reported.
Sorry, I didn't notice the part that it wasn't working. People often complain about that message and I'm conditioned to seeing that and explaining that it isn't a bug. I promise you that message has absolutely nothing to do with the fact that PPP isn't working for you. It works fine with PAP, I have tested it with quite a few providers using PAP with no problems whatsoever. So the problem is not PAP. Make sure that you have the latest initscripts and ppp packages from our errata. If you have the latest and still have a problem, please try echo 'DEBUG=yes' >> /etc/sysconfig/network-scripts/ifcfg-ppp0 and see if that helps. (The upgrade I was referring to was the kernel -- if you chose to use the 2.3.x kernels, without that message you are seeing, pppd could not work. The message is caused by pppd checking to see whether a 2.3.x or 2.2.x kernel is there so that it can do the right thing. So you can ignore that part.)
Could not find any update to 6.1 redhat for ppp and I edited the script file and put in echo 'DEBUG=yes' and didn't see any messages that would help nor using that option help my connection. All I see is the following: Serial connection established Using interface ppp0 Connect: ppp0 <--> /dev/modem Hangup <SIGHUP> Modem hangup Connection terminated Exit I assume since this is not a bug you can't assist any further. Thanks for the help. js
The message is not a bug. The SIGHUP is either a bug or the modem hanging up. There IS an update for ppp (ppp-2.3.10-3) for Red Hat Linux 6.1. There is also an update for initscripts. You want both of them.
I have downloaded and installed the new pppd. But I have not been able to find the initscripts unless they are included int the RPM for pppd (ppp-2.3.10-3). This still has not corrected the problem. If I still need the initscripts. Were can I find them?
The initscripts update is a security update. It's on the web page with everything else.
Installed the update to the initscripts and it did not help.
One step at a time, I guess. The next step is: rpm -q initscripts rpm -V initscripts rpm -q ppp rpm -V ppp
rpm -q initscripts initscripts-4.70-1 rpm -V initscripts ..5....T c/etc/inittab S.5....T c/etc/sysconfig/network-scripts/ifcfg-lo rpm -q ppp ppp- 2.3.10-3 rpm -V ppp ..?..... c/etc/ppp/chap-secrets S.5....T c/etc/ppp/options S.?....T c/etc/ppp/pap-secrets missing /usr/doc/ppp-2.3.10/scripts/chatchat/README missing /usr/doc/ppp-2.3.10/scripts/chatchat/chatchat.c
Looking back over this, I see that you appear to have added echo 'DEBUG=yes' to the file /etc/sysconfig/network-scripts/ifcfg-ppp0. That wasn't what I suggested. I suggested the command echo 'DEBUG=yes' >> /etc/sysconfig/network-scripts/ifcfg-ppp0 which would add the line DEBUG=yes to the file /etc/sysconfig/network-scripts/ifcfg-ppp0 You might want to fix that and try again; we may get some useful output that helps me figure out where that SIGHUP is coming from. If that doesn't work, you can strace pppd by editing the file /etc/sysconfig/network-scripts/ifup-ppp and changing exec /usr/sbin/pppd [...] to exec strace -fo /tmp/ppp.$$.st /usr/sbin/pppd [...] so that we can see precisely what pppd is doing. You can create a new attachment (see the link under the Summary line) that includes the strace output. Note that "$$" in that line will be replaced with a pid -- that's so that if you do this multiple times, the strace output files won't overwrite each other.
Here is what my ifcfg-ppp0 file looks like: PERSIST=yes DEFROUTE=yes ONBOOT=no INITSTRING=ATZ MODEMPORT=/dev/modem LINESPEED=115200 ESCAPECHARS=no DEFABORT=yes HARDFLOWCTL=yes DEVICE=ppp0 PPPOPTIONS= DEBUG=no PAPNAME='jshivley' REMIP= IPADDR= BOOTPROTO=none MTU= MRU= DISCONNECTTIMEOUT= RETRYTIMEOUT= USERCTL=yes DEBUG=yes Here is the results I got from it: Dec 7 12:12:25 localhost modprobe: can't locate module char-major-108 Dec 7 12:12:25 localhost pppd[1350]: pppd 2.3.10 started by root, uid 0 Dec 7 12:12:25 localhost ifup-ppp: pppd started for ppp0 on /dev/modem at 115200 Dec 7 12:12:26 localhost chat[1360]: abort on (BUSY) Dec 7 12:12:26 localhost chat[1360]: abort on (ERROR) Dec 7 12:12:26 localhost chat[1360]: abort on (NO CARRIER) Dec 7 12:12:26 localhost chat[1360]: abort on (NO DIALTONE) Dec 7 12:12:26 localhost chat[1360]: abort on (Invalid Login) Dec 7 12:12:26 localhost chat[1360]: abort on (Login incorrect) Dec 7 12:12:26 localhost chat[1360]: send (ATZ^M) Dec 7 12:12:26 localhost chat[1360]: expect (OK) Dec 7 12:12:27 localhost chat[1360]: ATZ^M^M Dec 7 12:12:27 localhost chat[1360]: OK Dec 7 12:12:27 localhost chat[1360]: -- got it Dec 7 12:12:27 localhost chat[1360]: send (ATDT2205000^M) Dec 7 12:12:27 localhost chat[1360]: expect (CONNECT) Dec 7 12:12:27 localhost chat[1360]: ^M Dec 7 12:12:56 localhost chat[1360]: ATDT2205000^M^M Dec 7 12:12:56 localhost chat[1360]: CONNECT Dec 7 12:12:56 localhost chat[1360]: -- got it Dec 7 12:12:56 localhost chat[1360]: send (^M) Dec 7 12:12:56 localhost pppd[1350]: Serial connection established. Dec 7 12:12:56 localhost pppd[1350]: Using interface ppp0 Dec 7 12:12:56 localhost pppd[1350]: Connect: ppp0 <--> /dev/modem Dec 7 12:13:00 localhost pppd[1350]: Hangup (SIGHUP) Dec 7 12:13:00 localhost pppd[1350]: Modem hangup Dec 7 12:13:00 localhost pppd[1350]: Connection terminated. Dec 7 12:13:01 localhost pppd[1350]: Exit. Dec 7 12:13:01 localhost ifup-ppp: pppd started for ppp0 on /dev/modem at 115200 Dec 7 12:13:01 localhost modprobe: can't locate module char-major-108 Dec 7 12:13:01 localhost pppd[1361]: pppd 2.3.10 started by root, uid 0 Dec 7 12:13:02 localhost chat[1371]: abort on (BUSY) Dec 7 12:13:02 localhost chat[1371]: abort on (ERROR) Dec 7 12:13:02 localhost chat[1371]: abort on (NO CARRIER) Dec 7 12:13:02 localhost chat[1371]: abort on (NO DIALTONE) Dec 7 12:13:02 localhost chat[1371]: abort on (Invalid Login) Dec 7 12:13:02 localhost chat[1371]: abort on (Login incorrect) Dec 7 12:13:02 localhost chat[1371]: send (ATZ^M) Dec 7 12:13:02 localhost chat[1371]: expect (OK) Dec 7 12:13:02 localhost chat[1371]: ^M Dec 7 12:13:02 localhost chat[1371]: NO CARRIER Dec 7 12:13:02 localhost chat[1371]: -- failed Dec 7 12:13:02 localhost chat[1371]: Failed (NO CARRIER) Dec 7 12:13:02 localhost pppd[1361]: Connect script failed Dec 7 12:13:03 localhost pppd[1361]: Exit. Dec 7 12:13:03 localhost modprobe: can't locate module char-major-108 Dec 7 12:13:03 localhost ifup-ppp: pppd started for ppp0 on /dev/modem at 115200 Dec 7 12:13:03 localhost pppd[1372]: pppd 2.3.10 started by root, uid 0 Dec 7 12:13:04 localhost chat[1382]: abort on (BUSY) Dec 7 12:13:04 localhost chat[1382]: abort on (ERROR) Dec 7 12:13:04 localhost chat[1382]: abort on (NO CARRIER) Dec 7 12:13:04 localhost chat[1382]: abort on (NO DIALTONE) Dec 7 12:13:04 localhost chat[1382]: abort on (Invalid Login) Dec 7 12:13:04 localhost chat[1382]: abort on (Login incorrect) Dec 7 12:13:04 localhost chat[1382]: send (ATZ^M) Dec 7 12:13:04 localhost chat[1382]: expect (OK) Dec 7 12:13:05 localhost chat[1382]: ATZ^M^M Dec 7 12:13:05 localhost chat[1382]: OK Dec 7 12:13:05 localhost chat[1382]: -- got it Dec 7 12:13:05 localhost chat[1382]: send (ATDT2205000^M) Dec 7 12:13:05 localhost chat[1382]: expect (CONNECT) Dec 7 12:13:05 localhost chat[1382]: ^M Dec 7 12:13:25 localhost pppd[1372]: Terminating on signal 15. Dec 7 12:13:25 localhost chat[1382]: SIGTERM Dec 7 12:13:25 localhost pppd[1372]: Connect script failed Dec 7 12:13:26 localhost pppd[1372]: Exit. Here is the result of the strace; It errored and did not connect but this is what i edited and what I got. I used strace with -fo and -f -o got same result. Edited: if [ -n "$WVDIALSECT" ] ; then exec /usr/sbin/pppd -detach $opts $MODEMPORT $LINESPEED \ remotename $DEVICE ipparam $DEVICE \ linkname $DEVICE \ noauth \ ${PPPOPTIONS} \ connect "/usr/bin/wvdial --remotename $DEVICE --chat $WVDIALSECT" else exec strace -f -o /tmp/ppp.$$.st /usr/sbin/pppd -detach $opts $MODEMPORT $LINESPEED \ remotename $DEVICE ipparam $DEVICE \ linkname $DEVICE \ noauth \ ${PPPOPTIONS} \ connect "/usr/sbin/chat $chatdbg -f $CHATSCRIPT" fi Result : 1446 execve("/usr/sbin/pppd", ["/usr/sbin/pppd", "- detach", "lock", "modem", "crtscts", "asyncmap", "00000000", "defaultroute", "us epeerdns", "name", "jshivley", "debug", "/dev/modem", "115200", "remo tename", "ppp0", "ipparam", "ppp0", "linkname", "ppp0", "noauth", "connect", "/u sr/sbin/chat -v -f /etc/sysconfig/network-scripts/chat-ppp0"], [/* 31 vars */]) = 0 I Hope this will help. Thanks for all the help, John S
I need the entire strace output, not the one execve line. If you do not want to submit the entire thing here as an attachment, please send it to me via mail. Without it, I can't help.
When I ran "/sbin/ifup ppp0" with the trace, I got an error and did not connect as I stated above. I will try again but that is all I got. I what I canged correct.
Let me try that last part again. Is what I edited in the ifup-ppp correct? The ppp0 session fails ans I don't dial or connect with that in there.
The message I get is : Failed to activate ppp0 with error 1
Your editing of ifup-ppp was correct. Are you saying that the "1446" line was the ONLY line in the /tmp/ppp.*.st file that was created?
I have been having exactly the same problem, with identical error messages. ppp does seem to work fine when invoked directly using wvdial. When called through rp3 (for example) the SIGHUP occurs, and it goes into an infinite loop of dialing and hanging up. Likewise I am using the latest versions of ppp, rp3, initscripts, etc.
lowe: can you please rpm -q ppp to make absolutely sure that you have ppp-2.3.10-3? This really is typical of ppp-2.3.10-1 and jshivley is the first to report otherwise. Assuming that you do have ppp-2.3.10-3, I need the same thing from you as from jshivley in order to have a ghost of a chance of fixing it: full strace output from pppd. See the instructions here for how to get that output. Thanks! ------- Email From David Lowe <lowe.edu> 12/08/99 22:03 ------- Attached to Bug # 7509.
What I'm saying is this, ever since I have put in the strace this is what happens. When I run ifup ppp0 --- I get this --- Failed to activate ppp0 with error 1 The ony message I see in the message log is : Dec 9 08:39:25 localhost ifup-ppp: pppd started for ppp0 on /dev/modem at 115200 and I recieve the following in the trace file: 1446 execve("/usr/sbin/pppd", ["/usr/sbin/pppd", "- detach", "lock", "modem", "crtscts", "asyncmap", "00000000", "defaultroute", "us epeerdns", "name", "jshivley", "debug", "/dev/modem", "115200", "remo tename", "ppp0", "ipparam", "ppp0", "linkname", "ppp0", "noauth", "connect", "/u sr/sbin/chat -v -f /etc/sysconfig/network-scripts/chat-ppp0"], [/* 31 vars */]) = 0 1. Should I be seeing that error message when I run ifup? 2. Should I at least be able to dial and try to connect while using strace? If so I'm not. 3. Should I see only on trace log file per one dial attempt? not just one ifup run. ------- Email From "John Shivley" <jshivley> 12/09/99 11:27 ------- Attached to Bug # 7509.
1) that error indicates: 1 An immediately fatal error of some kind occurred, such as an essential system call failing, or run- ning out of virtual memory. However, your strace doesn't show that. 2) strace should not change your ability to dial. I'm rather confused -- is strace changing the behaviour of your system? 3) You should see one strace attempt per ifup run.
I sent you a e-mail with attachment with a good strace. I got it to dial and connect with rp3.
I still have the problem of the hang up. I hope you didn't think I meant every thing was fine from my last note. I only got strace to work. I hope you got my attachment. I have not heard from you and you usally reply back sooner.
I did not receive your email.
Did you get it this time?? Sent about 1 hour ago..
Yes, thanks. I'm a bit overloaded at the moment so it may be a few days before I can look at it... :-(
It has been 15 days and I was wondering what was up? Thanks
It has been over a month now. What is the status? Do you think it's a bug? Please at least let me know if someone is working on it. Thanks
I have similar problems! And it seems for me that there is lot of people having ...
Please attach your strace output to this bug report. I've inherited most of the PPP-related bugs and have been digging out from under a large pile of bugs for a couple of weeks now, and I'm just now getting to this one. Just to be sure, please verify that you have a line in /etc/ppp/pap-secrets of the form: jshivley ppp0 somepassword
Okay, I've just looked at the strace you'd already sent to bugzilla, and it looks like the modifications made to ifup-ppp are causing part of the problem with tracing. The quoting rules for the "connect" argument bing passed to pppd are causing pppd to exit immediately. The only way that will work is if you create a short script (for example, /etc/sysconfig/network-scripts/call-ppp0) that just runs a single command: /usr/sbin/chat -v -f /etc/sysconfig/network-scripts/chat-ppp0 And modify the line in ifup-ppp that reads: connect "/usr/sbin/chat $chatdbg -f $CHATSCRIPT" to instead read: connect "/etc/sysconfig/network-scripts/call-ppp0" If you've had success invoking pppd with wvdial, I'd suggest updating both rp3 and wvdial from Raw Hide to see if they make a difference. Until the latest releases, rp3 would use libraries from a modified wvdial, but the regular wvdial binary called by rp3 didn't have the correct patches applied. I'm a bit concerned about the section of the log that looks like this: 668 ioctl(12, SIOCGIFFLAGS, 0xbffff8f0) = -1 ENOSYS (Function not implemented) 668 ioctl(12, SIOCGIFFLAGS, 0xbffff8f0) = -1 ENOSYS (Function not implemented) 668 ioctl(12, SIOCGIFFLAGS, 0xbffff8f0) = -1 ENODEV (No such device) You're still running the kernel we ship, right? This looks like a failure getting information about local interfaces, and a strace on my test machine succeeds here.
I have attached a new strace with the most recent versions of rp3-1.0.7-2, ppp-2.3.11-3, wvdial-1.41-2, initscripts-4.89-1 Also I created a /dev/ppp node which was missing from my system, following command explained in README.linux in the ppp source. This seems to have fixed the "Function not implemented" error, but not the modem hangup. In case it is not clear from the previous messages, this problem occurs with other X-based dialer programs (kppp, xisp,...).
It seems I have managed to accidentally fix this bug on my machine. The changes I made had nothing obvious to do with ppp or rp3, so its rather puzzling everything should suddenly start working. Are others still having this problem?
I'm surprised that you were even able to open /dev/ppp while running a 2.2 kernel -- the test for the presence of that device is only in there for support for the new scheme used in 2.3 kernels, and if the check fails pppd falls back to doing things the way the 2.2 kernel expects it to. From looking at the strace log, it looks like the /etc/ppp/pap-secrets file was empty, and pppd was therefore failing to authenticate via PAP.
I had the same problem (SIGHUP just after connecting) with a machine of my customer. After many hours of work I realized that the bug disappeared after removing $LINESPEED parameter from the last line exec /usr/sbin/pppd -detach $opts $MODEMPORT $LINESPEED \ in /etc/sysconfig/network-scripts/ifup-ppp. Then it has been happy working for half a year, but the bug has returned 14 days ago. :-( If I can remember the computer was a 486 machine, with 16550A ports and some external Voice/Fax/Modem (Desk Porte?) and RH 6.1 with updates till March or April 2000. Also, there were no problems with the same hardware and Internet provider but when calling from another town. Had somebody the same problem which would disappear after upgrading to RH 6.2? Now I want to try using chat -t parameter.
Bug 7509 is being closed because most if not all problems were fixed by upgrading to later versions of Red Hat Linux. The problem does not seem to be in current releases of RHL.