Hi, My Dad has asked me to help with a dialup connection problem to ValueNet. He has Mandrake 9.0 and it works fine when connecting to Xtra. connection. The ValueNet connection also works fine from a win95 PC. From the log it appears that PPP is not starting: Valuenet with correct login data (same result with incorrect user name or password) Jun 24 20:50:03 localhost pppd[2645]: pppd 2.4.1 started by trevor, uid 1001 Jun 24 20:50:03 localhost pppd[2645]: using channel 38 Jun 24 20:50:03 localhost pppd[2645]: Using interface ppp0 Jun 24 20:50:03 localhost pppd[2645]: Connect: ppp0 <--> /dev/ham Jun 24 20:50:03 localhost pppd[2645]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe86fb3e4> <pcomp> <accomp>] Jun 24 20:50:06 localhost pppd[2645]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe86fb3e4> <pcomp> <accomp>] Jun 24 20:50:33 localhost pppd[2645]: LCP: timeout sending Config-Requests Jun 24 20:50:33 localhost pppd[2645]: Connection terminated. Jun 24 20:50:33 localhost pppd[2645]: Receive serial link is not 8-bit clean: Jun 24 20:50:33 localhost pppd[2645]: Problem: all had bit 7 set to 0 Jun 24 20:50:33 localhost pppd[2645]: Exit. Does anyone have a working linux dialup connection to ValueNet? If so would you be able to let me know what configuration is required? Anyone else got any ideas? TIA g -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
* Glenn Ramsey <glenn(a)componic.co.nz> [2004-06-26 10:25]:
Jun 24 20:50:03 localhost pppd[2645]: pppd 2.4.1 started by trevor, uid 1001 Jun 24 20:50:03 localhost pppd[2645]: using channel 38 Jun 24 20:50:03 localhost pppd[2645]: Using interface ppp0 Jun 24 20:50:03 localhost pppd[2645]: Connect: ppp0 <--> /dev/ham
PPP was launched and is getting ready to talk.
Jun 24 20:50:03 localhost pppd[2645]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe86fb3e4> <pcomp> <accomp>] Jun 24 20:50:06 localhost pppd[2645]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xe86fb3e4> <pcomp> <accomp>] Jun 24 20:50:33 localhost pppd[2645]: LCP: timeout sending Config-Requests
But the remote end is not replying.
Jun 24 20:50:33 localhost pppd[2645]: Connection terminated.
So the connection gets closed.
Jun 24 20:50:33 localhost pppd[2645]: Receive serial link is not 8-bit clean: Jun 24 20:50:33 localhost pppd[2645]: Problem: all had bit 7 set to 0
This is apparently the culprit: seems like the serial line (or the modem?) is not correctly configured (line speed, data bits, stop bits, and whatever else there was). I can't help any more precisely, since it's been nearly a decade since I put my modem to rest, but maybe that helps. Have you tried googling these errors? A query like "pppd lcp timeout link 8-bit clean" or something should yield a result or two that may get you somewhere. Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
On Sun, Jun 27, 2004 at 07:37:20PM +0200, A. Pagaltzis wrote:
Jun 24 20:50:33 localhost pppd[2645]: Receive serial link is not 8-bit clean: Jun 24 20:50:33 localhost pppd[2645]: Problem: all had bit 7 set to 0
This is apparently the culprit: seems like the serial line (or the modem?) is not correctly configured (line speed, data bits, stop bits, and whatever else there was).
I've seen this error message before. pppd gives some of the most useless diagnostic messages I've ever seen. pppd will give you a message about not being 8-bit clean/all bytes had bit7 set to 0 if it receives no data at all! It took me ages and ages to diagnose a dial-up problem. Eventually I figured out that I was getting the above error message because no data at all was being sent by the remote machine. My isp had changed the dial-up number, but either they'd left some modems answering on the old number (that would answer the line and never reply), or someone else craftily got that number and now has a bunch of ISP username/password pairs... Either way, try using a program like minicom to give commands directly to the modem which might help diagnose what is happening when you dial in. Extremely brief walkthrough (in case you don't know how to use minicom): type: ATDT(isp phone number) then presumably the remote end will ask for your username and password. If you successfully log in, then it should start ppp and print out lots of random characters/punctuation... John McPherson
I've seen the same error before too. My wife's win2k machine has it's own modem in case the linux dialup box goes down. Took a while to figure out what was going on but I had both modems plugged into the same jack. As soon as I unplugged her modem pppd ran as usual Wierd Jodi On Mon, 2004-06-28 at 08:33, John R. McPherson wrote:
On Sun, Jun 27, 2004 at 07:37:20PM +0200, A. Pagaltzis wrote:
Jun 24 20:50:33 localhost pppd[2645]: Receive serial link is not 8-bit clean: Jun 24 20:50:33 localhost pppd[2645]: Problem: all had bit 7 set to 0
This is apparently the culprit: seems like the serial line (or the modem?) is not correctly configured (line speed, data bits, stop bits, and whatever else there was).
______________________________________________________________________ _______________________________________________ wlug mailing list | wlug(a)list.waikato.ac.nz Unsubscribe: http://list.waikato.ac.nz/mailman/listinfo/wlug
-- --------------------------------------------------------------------------------------------------- Jodi W. Anderson, Mr (BA, A+, MCP) - Computer Systems Consultant Waikato University Library - Computing Operations Group Ph: +64 7 838 4323 email: jodi(a)waikato.ac.nz "Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before."
Thanks for all your suggestions. A few seemed promising but none worked. I was there yesterday and had a play with minicom and kppp and we did get it to connect and start ppp but it was very weird. Here's what happens. In minicom you get: atdt086733444 ... login: username password:<password> now I'd expect to see something like ~(&*%$%*()&)&*%$&*%^ but nothing happens, it's as if the username/password is wrong, but it isn't. The ppp log also indicates that ppp is not starting when dialing with kppp. Here's the weird thing: in kppp we put a Expect ~ / Send <nothing> in the chat script because that's what the howto said to do if it looks like ppp is taking a while to start up on the server. No go. Then we took off the Send <nothing> and just had Expect <any old string>. This caused the chat script to time out waiting for the string and redial. On the second try it connects OK. If the connection is stopped and you try to reconnect then it does the same thing ie dials a second time and connects on the 2nd try. The other puzzling thing is that it used to work fine and as far we know nothing had been changed. He currently has an internal Intel ham modem and I'm wondering if there is something going on with that, like an intermittant hardware failure. The next thing we are going try is an external modem. Any more ideas? g -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
On Tue, Jun 29, 2004 at 10:27:17AM +1200, Glenn Ramsey wrote:
login: username password:<password>
now I'd expect to see something like ~(&*%$%*()&)&*%$&*%^ but nothing happens, it's as if the username/password is wrong, but it isn't. The ppp log also indicates that ppp is not starting when dialing with kppp.
Here's the weird thing: in kppp we put a Expect ~ / Send <nothing> in the chat script because that's what the howto said to do if it looks like ppp is taking a while to start up on the server. No go.
Then we took off the Send <nothing> and just had Expect <any old string>. This caused the chat script to time out waiting for the string and redial. On the second try it connects OK. If the connection is stopped and you try to reconnect then it does the same thing ie dials a second time and connects on the 2nd try.
Any more ideas?
When I had problems dialing up to an isp, it would sometimes work and sometimes not work. This was because the isp had a fairly large modem pool, and had at least two types of modems answering, or at least sets of modems with different setups - if the call was answered by certain modems, things would go ok, but if answered by some other modems we couldn't connect. Also, make sure that your dialup ppp config has "noauth" set, otherwise ppp tries to make the remote end authenticate to you. However you'd get better error messages if this is what's happening to you, but it can't hurt to make sure this is disabled. John McPherson
My bet would be that you shouldn't use plaintext login at all. Most ISPs use something similar to mgettys autoppp feature, to listen for PPP frames coming from the subscriber before presenting a login prompt. If you wait for the CONNECT string in the chat script, then bail back to pppd and give pppd a 'user' parameter matching that with your fathers passwords in /etc/ppp/pap-secrets, you might find an improvement. Below i've pasted the contents of debians /etc/chatscripts/pap Cheers James /etc/chatscripts/pap: # You can use this script unmodified to connect to sites which allow # authentication via PAP, CHAP and similar protocols. # This script can be shared among different pppd scripts. # To use it, add something like this to your /etc/ppp/peers/ file: # # connect "/usr/sbin/chat -v -f /etc/chatscripts/pap -T PHONE-NUMBER" # user YOUR-USERNAME-IN-PAP-SECRETS # noauth # Uncomment the following line to see the connect speed. # It will be logged to stderr or to the file specified with -r . #REPORT CONNECT ABORT BUSY ABORT VOICE ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT "NO DIAL TONE" "" ATZ OK ATDT\T CONNECT "" ----- Original Message ----- From: "Glenn Ramsey" <glenn(a)componic.co.nz> To: "Waikato Linux Users Group" <wlug(a)list.waikato.ac.nz> Sent: Tuesday, June 29, 2004 10:27 AM Subject: Re: [wlug] Trouble connecting linux to ValueNet
Thanks for all your suggestions. A few seemed promising but none worked. I was there yesterday and had a play with minicom and kppp and we did get it to connect and start ppp but it was very weird.
Here's what happens.
In minicom you get: atdt086733444 ... login: username password:<password>
now I'd expect to see something like ~(&*%$%*()&)&*%$&*%^ but nothing happens, it's as if the username/password is wrong, but it isn't. The ppp log also indicates that ppp is not starting when dialing with kppp.
Here's the weird thing: in kppp we put a Expect ~ / Send <nothing> in the chat script because that's what the howto said to do if it looks like ppp is taking a while to start up on the server. No go.
Then we took off the Send <nothing> and just had Expect <any old string>. This caused the chat script to time out waiting for the string and redial. On the second try it connects OK. If the connection is stopped and you try to reconnect then it does the same thing ie dials a second time and connects on the 2nd try.
The other puzzling thing is that it used to work fine and as far we know nothing had been changed. He currently has an internal Intel ham modem and I'm wondering if there is something going on with that, like an intermittant hardware failure. The next thing we are going try is an external modem.
Any more ideas?
g
-- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
_______________________________________________ wlug mailing list | wlug(a)list.waikato.ac.nz Unsubscribe: http://list.waikato.ac.nz/mailman/listinfo/wlug
James Spooner wrote:
My bet would be that you shouldn't use plaintext login at all.
Most ISPs use something similar to mgettys autoppp feature, to listen for PPP frames coming from the subscriber before presenting a login prompt.
If you wait for the CONNECT string in the chat script, then bail back to pppd and give pppd a 'user' parameter matching that with your fathers passwords in /etc/ppp/pap-secrets, you might find an improvement.
Thanks James, that was it, he has it working now. He simply created a new PAP connection in kppp without a chat script. The first time he dialed it asked for his username/pw and now it works. All of the preloaded (by DSE) dialups had chat based login so we thought that was how it was supposed be set up. I've always used Debian's pppconfig which has always just worked and I've never had to think about it. He has stopped muttering about going back to windows :-). Thanks everyone else too for your suggestions. Cheers g -- Glenn Ramsey <glenn(a)componic.co.nz> 07 8627077 http://www.componic.co.nz
participants (5)
-
A. Pagaltzis -
Glenn Ramsey -
James Spooner -
Jodi Anderson -
John R. McPherson