Re: Re [expert] pppd dying unexpectedly
"D. R. Evans" wrote: If I kill the script-based bit, then I never get to the PAP. BOTH are necessary, which does seem faintly ridiculous. But perhaps not without precedent; this is, after all, USWest. (Maybe this whole thing has something to do with the takeover, since they are now QWest. But it's probably just a coinicidence. It's no good asking them. They don't seem to have a clue about much at all. In the course of the last three months I have contacted tech support three times. They didn't solve a single one of the problems.) That's because all the really talented people are not working for peanuts in tech support anymore. -Stephen- Keep in touch with http://mandrakeforum.com: Subscribe the "[EMAIL PROTECTED]" mailing list.
Re: Re [expert] pppd dying unexpectedly
"Stephen F. Bosch" wrote: "D. R. Evans" wrote: If I kill the script-based bit, then I never get to the PAP. BOTH are necessary, which does seem faintly ridiculous. But perhaps not without precedent; this is, after all, USWest. (Maybe this whole thing has something to do with the takeover, since they are now QWest. But it's probably just a coinicidence. It's no good asking them. They don't seem to have a clue about much at all. In the course of the last three months I have contacted tech support three times. They didn't solve a single one of the problems.) That's because all the really talented people are not working for peanuts in tech support anymore. -Stephen- There is a very good diagnostic-type page on setting up PPP at: http://www.linux-firewall-tools.com/linux/ There is/are serverl pages of step by step instructions on how to go about the process of figuring out just what the ISP expects to process during your login. It may be very useful in diagnosing just what is happening here. Cheers -- ICQ# 89345394 Mailto: [EMAIL PROTECTED] Keep in touch with http://mandrakeforum.com: Subscribe the "[EMAIL PROTECTED]" mailing list.
Re: Re [expert] pppd dying unexpectedly
Submitted 04-Sep-00 by D. R. Evans: No. It accepts the script based login just fine. It then changes gears to PAP. Most bizaare. (Maybe this whole thing has something to do with the takeover, since they are now QWest. ^ That being the case, it may be time to shop for a new ISP. Not only is their tech support clueless, even when dealing with OSes they officially support, but they are know for giving people instructions that only make their problems worse. They also seem to have this annoying lack of communication internally. The end result being conflicting instructions from various tech support reps. That said, I finally convinced my wife (a Windows user) last week that her internet connectivity problems were Qwest related. For one thing, Qwest shares too many POPs with other networks (the local POP is shared by Juno and Concentric). A change to Earthlink (on an old Mindspring POP) sent her troubles away. -- Anton GrahamGPG ID: 0x18F78541 [EMAIL PROTECTED] RSA key available upon request Authors (and perhaps columnists) eventually rise to the top of whatever depths they were once able to plumb. -- Stanley Kaufman PGP signature
Re [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Found it!! The geniuses at USWest added PAP authentication after the ordinary logon script. In other words, you have to go through the old logon sequence and then do a PAP dance that was never necessary before. Now why couldn't they have told me that instead of simply saying that Linux isn't supported One also wonders what is the point of bothering with PAP, since I've already sent exactly the same information via the terminal script. Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBObN3p2nXrLw2KRK4EQKtfgCdGAkVbEId4MiyvMucVR6VHchvxOYAoJ55 i9Qe3vFTuRFzxxjLpzFFtXRD =bDmn -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re: Re [expert] pppd dying unexpectedly
Submitted 04-Sep-00 by D. R. Evans: The geniuses at USWest added PAP authentication after the ordinary logon script. In other words, you have to go through the old logon sequence and then do a PAP dance that was never necessary before. Now why couldn't they have told me that instead of simply saying that Linux isn't supported One also wonders what is the point of bothering with PAP, since I've already sent exactly the same information via the terminal script. Because it's (apparently) throwing out the script based login. You never saw this under Windows because the DUN client automagically detects the authentication protocol in use. But at least you now know why they were hanging up on you :) -- Anton GrahamGPG ID: 0x18F78541 [EMAIL PROTECTED] RSA key available upon request You will pay for your sins. If you have already paid, please disregard this message. PGP signature
Re: Re [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4 Sep 00, at 11:35, Anton Graham wrote: One also wonders what is the point of bothering with PAP, since I've already sent exactly the same information via the terminal script. Because it's (apparently) throwing out the script based login. You never saw this under Windows because the DUN client automagically detects the authentication protocol in use. But at least you now know why they were hanging up on you :) No. It accepts the script based login just fine. It then changes gears to PAP. If I kill the script-based bit, then I never get to the PAP. BOTH are necessary, which does seem faintly ridiculous. But perhaps not without precedent; this is, after all, USWest. (Maybe this whole thing has something to do with the takeover, since they are now QWest. But it's probably just a coinicidence. It's no good asking them. They don't seem to have a clue about much at all. In the course of the last three months I have contacted tech support three times. They didn't solve a single one of the problems.) Doc -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBObRIymnXrLw2KRK4EQLB0wCg65Do2xsFM3mnqshtm7VyoCjnim8AoJLm SJRWgT0v+SHBxuwJ8j5Ahdp+ =C0tR -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re [expert] pppd dying unexpectedly
Bring up a console window, type man pppd Maybe set 'crtscts' or 'cdtrcts' or check if it is set wrong Check the idle variable, mabe it's just timing out? Not sure how you set up pppd to run, you may not have all the variables set right.
Re: [expert] pppd dying unexpectedly
Hey... this sounds like it could be it -- where are the timer settings, and why wouldn't it be setting the timer? -Stephen- Pierre Fortin wrote: Looking into the problem (before I saw this thread), it appears the problem is due to a timer popping early. Looking at the log of a successful connection, a 10 second timer gets set for initial modem handshaking, then a longer timer (75 seconds in his case: /etc/ppp/ppp.chatscript) for the actual login... In the failing attempts, the chatscript timer is not getting set, causing the initial 10 second timer to pop and kill the connection before it completes.
Re: [expert] pppd dying unexpectedly
I wrote: Hi Stephen, Today, I looked into a similar problem with my brother-in-law's machine... he just moved his office out of the house and into a real office. Looking into the problem (before I saw this thread), it appears the problem is due to a timer popping early. Looking at the log of a successful connection, a 10 second timer gets set for initial modem handshaking, then a longer timer (75 seconds in his case: /etc/ppp/ppp.chatscript) for the actual login... In the failing attempts, the chatscript timer is not getting set, causing the initial 10 second timer to pop and kill the connection before it completes. I'll look into this some more later; but thought it might be useful to post this now... Pierre Finally got the answer on this one... turns out when he moved, he plugged the modem into the wrong port and forgot to mention it until I quizzed him about the problem. So, the 10 second timer was the correct one to pop... To those whose connections fail, does the sighup occur when a timer expires (check your log's timestamps)...? I suspect so. Pierre Stephen Bosch wrote: So, Doc... have you confirmed that it is the ISP that is causing the problem? I hope I don't have to switch ISPs... there has to be a way of figuring out what they may have changed... And again -- *why* does it work when you dial with kppp? I think the answer resides elsewhere... -Stephen- - Original Message - From: D. R. Evans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 30, 2000 5:43 PM Subject: Re: [expert] pppd dying unexpectedly -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28 Aug 00, at 20:05, Anton Graham wrote: Submitted 28-Aug-00 by Stephen Bosch: And again -- that SIGHUP is damn peculiar -- who is sending it? I suspect that that is modem generated. Every modem i have ever owned generates a SIGHUP when the other end hangs up on it. That makes sense. If the ISP doesn't like the PPP handshaking for whatever reason (maybe USWest figures I'm running Linux so it should shut me up) then it probably causes the line to go down, thus causing the SIGHUP. Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOa2cGWnXrLw2KRK4EQKVaACfZHtExZWFQdoDOH6R1h+srOl6Eh4AoKif heaA7ftO1SgLFQwyi0Q9z62F =C6LE -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp -- -- Linux (Up 39 days) -- Reboots are for system upgrades... Currently running 124 processes; CPU activity: user=1.0%, system=0.4% Last reboot reason: Installed new BackUPS power supply. -- Linux (Up 40 days) -- Reboots are for system upgrades... Currently running 124 processes; CPU activity: user=1.0%, system=0.4% Last reboot reason: Installed new BackUPS power supply.
Re: [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1 Sep 00, at 10:56, Pierre Fortin wrote: I wrote: Hi Stephen, Today, I looked into a similar problem with my brother-in-law's machine... he just moved his office out of the house and into a real office. Looking into the problem (before I saw this thread), it appears the problem is due to a timer popping early. Looking at the log of a successful connection, a 10 second timer gets set for initial modem handshaking, then a longer timer (75 seconds in his case: /etc/ppp/ppp.chatscript) for the actual login... In the failing attempts, the chatscript timer is not getting set, causing the initial 10 second timer to pop and kill the connection before it completes. I'll look into this some more later; but thought it might be useful to post this now... Pierre Finally got the answer on this one... turns out when he moved, he plugged the modem into the wrong port and forgot to mention it until I quizzed him about the problem. So, the 10 second timer was the correct one to pop... To those whose connections fail, does the sighup occur when a timer expires (check your log's timestamps)...? I suspect so. I haven't had time to investigate any more at my end for the past few days, but hope to spend some time on it (and maybe Figure It Out) this weekend. Maybe I missed it, but where are these timers defined? It does seem pretty consistent that the SIGHUP happens two seconds after the PPP handshake starts. Doc -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOa/Yg2nXrLw2KRK4EQIsvwCeMBc8gCXh57tiuJy4Y4AZzeOlQeUAn2j0 8PZjxBALu5YWx2u0WxGTM33P =oK2/ -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re: [expert] pppd dying unexpectedly
So, Doc... have you confirmed that it is the ISP that is causing the problem? I hope I don't have to switch ISPs... there has to be a way of figuring out what they may have changed... And again -- *why* does it work when you dial with kppp? I think the answer resides elsewhere... -Stephen- - Original Message - From: D. R. Evans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 30, 2000 5:43 PM Subject: Re: [expert] pppd dying unexpectedly -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28 Aug 00, at 20:05, Anton Graham wrote: Submitted 28-Aug-00 by Stephen Bosch: And again -- that SIGHUP is damn peculiar -- who is sending it? I suspect that that is modem generated. Every modem i have ever owned generates a SIGHUP when the other end hangs up on it. That makes sense. If the ISP doesn't like the PPP handshaking for whatever reason (maybe USWest figures I'm running Linux so it should shut me up) then it probably causes the line to go down, thus causing the SIGHUP. Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOa2cGWnXrLw2KRK4EQKVaACfZHtExZWFQdoDOH6R1h+srOl6Eh4AoKif heaA7ftO1SgLFQwyi0Q9z62F =C6LE -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re: [expert] pppd dying unexpectedly
Hi Stephen, Today, I looked into a similar problem with my brother-in-law's machine... he just moved his office out of the house and into a real office. Looking into the problem (before I saw this thread), it appears the problem is due to a timer popping early. Looking at the log of a successful connection, a 10 second timer gets set for initial modem handshaking, then a longer timer (75 seconds in his case: /etc/ppp/ppp.chatscript) for the actual login... In the failing attempts, the chatscript timer is not getting set, causing the initial 10 second timer to pop and kill the connection before it completes. I'll look into this some more later; but thought it might be useful to post this now... Pierre Stephen Bosch wrote: So, Doc... have you confirmed that it is the ISP that is causing the problem? I hope I don't have to switch ISPs... there has to be a way of figuring out what they may have changed... And again -- *why* does it work when you dial with kppp? I think the answer resides elsewhere... -Stephen- - Original Message - From: D. R. Evans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 30, 2000 5:43 PM Subject: Re: [expert] pppd dying unexpectedly -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28 Aug 00, at 20:05, Anton Graham wrote: Submitted 28-Aug-00 by Stephen Bosch: And again -- that SIGHUP is damn peculiar -- who is sending it? I suspect that that is modem generated. Every modem i have ever owned generates a SIGHUP when the other end hangs up on it. That makes sense. If the ISP doesn't like the PPP handshaking for whatever reason (maybe USWest figures I'm running Linux so it should shut me up) then it probably causes the line to go down, thus causing the SIGHUP. Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOa2cGWnXrLw2KRK4EQKVaACfZHtExZWFQdoDOH6R1h+srOl6Eh4AoKif heaA7ftO1SgLFQwyi0Q9z62F =C6LE -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp -- -- Linux (Up 39 days) -- Reboots are for system upgrades... Currently running 124 processes; CPU activity: user=1.0%, system=0.4% Last reboot reason: Installed new BackUPS power supply.
Re: [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28 Aug 00, at 20:05, Anton Graham wrote: Submitted 28-Aug-00 by Stephen Bosch: And again -- that SIGHUP is damn peculiar -- who is sending it? I suspect that that is modem generated. Every modem i have ever owned generates a SIGHUP when the other end hangs up on it. That makes sense. If the ISP doesn't like the PPP handshaking for whatever reason (maybe USWest figures I'm running Linux so it should shut me up) then it probably causes the line to go down, thus causing the SIGHUP. Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOa2cGWnXrLw2KRK4EQKVaACfZHtExZWFQdoDOH6R1h+srOl6Eh4AoKif heaA7ftO1SgLFQwyi0Q9z62F =C6LE -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re: [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Do this make you want to laugh or to cry? I am now fairly sure that the fault is indeed with USWest/Qwest/whatever-the-dolts- want-to-call-themselves-today. I found another entity that runs PPP (a bunsiness, not an ISP) and I have no trouble connecting to the latter. One question, I notice that with the business, I see no PPP packets after I go through the log-in script; apparently it waits for some PPP packets from me. With USWest, I see PPP packets coming from them. Does this matter? (I'm guessing that it doesn't make any difference and that PPP can be started from either side. Right now I'm too tired after a day at work to look up the answer and thought I'd be lazy and simply ask.) I guess I'll be showing USWest the door. Doc Evans Hello, US WEST and Qwest recently merged and US WEST is now Qwest. Thank you for your e-mail. U S West does not support Linux. You need to contact them for support. If you have any other questions, call the tech support center at 1 888 777-9569. Qwest Internet Technical Support db -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOaxhFWnXrLw2KRK4EQKzVACg9dHBHldOL1E/TSTOXbL8D5aeetAAoJl9 BMyXmHErDaSi5NBJofu2gCiQ =luJQ -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re: [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I suppose before I give up entirely on the bozos at USWest, I should ask if anyone else in the Denver area is reading this and uses USWest as their ISP. If so, please e-mail me privately if you're interested in sharing your ppp configuration. Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOaxjg2nXrLw2KRK4EQKrogCdH/wzTBnGHE/9036aoIjIq6Y7n3wAnAvk 5+dKW2D+Msxuj9RdFziLnobD =O4Wi -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re: [expert] pppd dying unexpectedly
My word... I have been having exactly this same problem, and this is after a whole month of trouble-free operation... why is the damn thing dropping connections? I know this wasn't very helpful, but I want to add my name to the chorus. I expect to take another stab at this problem later in the week. Perhaps I'll have better luck. Further to the pppd problem (I swore I'd had enough for today, but of course, I kept wanting to try One More Thing). Spoken like a true geek. a. I have now installed the very lastest ppp from rpmfind; the same still happens. b. The failure occurs regardless of whether I am root or an ordinary user. c. the options file currently contains: lock crtscts defaultroute noauth debug kdebug 3 d. I have a somewhat more expansive log now: Aug 27 14:57:09 localhost pppd[928]: pppd 2.4.0 started by root, uid 0 Aug 27 14:57:10 localhost chat[929]: send (ATDT3034427097^M) Aug 27 14:57:10 localhost chat[929]: expect (CONNECT) Aug 27 14:57:30 localhost chat[929]: ATDT3034427097^M^M Aug 27 14:57:30 localhost chat[929]: CONNECT Aug 27 14:57:30 localhost chat[929]: -- got it Aug 27 14:57:30 localhost chat[929]: send (^M) Aug 27 14:57:30 localhost chat[929]: expect (name:) Aug 27 14:57:30 localhost chat[929]: 26400/ARQ/V34/LAPM/V42BIS^M Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: User Access Verification^M Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: Username: Aug 27 14:57:31 localhost chat[929]: -- got it Aug 27 14:57:31 localhost chat[929]: send (n7dr^M) Aug 27 14:57:31 localhost chat[929]: expect (word:) Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: Username: n7dr^M Aug 27 14:57:31 localhost chat[929]: Password: Aug 27 14:57:31 localhost chat[929]: -- got it Aug 27 14:57:31 localhost chat[929]: send (password goes here^M) Aug 27 14:57:31 localhost pppd[928]: Serial connection established. Aug 27 14:57:31 localhost kernel: ppp_ioctl: set dbg flags to 3 Aug 27 14:57:31 localhost kernel: ppp_ioctl: set flags to 3 Aug 27 14:57:31 localhost pppd[928]: Using interface ppp0 Aug 27 14:57:31 localhost pppd[928]: Connect: ppp0 -- /dev/modem Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set xasyncmap Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set xmit asyncmap Aug 27 14:57:31 localhost kernel: ppp_ioctl: set flags to 3 Aug 27 14:57:31 localhost kernel: ppp_ioctl: set mru to 5dc Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set rcv asyncmap Aug 27 14:57:33 localhost kernel: ppp: channel ppp0 closing. Aug 27 14:57:33 localhost pppd[928]: Hangup (SIGHUP) Aug 27 14:57:33 localhost pppd[928]: Modem hangup Aug 27 14:57:33 localhost pppd[928]: Connection terminated. Aug 27 14:57:34 localhost pppd[928]: Exit. The only thing that this suggests to me is perhaps that the "Hangup (SIGHUP)" does _not_ mean that a SIGHUP was received, but rather that one was sent to hang up the modem (i.e., it is an effect rather than a cause). In either case, it still isn't at all obvious what causes the essential failure to connect (or, perhaps, "failure to remain connected" is a better description). No, it's not clear at all. I haven't been getting the SIGHUP -- but I imagine that you get this since you turned debugging output on? Are you *sure* that pppd isn't receiving a SIGHUP? If it *is*, I would have no idea where that might be coming from... -Stephen-
Re: [expert] pppd dying unexpectedly
- Original Message - From: "Stephen Bosch" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 28, 2000 11:23 AM Subject: Re: [expert] pppd dying unexpectedly My word... I have been having exactly this same problem, and this is after a whole month of trouble-free operation... why is the damn thing dropping connections? I know this wasn't very helpful, but I want to add my name to the chorus. I expect to take another stab at this problem later in the week. Perhaps I'll have better luck. Further to the pppd problem (I swore I'd had enough for today, but of course, I kept wanting to try One More Thing). Spoken like a true geek. a. I have now installed the very lastest ppp from rpmfind; the same still happens. b. The failure occurs regardless of whether I am root or an ordinary user. c. the options file currently contains: lock crtscts defaultroute noauth debug kdebug 3 d. I have a somewhat more expansive log now: Aug 27 14:57:09 localhost pppd[928]: pppd 2.4.0 started by root, uid 0 Aug 27 14:57:10 localhost chat[929]: send (ATDT3034427097^M) Aug 27 14:57:10 localhost chat[929]: expect (CONNECT) Aug 27 14:57:30 localhost chat[929]: ATDT3034427097^M^M Aug 27 14:57:30 localhost chat[929]: CONNECT Aug 27 14:57:30 localhost chat[929]: -- got it Aug 27 14:57:30 localhost chat[929]: send (^M) Aug 27 14:57:30 localhost chat[929]: expect (name:) Aug 27 14:57:30 localhost chat[929]: 26400/ARQ/V34/LAPM/V42BIS^M Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: User Access Verification^M Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: Username: Aug 27 14:57:31 localhost chat[929]: -- got it Aug 27 14:57:31 localhost chat[929]: send (n7dr^M) Aug 27 14:57:31 localhost chat[929]: expect (word:) Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: Username: n7dr^M Aug 27 14:57:31 localhost chat[929]: Password: Aug 27 14:57:31 localhost chat[929]: -- got it Aug 27 14:57:31 localhost chat[929]: send (password goes here^M) Aug 27 14:57:31 localhost pppd[928]: Serial connection established. Aug 27 14:57:31 localhost kernel: ppp_ioctl: set dbg flags to 3 Aug 27 14:57:31 localhost kernel: ppp_ioctl: set flags to 3 Aug 27 14:57:31 localhost pppd[928]: Using interface ppp0 Aug 27 14:57:31 localhost pppd[928]: Connect: ppp0 -- /dev/modem Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set xasyncmap Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set xmit asyncmap Aug 27 14:57:31 localhost kernel: ppp_ioctl: set flags to 3 Aug 27 14:57:31 localhost kernel: ppp_ioctl: set mru to 5dc Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set rcv asyncmap Aug 27 14:57:33 localhost kernel: ppp: channel ppp0 closing. Aug 27 14:57:33 localhost pppd[928]: Hangup (SIGHUP) Aug 27 14:57:33 localhost pppd[928]: Modem hangup Aug 27 14:57:33 localhost pppd[928]: Connection terminated. Aug 27 14:57:34 localhost pppd[928]: Exit. The only thing that this suggests to me is perhaps that the "Hangup (SIGHUP)" does _not_ mean that a SIGHUP was received, but rather that one was sent to hang up the modem (i.e., it is an effect rather than a cause). In either case, it still isn't at all obvious what causes the essential failure to connect (or, perhaps, "failure to remain connected" is a better description). No, it's not clear at all. I haven't been getting the SIGHUP -- but I imagine that you get this since you turned debugging output on? Are you *sure* that pppd isn't receiving a SIGHUP? If it *is*, I would have no idea where that might be coming from... -Stephen- I have been doing some research. In general, ppp problems fall into four broad areas: 1. physical installation of modem wrong serial port, it's a winmodem, setserial config needed, IRQ conflicts, pnp not set up, linmodem drivers not installed 2. misconfiguration typos in username, password, chat script; missing info; incorrect DNS config 3. authentication wrong protocol selected, incorrect implementation of PPP on the ISP's end, weird app behavior (subtle changes in ppp, kppp, etc.) 4. hardware failure it's just broken I suspect the trouble here falls into area #3, and there are plenty of posts to the Mandrake usenet group that mirror this problem. The solution is to use "debug" and minicom to gather as much ionf about the connection as possible. Typically, the solutions offered are to try one or more of the following: Add noauth, asyncmap 0xa, defaultroute, noipdefault, noccp, nobsdcomp, novj, novjcomp, noaccomp, nopcomp one at a time to the options file and see waht happens. This remind me of my aotu mechanic, but it sometimes works. Try using a different authentication protocol (ie, CHAP instead of PAP). Ch
Re: [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28 Aug 00, at 12:56, Hoyt wrote: 1. physical installation of modem wrong serial port, it's a winmodem, setserial config needed, IRQ conflicts, pnp not set up, linmodem drivers not installed Nope. Modem works fine. I can talk to the device, dial out manually, all the usual stuff. (And of course it's still working OK under Windows.) 2. misconfiguration typos in username, password, chat script; missing info; incorrect DNS config Been through all this multiple times, and also have invoked pppd several ways. I couldn't have made the same mistake everywhere. 3. authentication wrong protocol selected, incorrect implementation of PPP on the ISP's end, weird app behavior (subtle changes in ppp, kppp, etc.) No authorization necessary. After going through the usual vanilla script logon manually (which works fine) I see the ppp packets coming from the other end. In fact, if I understand the messages in /var/log/messages correctly (always a big IF) ppp actually correctly sets several configuration parameters and completes the set of initial handshakes. It only dies _after_ that. I think. And, of course, Windows is working just fine. 4. hardware failure it's just broken Again, don't see how, if only because Windows is happy. I suspect the trouble here falls into area #3, and there are plenty of posts to the Mandrake usenet group that mirror this problem. The solution is to use "debug" and minicom to gather as much ionf about the connection as possible. 'Tis indeed the most likely. I bet that there's some weird trivial configuration parameter that has somehow got tweaked. Typically, the solutions offered are to try one or more of the following: Add noauth, asyncmap 0xa, defaultroute, noipdefault, noccp, nobsdcomp, novj, novjcomp, noaccomp, nopcomp one at a time to the options file and see waht happens. This remind me of my aotu mechanic, but it sometimes works. Will do this. noauth, defaultroute are already there. Try using a different authentication protocol (ie, CHAP instead of PAP). Well, doesn't "noauth" turn all this stuff off? I mean, I don't have any kind of a shared secret with my ISP, just the usual password at login time, so I don't see that any kind of further authentication is needed or even possible. Change to a scripted login. Not sure exactly what you mean. That's how I was logging in when the problem first appeared. Use something besides kppp (linuxconf, gppp, wvdial or configure the scripts by hand -- the problem is that only gppp and by hand supports CHAP if you need it, but the others can be forced to use it also). I've been doing it by hand, since that seems like the "closest to the metal" with less of a chance for something else to get in the way. Change to a different ISP. I don't think its their fault. I'll check with some other Linux users in the area, but I doubt that US West has been stupid enough (although I admit that they certainly do some pretty stupid things) to break Linux access. I'm not trying to put down any of the suggestions; just trying to explain where things stand. I tried a LOT of things before posting the request for help. (I mean, how hard can this stuff be, right?) ___ Well, here are some web resources: The PPP page at MandrakeUser.Org has some suggestions. http://mandrakeuser.org/connect/cppp5.html First place I looked. I'll try the other suggestions. Most of the documentation I've come across is about getting the modem configured correctly and/or being able to talk to the modem through the serial port, etc. All that seems to be working fine. Let's throw our collective efforts behind this. There are too many unsolved posts about this problem. It's going to turn out to be something really, really stupid. I just know it Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOaq32WnXrLw2KRK4EQKccwCffOujV5wTU1bq3E91/BofpZw9wZgAniMT xCI0sW5rGvXKWCBAoMU5EAqn =Hbwq -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re: [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 More info on the still-unsolved ppp problem (in the hope that a light will flash on over someone's head!): 1. The messages in the /var/log/messages file are completely reproducable. 2. After trying to bring up the link, ifconfig says: ppp0 Link encap:Point-to-Point Protocol POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 I don't knwo if there's a way to get more info from ifconfig, but the above _appears_ to be reasonable (from what little I know about this stuff). 3. The command line I'm using (to get rid of One More Variable -- kppp) looks like this: pppd connect 'chat -v "" ATDT3034427097 CONNECT "" name: n7dr word: password goes here' /dev/modem 115200 debug crtscts defaultroute The above is all on one line, and seems to give exactly the same result as kppp. (/dev/modem points to /dev/ttyS4, which is the correct device.) 4. Someone suggested that I try executing "ifup ppp0" as root. I couldn't find a man page on "ifup" but I tried it anyway. Got exactly the same set of error messages in the system log. 5. Someone else suggested I try ezppp. I'm going to go find that now and try to install run it later today. Can't say I'm hopeful, but I don't have any other brilliant ideas (or even any stupid ones). Doc Evans On 27 Aug 00, at 13:38, D. R. Evans wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 0. Running Mandrake 7.0, with no substantive changes (no kernel builds, etc.) 1. For months, I have had no kppp/ppp/pppd have seemed to work perfectly. 2. Several days passed when I didn't use them. (They worked fine last Tuesday; but on Saturday, disaster). 3. Now, whatever I do, pppd dies at some point during the opening negotiation. This is the most verbose version of the log that I can get: Aug 27 12:47:33 localhost chat[989]: expect (CONNECT) Aug 27 12:47:53 localhost chat[989]: ATDT3034427097^M^M Aug 27 12:47:53 localhost chat[989]: CONNECT Aug 27 12:47:53 localhost chat[989]: -- got it Aug 27 12:47:53 localhost chat[989]: send (^M) Aug 27 12:47:53 localhost chat[989]: expect (name:) Aug 27 12:47:53 localhost chat[989]: 26400/ARQ/V34/LAPM/V42BIS^M Aug 27 12:47:54 localhost chat[989]: ^M Aug 27 12:47:54 localhost chat[989]: ^M Aug 27 12:47:54 localhost chat[989]: User Access Verification^M Aug 27 12:47:54 localhost chat[989]: ^M Aug 27 12:47:54 localhost chat[989]: Username: Aug 27 12:47:54 localhost chat[989]: -- got it Aug 27 12:47:54 localhost chat[989]: send (n7dr^M) Aug 27 12:47:54 localhost chat[989]: expect (word:) Aug 27 12:47:54 localhost chat[989]: ^M Aug 27 12:47:54 localhost chat[989]: Username: n7dr^M Aug 27 12:47:54 localhost chat[989]: Password: Aug 27 12:47:54 localhost chat[989]: -- got it Aug 27 12:47:54 localhost chat[989]: send (password goes here^M) Aug 27 12:47:54 localhost pppd[988]: Serial connection established. Aug 27 12:47:54 localhost pppd[988]: Using interface ppp0 Aug 27 12:47:54 localhost pppd[988]: Connect: ppp0 -- /dev/modem Aug 27 12:47:56 localhost pppd[988]: Hangup (SIGHUP) Aug 27 12:47:56 localhost pppd[988]: Modem hangup Aug 27 12:47:56 localhost pppd[988]: Connection terminated. Aug 27 12:47:57 localhost pppd[988]: Exit. The "Hangup (SIGHUP)" is what seems to be the problem. I assume that this means that _something_ is sending pppd a SIGHUP, but what could it possibly be??? 4. Booting under Windows, PPP works perfectly. 5. If I manually talk to the serial port, I can dial the phone and log in, and see the ppp initialization packets coming. Eventually (since I can't send the right packets back when I am pretending to be an ordinary terminal) the phone line hangs up, but only after about 20 seconds. As you can see from the log, the ppp daemon is dying after only a couple of seconds. 6. Exactly the same happens if I do a command-line invocation of pppd/chat (in fact, that's how I got the error log). I'm less bothered by the fact that what used to work is no longer working (hey! I'm used to Windows, where that sort of thing happens all the time) than I am by the fact that I've spent several hours now, and haven't made any progress in getting this to work. (Amongst other things, I have reinstalled ppp and kppp, but that had no effect. I also tweaked every parameter I thought reasonable, and nothing improved the situation.) So I'm well and truly stumped. Any suggestions as to things to try are MOST WELCOME. Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOaluMmnXrLw2KRK4EQITUgCeJYF3MZXGtP/ID+WH7lm9BPXIpIkAniGe IqfjkBpcumOJEoUq9uvkK4FR =kDmZ -END PGP SIGNATURE-
Re: [expert] pppd dying unexpectedly
Hi, Doc: 3. The command line I'm using (to get rid of One More Variable -- kppp) looks like this: pppd connect 'chat -v "" ATDT3034427097 CONNECT "" name: n7dr word: password goes here' /dev/modem 115200 debug crtscts defaultroute The above is all on one line, and seems to give exactly the same result as kppp. (/dev/modem points to /dev/ttyS4, which is the correct device.) Meaning it works, right? It looks like only scripted pppd connections fail -- I had the same thing happen; on my box, kppp works fine. 4. Someone suggested that I try executing "ifup ppp0" as root. I couldn't find a man page on "ifup" but I tried it anyway. Got exactly the same set of error messages in the system log. This problem has got to be in pppd... 5. Someone else suggested I try ezppp. I'm going to go find that now and try to install run it later today. Can't say I'm hopeful, but I don't have any other brilliant ideas (or even any stupid ones). *cries* But does ezppp do demand dialing? *sigh* None of these options look like a real solution... something strange has happened somewhere... -Stephen-
Re: [expert] pppd dying unexpectedly
Hullo: I have been doing some research. In general, ppp problems fall into four broad areas: 1. physical installation of modem wrong serial port, it's a winmodem, setserial config needed, IRQ conflicts, pnp not set up, linmodem drivers not installed Modem works fine. It's been recognized by the system; it works with kppp without troubles; if I launch pppd manually from the command line it works too. 2. misconfiguration typos in username, password, chat script; missing info; incorrect DNS config Nothing changed there. As I said, it works fine in kppp. I've been over the config stuff 20 times... I should note that we started having failures after a dirty shutdown -- but I have NO idea where to look for damage... 3. authentication wrong protocol selected, incorrect implementation of PPP on the ISP's end, weird app behavior (subtle changes in ppp, kppp, etc.) But why does it work when you don't run it from the script? 4. hardware failure it's just broken Doesn't seem likely - the hardware works with everything else... I suspect the trouble here falls into area #3, and there are plenty of posts to the Mandrake usenet group that mirror this problem. The solution is to use "debug" and minicom to gather as much ionf about the connection as possible. You're probably right... but it's all very nebulous... somebody has got to know more about what's going on here... And again -- that SIGHUP is damn peculiar -- who is sending it? -Stephen-
Re: [expert] pppd dying unexpectedly
On Mon, 28 Aug 2000, Stephen Bosch wrote: Hi, Doc: 3. The command line I'm using (to get rid of One More Variable -- kppp) looks like this: pppd connect 'chat -v "" ATDT3034427097 CONNECT "" name: n7dr word: password goes here' /dev/modem 115200 debug crtscts defaultroute The above is all on one line, and seems to give exactly the same result as kppp. (/dev/modem points to /dev/ttyS4, which is the correct device.) Meaning it works, right? It looks like only scripted pppd connections fail -- I had the same thing happen; on my box, kppp works fine. 4. Someone suggested that I try executing "ifup ppp0" as root. I couldn't find a man page on "ifup" but I tried it anyway. Got exactly the same set of error messages in the system log. This problem has got to be in pppd... 5. Someone else suggested I try ezppp. I'm going to go find that now and try to install run it later today. Can't say I'm hopeful, but I don't have any other brilliant ideas (or even any stupid ones). Ok Obvious questions Did you change anything shortly before it went ga-ga? have you checked permissions on chat, pppd, /dev/ttys4 and /dev/modem? AG
Re: [expert] pppd dying unexpectedly
Quick question about the SIGHUP:
Only root can send signals to root processes, right? So, reboot in
single-user mode, then try pppd. See if it still gets the SIGHUP.
I mean, if there are no other programs, it *should* work, right? There
are no programs ('cept the kernel!) to give it the SIGHUP, so I imagine
it probably won't get it.
I hope this is turns out to be useful!
Good luck!
-- Asheesh.
Re: [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29 Aug 00, at 7:50, Andrew George wrote: Ok Obvious questions No question is too obvious for me to fail to think of it. In this case, however: Did you change anything shortly before it went ga-ga? No. have you checked permissions on chat, pppd, /dev/ttys4 and /dev/modem? Yes. I now have a request into USWest tech support. At this point I am about 85% that they've done something at their end. Although what, I have no idea. I do still need to try the process of adding options to the options file one at a time, though. Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOarXAGnXrLw2KRK4EQIh9wCfYmkDcFZmtaviEFPv5BgAw4RX/AgAoNeX NLdzQPs0xaVngQjZEapX3AZG =ZY6f -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re: [expert] pppd dying unexpectedly
Submitted 28-Aug-00 by Stephen Bosch: And again -- that SIGHUP is damn peculiar -- who is sending it? I suspect that that is modem generated. Every modem i have ever owned generates a SIGHUP when the other end hangs up on it. -- Anton GrahamGPG ID: 0x18F78541 [EMAIL PROTECTED] RSA key available upon request Outside of a dog, a book is man's best friend. Inside of a dog, it is too dark to read.
Re: [expert] pppd dying unexpectedly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Further to the pppd problem (I swore I'd had enough for today, but of course, I kept wanting to try One More Thing). a. I have now installed the very lastest ppp from rpmfind; the same still happens. b. The failure occurs regardless of whether I am root or an ordinary user. c. the options file currently contains: lock crtscts defaultroute noauth debug kdebug 3 d. I have a somewhat more expansive log now: Aug 27 14:57:09 localhost pppd[928]: pppd 2.4.0 started by root, uid 0 Aug 27 14:57:10 localhost chat[929]: send (ATDT3034427097^M) Aug 27 14:57:10 localhost chat[929]: expect (CONNECT) Aug 27 14:57:30 localhost chat[929]: ATDT3034427097^M^M Aug 27 14:57:30 localhost chat[929]: CONNECT Aug 27 14:57:30 localhost chat[929]: -- got it Aug 27 14:57:30 localhost chat[929]: send (^M) Aug 27 14:57:30 localhost chat[929]: expect (name:) Aug 27 14:57:30 localhost chat[929]: 26400/ARQ/V34/LAPM/V42BIS^M Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: User Access Verification^M Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: Username: Aug 27 14:57:31 localhost chat[929]: -- got it Aug 27 14:57:31 localhost chat[929]: send (n7dr^M) Aug 27 14:57:31 localhost chat[929]: expect (word:) Aug 27 14:57:31 localhost chat[929]: ^M Aug 27 14:57:31 localhost chat[929]: Username: n7dr^M Aug 27 14:57:31 localhost chat[929]: Password: Aug 27 14:57:31 localhost chat[929]: -- got it Aug 27 14:57:31 localhost chat[929]: send (password goes here^M) Aug 27 14:57:31 localhost pppd[928]: Serial connection established. Aug 27 14:57:31 localhost kernel: ppp_ioctl: set dbg flags to 3 Aug 27 14:57:31 localhost kernel: ppp_ioctl: set flags to 3 Aug 27 14:57:31 localhost pppd[928]: Using interface ppp0 Aug 27 14:57:31 localhost pppd[928]: Connect: ppp0 -- /dev/modem Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set xasyncmap Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set xmit asyncmap Aug 27 14:57:31 localhost kernel: ppp_ioctl: set flags to 3 Aug 27 14:57:31 localhost kernel: ppp_ioctl: set mru to 5dc Aug 27 14:57:31 localhost kernel: ppp_tty_ioctl: set rcv asyncmap Aug 27 14:57:33 localhost kernel: ppp: channel ppp0 closing. Aug 27 14:57:33 localhost pppd[928]: Hangup (SIGHUP) Aug 27 14:57:33 localhost pppd[928]: Modem hangup Aug 27 14:57:33 localhost pppd[928]: Connection terminated. Aug 27 14:57:34 localhost pppd[928]: Exit. The only thing that this suggests to me is perhaps that the "Hangup (SIGHUP)" does _not_ mean that a SIGHUP was received, but rather that one was sent to hang up the modem (i.e., it is an effect rather than a cause). In either case, it still isn't at all obvious what causes the essential failure to connect (or, perhaps, "failure to remain connected" is a better description). And now I well and truly am going to give up for the day. Five hours is way too much to spend on this sort of junk on a Sunday. Doc Evans -BEGIN PGP SIGNATURE- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: Key obtainable from servers: ID 0x362912B8 iQA/AwUBOamEUmnXrLw2KRK4EQI8tQCdEL5zmbbrUk+Cw8IA2HHyPliDygUAoM7S 7fans36M7wH50QDhjsPX1ILG =07dk -END PGP SIGNATURE- -- D.R. Evans N7DR / G4AMJ [EMAIL PROTECTED] The last of the Chronicles of the Three Lands, "Phendric", has been published: http://www.sff.net/people/N7DR/drevans.htp --
Re: [expert] pppd dying unexpectedly
Fredthere's a thread on this called "Kppp in Air" starting on Jan 21st. There's a bunch of suggestions for possible solutions in there to try out. Please let me know if any of them work as I'm still running 6.1 on my masquerade machine because of the same problem you're experiencing. Alan On Fri, 04 Feb 2000, you wrote: Hello All, I am new to this list, running Linux for a couple of years now, and recently installed LM7 Install went through okay (albeit a bit long), but I experienced problems with connecting to the internet via kppp. This is the fault report I got: The remote system is required to authenticate itself but I couldn't find any secret (password) which would let it use an IP address. I then uninstalled v7, installed Mandrake 6.1, made sure the internet was working, upgraded to v7 and experienced the same problems. Anyone familiar with the problem (and more importantly a solution)??? Help much appreciated. Regards Fred de Klein tel: 01908 656106 (w) 0780 8254445(mob) http://www.bigfoot.com/~klein_it http://www.bigfoot.com/~klein_it
