ppp redial
how to set the ppp to redial when losting connection? thanks!
Re: ppp redial
how to set the ppp to redial when losting connection? in /etc/ppp/peers edit the file with the provider information (default is provider) and add persist maxfail N N is the number of attepmts to conenct before ppp gives up, set to 0 for never give-up. I've never used maxfail, so can not comment more on that... I did use persist and it works... Lazar
Re: ppp redial
thanks for the replies. I've uncommented persist in /etc/options and it works. Look into man pppd for persist option. :)
Re: ppp redial
I use x-isp, it re-dials when connection is lost... I guess other ppp front-ends have similar fuctionality erik Jack wrote: how to set the ppp to redial when losting connection? thanks! -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: ppp redial
Erik Steffl writes: I use x-isp, it re-dials when connection is lost... I guess other ppp front-ends have similar fuctionality No front-ends needed. Just give pppd the 'persist' option. You can do this in pppconfig: Go to 'Advanced' and select 'Persist'. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: ppp redial
that's true, I was just providing more info, I use x-isp because I can have a list of numbers, if one fails it calls another - AFAIK the ppp scripts provided with debian do not have this functionality - do they? (I haven't found anything that looked like it might provide the same functionality, but I haven't searched very hard) while we're at topic of ppp, I'd appreciate advices how to accomplish following the least obtrusive way: 1) start pppd (persist, use list of phone numbers) 2) show the /var/log/ppp.log (or equal info) until connected, then info disappears 3) users in given group can stop pppd, even if it was started by another user (would sudo help here?) 4) show very very small indicator of status - perhaps even use keyboard led (scroll lock, I never use that one) [most of these could be accomplished by existing programs and fairly simple shell/perl/whatever scripts but I hope somebody already have the whole thing figured out] of course, it has to be (mainly point 4) WM/desktop independent... (i.e. not part of some enlightenment panel or something) thanks in advance, erik John Hasler wrote: Erik Steffl writes: I use x-isp, it re-dials when connection is lost... I guess other ppp front-ends have similar fuctionality No front-ends needed. Just give pppd the 'persist' option. You can do this in pppconfig: Go to 'Advanced' and select 'Persist'. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
ppp redial problem
A weird thing is happening to my pppd. (version 2.2.0f-19) I added the persist option to /etc/ppp/options so that if the connection went down, it would immediately be brought back up again. However what happens is it attempts to dial and then stops short. It does this about three times and then stops. I thought maybe the modem wasn't re-initializing properly (It's a rather old ATT DataExpress 28.8) so I went to my chat script and added ath,atf before the dial string. ath should hang up my modem and atf should reinitialize it. I have checked these commands with the modem manual. This didn't work either. In fact I was unable to use pppd until I rebooted. (yes even stopping it and starting it again didn't work.) The odd thing was I could redial with minicom. So there is something wrong with pppd or my setup of it. The immediate emergency is gone. I have found a small program called pppupd which can watch the connection and bring it back up again if needed. This seems to be able to redial without any problems. Still I'd like to get to the bottom of the ppp problem if anyone has any ideas. -- Jaldhar
RE: ppp redial problem
-BEGIN PGP SIGNED MESSAGE- Why don't you try adding a wait or sleep command to the chatscript just before the dialout, or try a comma (,) between the numbers to see if it helps. It may be just sending the data too fast. Also. Normally atf doesn't reset the modem. It resets FACTORY DEFAULTS which can be off the wall and slow down or stop it from functioning properly until you get a good init string in it. ATZ re-initializes it to previous settings. ATV will show you a list of the current settings on the modem. This is if it uses the Hayes command set (Hayes compatable). On 11-Apr-97 Jaldhar H. Vyas wrote: A weird thing is happening to my pppd. (version 2.2.0f-19) I added the persist option to /etc/ppp/options so that if the connection went down, it would immediately be brought back up again. However what happens is it attempts to dial and then stops short. It does this about three times and then stops. I thought maybe the modem wasn't re-initializing properly (It's a rather old ATT DataExpress 28.8) so I went to my chat script and added ath,atf before the dial string. ath should hang up my modem and atf should reinitialize it. I have checked these commands with the modem manual. This didn't work either. In fact I was unable to use pppd until I rebooted. (yes even stopping it and starting it again didn't work.) The odd thing was I could redial with minicom. So there is something wrong with pppd or my setup of it. The immediate emergency is gone. I have found a small program called pppupd which can watch the connection and bring it back up again if needed. This seems to be able to redial without any problems. Still I'd like to get to the bottom of the ppp problem if anyone has any ideas. -- Jaldhar Have a good one. - -- Rick Jones E-Mail: Rick [EMAIL PROTECTED] Date: 11-Apr-97 Time: 02:34:42 - -- -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBM03bmAi+Ph+i3TgpAQGoSwP/XrONllnku+HLZk8ib6y67RvY0IQulnrV iMAXnpRxyJQFYccYpvSC9z40uL/eLV3dIcUo4I5Z97+anZ6LDp71C/63n3KLrORc 27K8bw8cKthw5GhQLP7JOpvvZal2fn/tOmXAUzIOAEcZa6hdtmKsEiJ9FjVkv6Gm VejI7l4yexY= =sA19 -END PGP SIGNATURE-
Re: ppp redial problem
On Fri, 11 Apr 1997 01:32:36 -0500 (EST), Jaldhar H. Vyas wrote: A weird thing is happening to my pppd. (version 2.2.0f-19) I added the persist option to /etc/ppp/options so that if the connection went down, it would immediately be brought back up again. However what happens is it attempts to dial and then stops short. It does this about three times and then stops. I thought maybe the modem wasn't re-initializing properly (It's a rather old ATT DataExpress 28.8) so I went to my chat script and added ath,atf before the dial string. ath should hang up my modem and atf should reinitialize it. I have checked these commands with the modem manual. This didn't work either. In fact I was unable to use pppd until I rebooted. (yes even stopping it and starting it again didn't work.) The odd thing was I could redial with minicom. So there is something wrong with pppd or my setup of it. The immediate emergency is gone. I have found a small program called pppupd which can watch the connection and bring it back up again if needed. This seems to be able to redial without any problems. Still I'd like to get to the bottom of the ppp problem if anyone has any ideas. -- Jaldhar -- Elite MicroComputers 908-541-4214 http://www.psychosis.com/emc/
Re: ppp redial problem
On Fri, 11 Apr 1997 01:32:36 -0500 (EST), Jaldhar H. Vyas wrote: A weird thing is happening to my pppd. (version 2.2.0f-19) I added the persist option to /etc/ppp/options so that if the connection went down, it would immediately be brought back up again. However what happens is it attempts to dial and then stops short. It does this about three times and then stops. I thought maybe the modem wasn't re-initializing properly (It's a rather old ATT DataExpress 28.8) so I went to my chat script and added ath,atf before the dial string. ath should hang up my modem and atf should reinitialize it. I have checked these commands with the modem manual. This didn't work either. In fact I was unable to use pppd until I rebooted. (yes even stopping it and starting it again didn't work.) The odd thing was I could redial with minicom. So there is something wrong with pppd or my setup of it. I'm seeing things like this once and awhile. I just went to a serial port that only provides Rx, Tx, RTS, and CTS. I have to set DTR ON all the timeon the modem, and it seems to work fine, but sometimes it will not redial correctly. It also takes it awhile to redial, where as before with full modem control it redialed right away when a connection was lost. lost. The immediate emergency is gone. I have found a small program called pppupd which can watch the connection and bring it back up again if needed. This seems to be able to redial without any problems. Still I'd like to get to the bottom of the ppp problem if anyone has any ideas. Where did you get this? -- Elite MicroComputers 908-541-4214 http://www.psychosis.com/emc/
Re: ppp redial problem
Are you using cua for your modem? Jaldhar H. Vyas wrote: A weird thing is happening to my pppd. (version 2.2.0f-19) I added the persist option to /etc/ppp/options so that if the connection went down, it would immediately be brought back up again. However what happens is it attempts to dial and then stops short. It does this about three times and then stops. I thought maybe the modem wasn't re-initializing properly (It's a rather old ATT DataExpress 28.8) so I went to my chat script and added ath,atf before the dial string. ath should hang up my modem and atf should reinitialize it. I have checked these commands with the modem manual. This didn't work either. In fact I was unable to use pppd until I rebooted. (yes even stopping it and starting it again didn't work.) The odd thing was I could redial with minicom. So there is something wrong with pppd or my setup of it. The immediate emergency is gone. I have found a small program called pppupd which can watch the connection and bring it back up again if needed. This seems to be able to redial without any problems. Still I'd like to get to the bottom of the ppp problem if anyone has any ideas. -- Lawrence Chim [EMAIL PROTECTED]
Re: ppp redial problem
On Fri, 11 Apr 1997, Lawrence Chim wrote: Are you using cua for your modem? You mean the modem device or something else? I am using /dev/modem which is symlinked to /dev/ttyS1 in pppd as well minicom and pppupd both of which redial correctly. -- Jaldhar
Re: ppp redial problem
On Fri, 11 Apr 1997, Dave Cinege wrote: I'm seeing things like this once and awhile. I just went to a serial port that only provides Rx, Tx, RTS, and CTS. I have to set DTR ON all the timeon the modem, and it seems to work fine, but sometimes it will not redial correctly. It also takes it awhile to redial, where as before with full modem control it redialed right away when a connection was lost. The puzzling thing to me is that minicom will work fine with the exact same init. Thats why I think the problem is in my pppd setup. Where did you get this? From some place whose address escapes me at the moment. If you are willing to wait till Monday I will package it in .deb format. -- Jaldhar
RE: ppp redial problem
On Fri, 11 Apr 1997, Rick wrote: -BEGIN PGP SIGNED MESSAGE- Why don't you try adding a wait or sleep command to the chatscript just before the dialout, or try a comma (,) between the numbers to see if it helps. It may be just sending the data too fast. Also. Normally atf doesn't reset the modem. It resets FACTORY DEFAULTS which can be off the wall and slow down or stop it from functioning properly until you get a good init string in it. ATZ re-initializes it to previous settings. ATV will show you a list of the current settings on the modem. This is if it uses the Hayes command set (Hayes compatable). Thanks I will try these suggestions. Based on my reading of the manual atf should have reinitialized the modem too but I or the manual could be wrong. As I mentioned before, minicom works fine so my guess is still there is something wrong in my pppd setup. -- Jaldhar
Re: ppp redial problem
On Fri, 11 Apr 1997, Jaldhar H. Vyas wrote: A weird thing is happening to my pppd. (version 2.2.0f-19) I added the persist option to /etc/ppp/options so that if the connection went down, it would immediately be brought back up again. However what happens is it attempts to dial and then stops short. It does this about three times and then stops. I thought maybe the modem wasn't re-initializing properly (It's a rather old ATT DataExpress 28.8) so I went to my chat script and added ath,atf before the dial string. ath should hang up my modem and atf should reinitialize it. I have checked these commands with the modem manual. This didn't work either. In fact I was unable to use pppd until I rebooted. (yes even stopping it and starting it again didn't work.) The odd thing was I could redial with minicom. So there is something wrong with pppd or my setup of it. The immediate emergency is gone. I have found a small program called pppupd which can watch the connection and bring it back up again if needed. This seems to be able to redial without any problems. Still I'd like to get to the bottom of the ppp problem if anyone has any ideas. -- Jaldhar I noticed something similar with pppd. I'm new to Debian, I'm just trying to install and configure it these days. At the moment I'm writing from and old Slackware, under which (pppd 2.1.2) I left the following lines as a remark in my ppp-connect file: # pppd connect 'chat -v \ #ATZ \ # OK ATFE1V1Q0L0C1D2K3S11=55S38=0S95=2 \ # OK ATL2X3DT220792 CONNECT' # # Without the long second string to the modem, re-connection succeeds, # otherwise pppd fails for any re-connection after the first, waiting for # answer from the modem and then claiming something about SIGHUP, till # reboot. I can't dial and connect but the first time if I also want to send the longer string ATFE1V1Q0L0C1D2K3S11=55S38=0S95=2 as modem initialization beside ATZ. (Here /dev/modem is a symbolic link to /dev/cua1.) Nicola Bernardelli [EMAIL PROTECTED] --- Please use [EMAIL PROTECTED] for messages from any kind of robot, such as mailing lists. From that address no autoresponse messages will return even when I'm not at home. ---
Re: ppp redial problem
Jaldhar H. Vyas [EMAIL PROTECTED] writes: You mean the modem device or something else? I am using /dev/modem which is symlinked to /dev/ttyS1 in pppd as well minicom and pppupd both of which redial correctly. I may be mistaken, but I think that this can cause problems in some cases, especially with respect to device locking. I think using a symlink means that in certain locking strategies which base the lockfile name on the file name, a program locking /dev/modem will use the lockfile /var/lock/dev.modem or something, while other programs which are trying to use ttyS1 will use /var/lock/dev.ttyS1. Both programs will think they have exclusive access to the device, and both will be wrong. This, at least, was my understanding of the danger of device symlinks. -- Rob
Re: ppp redial problem
Rob Browning wrote: Jaldhar H. Vyas [EMAIL PROTECTED] writes: You mean the modem device or something else? I am using /dev/modem which is symlinked to /dev/ttyS1 in pppd as well minicom and pppupd both of which redial correctly. I may be mistaken, but I think that this can cause problems in some cases, especially with respect to device locking. I think using a symlink means that in certain locking strategies which base the lockfile name on the file name, a program locking /dev/modem will use the lockfile /var/lock/dev.modem or something, while other programs which are trying to use ttyS1 will use /var/lock/dev.ttyS1. Both programs will think they have exclusive access to the device, and both will be wrong. Please don't let me start another editor snowball here. What is the difference between /dev/ttyS0 and /dev/cua0? Thanx -- Greg. -- Greg Vence | Debian GNU Linux KH2EA/4 | Diamond 2000 (7npw 4cpw) [EMAIL PROTECTED]| There is time for what's important
Re: ppp redial problem
Greg Vence [EMAIL PROTECTED] writes: Please don't let me start another editor snowball here. What is the difference between /dev/ttyS0 and /dev/cua0? I think this is (or should be) a FAQ somewhere, but the short story is that the cua* devices are only kept around in the kernel for historical and backward compatibility purposes. The maintainer for these devices asks that they not be used, and that the ttyS* devices be used instead. The maintainer also claims that the code for the cua* devices is not being actively maintained. -- Rob
Re: ppp redial problem
-BEGIN PGP SIGNED MESSAGE- It's my understanding that /dev/cua* is outdated and only used for backward compatability. /dev/ttyS* is the correct usage. Which both belong to dialout. On 11-Apr-97 Greg Vence wrote: Rob Browning wrote: Jaldhar H. Vyas [EMAIL PROTECTED] writes: You mean the modem device or something else? I am using /dev/modem which is symlinked to /dev/ttyS1 in pppd as well minicom and pppupd both of which redial correctly. I may be mistaken, but I think that this can cause problems in some cases, especially with respect to device locking. I think using a symlink means that in certain locking strategies which base the lockfile name on the file name, a program locking /dev/modem will use the lockfile /var/lock/dev.modem or something, while other programs which are trying to use ttyS1 will use /var/lock/dev.ttyS1. Both programs will think they have exclusive access to the device, and both will be wrong. Please don't let me start another editor snowball here. What is the difference between /dev/ttyS0 and /dev/cua0? Thanx -- Greg. -- Greg Vence | Debian GNU Linux KH2EA/4 | Diamond 2000 (7npw 4cpw) [EMAIL PROTECTED]| There is time for what's important Have a good one. - -- Rick Jones E-Mail: Rick [EMAIL PROTECTED] Date: 11-Apr-97 Time: 14:10:48 - -- -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBM05+qAi+Ph+i3TgpAQEHhQP+KdRy78aKufU0ksRrGDtTa73KrbAIulDV P/yZsjNs7+8l6708pnLI6JWF6Khdmaiykxdn5qrHzXBjYXxo3Hw9CzIB3xnGGwPA 5qTk8ebnX6pNY2/0epCJHZiX/LfOrT/3De11sqdn3l3DYZ0zyGxsgwpWrh4j5U/L KYzRP72oj2I= =nFSi -END PGP SIGNATURE-
RE: ppp redial problem
-BEGIN PGP SIGNED MESSAGE- Well, actually the manual isn't wrong. ATF does reset the modem but to FACTORY DEFAULTS. ATZ re-initializes the modem to the prior settings. If the factory sets the defaults to no compression, no error checking, and software handshaking for example and minicom, which sends an init string, sets compression to on with error checking and hardware handshaking and you send atf to the modem in pppd the modem will stop compression etc... because it will return to the factory settings. If pppd sends atz the modem is reset to the last settings used by minicom for example. You could try running minicom, write down the init string in the serial configuration, then run pppd with an atz string. If minicom's init string makes pppd work then change the atz in your chatscript to the init string from minicom. I hope this wasn't too cryptic. On 11-Apr-97 Jaldhar H. Vyas wrote: On Fri, 11 Apr 1997, Rick wrote: -BEGIN PGP SIGNED MESSAGE- Why don't you try adding a wait or sleep command to the chatscript just before the dialout, or try a comma (,) between the numbers to see if it helps. It may be just sending the data too fast. Also. Normally atf doesn't reset the modem. It resets FACTORY DEFAULTS which can be off the wall and slow down or stop it from functioning properly until you get a good init string in it. ATZ re-initializes it to previous settings. ATV will show you a list of the current settings on the modem. This is if it uses the Hayes command set (Hayes compatable). Thanks I will try these suggestions. Based on my reading of the manual atf should have reinitialized the modem too but I or the manual could be wrong. As I mentioned before, minicom works fine so my guess is still there is something wrong in my pppd setup. -- Jaldhar Have a good one. - -- Rick Jones E-Mail: Rick [EMAIL PROTECTED] Date: 11-Apr-97 Time: 14:21:28 - -- -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBM06BKAi+Ph+i3TgpAQERiQQArXVc1iA5tW5VUgQavwAbnNUCGBzA+1HR ojnd5ark15/uc+kD5cZExaqg6H/Xxy2dSN9TfkspSZx6kyAw5Qaihbo5GofZJPy6 f59Su3GP/MfYKrhDxiqZ7Sp2avxcsp/zDN9YqEmpa2e4t857uCFmLFomcl1w1ZSC 6GDgYIBSmqM= =+lCH -END PGP SIGNATURE-
