DSL connection drops and then is no longer useable
Hi All! I have SuSE 8.0 which I did an online update using Yast2. I am connecting to my German ISP 1und1 using a Fritz DSL card. Often when the line is idle and the connection drops, I am no longer able to reconnect. The command I use to conncetion is: /usr/sbin/pppd call t-dsl Essentially all I get is capiplugin: disconnect(remote): "" -> "" outgoing (pcli=0x102/ncci=0x10102) 0x0000 (0x0000) - No additional information capiplugin: couldn't make connection At that point the only thing left to do is reboot. I have tried dropping into single-user mode (hoping that I overlooked something in a start-up script), but that did not help. I also tried unloading modules like capi* or fcdsl, hoping that there was a glitch there. However, that keep giving me "Device or resource busy" and I really don't have the patience to tryin 862 different combinations until I get the order right as rebooting is quicker. However, this ain't Windows! So the first question is whether anyone knows why the connection won't come back up and what to do about it. Or, is there a way of unloading and then reloading the drivers that is easy and keeps me from having to reboot. Any help would be greatly appreaciated. Regards, jimmo With debugging enabled I get : Plugin userpass.so loaded. userpass: $Revision: 1.3 $ Plugin capiplugin.so loaded. capiplugin: $Revision: 1.27 $ capiconn: 1.7 capiplugin: phase serialconn. loading adsl parameters from /etc/drdsl/adsl.conf ... capiplugin: contr=2 controller 2: listen_change_state 0 -> 1 contr 2: listenconf Info=0x0000 (No additional information) infomask=0x144 cipmask=0x0 capimask2=0x0 controller 2: listen_change_state 1 -> 0 plci_change_state:0x0 0 -> 1 event=1 capiplugin: leased line (adslpppoe) plci_change_state:0x102 1 -> 2 event=3 plci_change_state:0x102 2 -> 3 event=6 ncci_change_state:0x102 0 -> 1 event=1 ncci_change_state:0x10102 1 -> 3 event=3 ncci_change_state:0x10102 3 -> 7 event=10 ncci_change_state:0x10102 7 -> 0 event=13 plci_change_state:0x102 3 -> 7 event=8 plci_change_state:0x102 7 -> 8 event=9 plci_change_state:0x102 8 -> 0 event=11 capiplugin: disconnect(remote): "" -> "" outgoing (pcli=0x102/ncci=0x10102) 0x0000 (0x0000) - No additional information capiplugin: couldn't make connection controller 2: listen_change_state 0 -> 1 contr 2: listenconf Info=0x0000 (No additional information) infomask=0x144 cipmask=0x0 capimask2=0x0 controller 2: listen_change_state 1 -> 0 capiplugin: exit /etc/ppp/peers/t-dsl looks like this: # Verbindung zu T-DSL über die Fritz!Card DSL debug sync noauth defaultroute replacedefaultroute usepeerdns lcp-echo-interval 5 lcp-echo-failure 3 lcp-max-configure 50 lcp-max-terminate 2 noccp noipx # persist #demand connect "" # mru 1490 mtu 1490 ipcp-accept-local ipcp-accept-remote # # # plugin userpass.so # # Anschlußkennung T-Online-Nummer Mitbenutzerkennung # \ | / # user 000000000000\#000000000000\#0001\#@t-online.de user XXXXXXXXXXXXXXXXXXXXXXX password XXXXXXXXXXXXXXXXXXXXX linkname t-dsl ipparam internet plugin capiplugin.so avmadsl : /dev/null /etc/drdsl/adsl.conf: controller 2 protocol adslpppoe vpi 1 vci 32 -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi James. Is your DSL on a segrated or shared line, aka piggybacking on the phoneline of has a seperate dedicated line for the DSL? If it's piggybacking you might want to get a filter, or there are some devices (or perhaps a program) that periodically pings the servers, or similar, to fool it into thinking there's activity when you not (e.g. Idle and no packets, data exchanged triggers a disconnect after a certain time by the ISP, especially true with dial up's that do this to conserve bandwidth and ip addresses). Also, I'm guessing here, because I have a cable modem/line that is in an always on state. So, when I do get similar behavior (similar to a virtual disconnect) I issue "rcinetd restart" and that sometimes helps. - From the logs it looks like you being disconnected automatically by the ISP for being Idle. Then there also seems to be a problem (potentially on your/SuSE end) with reconnect because you machine didn't issue the disconnect the ISP did. So, perhaps, this is causing the system to issue some sort of secondary call (instead of the default connect request/protocals) and this is recognized as a second machine/connection by you ISP and hence it refuses to allow a connect. It could also be due to old phones with shaky signal strengths, and when your idle you lose your connect due to this... I don't know - just tossing about a few ideas. I'm just guessing here. There are far more Network capable and experienced on the list than I. Cheers, Curtis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+fChq7WVLiDrqeksRAlxvAKDeqKir62MtYBC93sce/z7I+V7gFQCgv8Ut A6l/vkD8lOB/nF6K87UQw5A= =TzJL -----END PGP SIGNATURE-----
Hi Curtis! Thanks for your reply. Comments are below. On Saturday 22 March 2003 10:09, Curtis Rey wrote:
Hi James. Is your DSL on a segrated or shared line, aka piggybacking on the phoneline of has a seperate dedicated line for the DSL? If it's piggybacking you might want to get a filter, or there are some devices (or perhaps a program) that periodically pings the servers, or similar, to fool it into thinking there's activity when you not (e.g. Idle and no packets, data exchanged triggers a disconnect after a certain time by the ISP, especially true with dial up's that do this to conserve bandwidth and ip addresses).
I have an ISDN connection and the DSL card is connected to the NTBA. I also have a switch box for the phone systems (up to 8 non-ISDN devices) which is connected to the NTBA. Are you talking about a a filter in the sense of a noise filter? Although I have a flat rate, I find the solution of pinging the servers a kludge. It might solve my problem, but might not if there is something else causing problems.
- From the logs it looks like you being disconnected automatically by the ISP for being Idle. Then there also seems to be a problem (potentially on your/SuSE end) with reconnect because you machine didn't issue the disconnect the ISP did.
The log entry is just for one attempted connection. Not the complete log. I typically start from an icon on the desktop and when the connection drops, the window closes. Obviously I should start it from a command line to see what it says when the connection drops. However, when I stop the connection intentionally (ctrl-C) I can reconnect fine.
So, perhaps, this is causing the system to issue some sort of secondary call (instead of the default connect request/protocals) and this is recognized as a second machine/connection by you ISP and hence it refuses to allow a connect. It could also be due to old phones with shaky signal strengths, and when your idle you lose your connect due to this... I don't know - just tossing about a few ideas.
So maybe by rebooting all connections are dropped. Is there a way to reset things without a reboot. Maybe I could try to simply disconnect the DSL line from the NTBA. Hmmm. If I let that sit disconnected for 10 minutes, it might be enough for everyone to think the connection is gone. That is a lot nicer than rebooting.
I'm just guessing here. There are far more Network capable and experienced on the list than I.
Hey, at least you got me thinking. Thanks for your time. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 22 March 2003 14:17 pm, James Mohr wrote:
Hi Curtis!
Thanks for your reply. Comments are below.
On Saturday 22 March 2003 10:09, Curtis Rey wrote:
Hi James. Is your DSL on a segrated or shared line, aka piggybacking on the phoneline of has a seperate dedicated line for the DSL? If it's piggybacking you might want to get a filter, or there are some devices (or perhaps a program) that periodically pings the servers, or similar, to fool it into thinking there's activity when you not (e.g. Idle and no packets, data exchanged triggers a disconnect after a certain time by the ISP, especially true with dial up's that do this to conserve bandwidth and ip addresses).
I have an ISDN connection and the DSL card is connected to the NTBA. I also have a switch box for the phone systems (up to 8 non-ISDN devices) which is connected to the NTBA.
Are you talking about a a filter in the sense of a noise filter?
Yes, that was what I was thinking of, sometimes phone calls and other activity on the line will kludge the connection, this might also be confounded by the NTBA/switchbox.
Although I have a flat rate, I find the solution of pinging the servers a kludge. It might solve my problem, but might not if there is something else causing problems.
- From the logs it looks like you being disconnected automatically by the ISP for being Idle. Then there also seems to be a problem (potentially on your/SuSE end) with reconnect because you machine didn't issue the disconnect the ISP did.
The log entry is just for one attempted connection. Not the complete log. I typically start from an icon on the desktop and when the connection drops, the window closes. Obviously I should start it from a command line to see what it says when the connection drops. However, when I stop the connection intentionally (ctrl-C) I can reconnect fine.
Precisely what may be suspect here. Consider when issueing the "crtl-c" will shut down the program and associated protocals as intended, rather than "yanking" the connection from the program that may get hung on something because of (perhaps) a keep alive protocal that keeps trying to re-establish the connect or is still running in the background. I think it would be most helpful to the list if you did indeed start this from the Konsole/command line and then posted the output when the signal is killed/dies.
So, perhaps, this is causing the system to issue some sort of secondary call (instead of the default connect request/protocals) and this is recognized as a second machine/connection by you ISP and hence it refuses to allow a connect. It could also be due to old phones with shaky signal strengths, and when your idle you lose your connect due to this... I don't know - just tossing about a few ideas.
So maybe by rebooting all connections are dropped. Is there a way to reset things without a reboot. Maybe I could try to simply disconnect the DSL line from the NTBA. Hmmm. If I let that sit disconnected for 10 minutes, it might be enough for everyone to think the connection is gone. That is a lot nicer than rebooting.
Well, consider. By reboot all "processes and programs" are dropped/stopped/killed - you are literally off the ISP radar (ping for lack of a better example), there is no longer any broadcast and your former IP address is not there. Hence the clue I got from the post. By reboot you can re-establish your connection to the ISP without issues/problems. So, it can be inferred that without the reboot you can't reconnect.... why? Perhaps this is due to communication between the ISP and machine (and vice verse) and my inclination to believe that something is hung or not sending the proper signal from machine to ISP (or vice verse). Hmmm.... another thing, along with starting from the konsole/command line is to run top. Then run the program and see what it shows you (you may want to run top with "U" flag and choose from all, root, and <user> run programs - I do this under my <user-acct> to see what's up when something like wine or a program [aka game, etc..] is hung or being a pain). Now, with top running in a manner that lets you see what programs/jobs are running with the connect issue the crtl-c or other normal disconnect proceedures that are not problematic and look at what changes, then run top and wait for the problemed disconnect to occur and look at this and compare the difference. I'm betting that the forced/problematic disconnect will show that something/some job is still running when compared to a normal process/program shutdown. This will be especially evident by one of the process having a "defunct" tag/label associated with it. Cheers, Curtis..... Let us know!
I'm just guessing here. There are far more Network capable and experienced on the list than I.
Hey, at least you got me thinking. Thanks for your time.
Regards,
jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+fNf67WVLiDrqeksRAvPjAKCjCkJ2P4MLtrqmXoUWEslJm87nkgCgiO55 QuWbJsCEJ6hqMllzezNayOE= =NmNi -----END PGP SIGNATURE-----
* Curtis Rey
On Saturday 22 March 2003 14:17 pm, James Mohr wrote:
[snip]
So maybe by rebooting all connections are dropped. Is there a way to reset things without a reboot. Maybe I could try to simply disconnect the DSL line from the NTBA. Hmmm. If I let that sit disconnected for 10 minutes, it might be enough for everyone to think the connection is gone. That is a lot nicer than rebooting.
Well, consider. By reboot all "processes and programs" are dropped/stopped/killed - you are literally off the ISP radar (ping for lack of a better example), there is no longer any broadcast and your former IP address is not there. Hence the clue I got from the post. By reboot you can re-establish your connection to the ISP without issues/problems. So, it can be inferred that without the reboot you can't reconnect.... why? Perhaps this is due to communication between the ISP and machine (and vice verse) and my inclination to believe that something is hung or not sending the proper signal from machine to ISP (or vice verse).
Have you considered, as root, /sbin/rcnetwork restart ??? -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 22 March 2003 15:58 pm, Patrick Shanahan wrote:
Have you considered, as root, /sbin/rcnetwork restart ???
Yes, to be sure this is the most direct route to getting the network to run. Providing there's no other issues related to his network. If one wants to simply get back up and running ASAP this would definitely be the way to go. The reason for the course of the present thread is to perhaps gain some understanding about why this is occurring. This would help, perhaps - perhaps not, in finding out if some other ancillary issues are at hand and could be addressed in order to alleviate the recurrance of this behavior. This may be due to some misconfiguration somewhere, or a buggy piece of hardware/software. In the event of a buggy piece of hardware this would most likely be addressed by replacement or some similar action. In the event of a software issue, this would be most helpful in knowing for a couple of reasons. Is the present software or series of software packages upgradable or replaced(?), and the other case is that the developers may need to be aware/advised of the current state of behavior in order to facillitate a fix/recode. I have found a few problems by running such things as mentioned (in command line with output at fail and top output, logs, etc..) in order to understand what the heck is really happening. Or at least to hand off what I have found to someone that understands the issue better than I. It may be more expedient for James to simply do as you suggest and issue the rcnetwork restart command and be done with it. I guess it's all a matter of the specific issues he's presented with and/or his disposition regarding how the handle this. I find that if one "can" find out specifics regarding problematic behaviors that in many cases they can be effectively addressed (providing that the behavior is reproducable and the problem has a maintainer/dev team that is actively involved). As you suggest (tacitly at least), it may be more fruitful to simply cope with a re-init of the network daemon/protocal. Just trying to troubleshoot a bit. Cheers, Curtis :)
-- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+fOei7WVLiDrqeksRAiUvAJ9D1AZyaT2sMtlX11p3XIyLrzOBsACgnp7K B8FcN79debcpJ5AwVfOymyg= =l7RK -----END PGP SIGNATURE-----
* Curtis Rey
On Saturday 22 March 2003 15:58 pm, Patrick Shanahan wrote:
Have you considered, as root, /sbin/rcnetwork restart ???
Yes, to be sure this is the most direct route to getting the network to run. Providing there's no other issues related to his network. If one wants to simply get back up and running ASAP this would definitely be the way to go.
[snip]
I find that if one "can" find out specifics regarding problematic behaviors that in many cases they can be effectively addressed (providing that the behavior is reproducable and the problem has a maintainer/dev team that is actively involved). As you suggest (tacitly at least), it may be more fruitful to simply cope with a re-init of the network daemon/protocal.
Just trying to troubleshoot a bit.
Myu suggestion was to defer the requirement for a *reboot*. That is the recovery methodology for another basically unstable system built on dos and, I believe, should be avoided, if at all possible. -- Patrick Shanahan Please avoid TOFU and trim >quotes< http://wahoo.no-ip.org Registered Linux User #207535 icq#173753138 @ http://counter.li.org Linux, a continuous *learning* experience
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 22 March 2003 17:30 pm, Patrick Shanahan wrote:
My suggestion was to defer the requirement for a *reboot*. That is the recovery methodology for another basically unstable system built on dos and, I believe, should be avoided, if at all possible.
Agreed! Hence why your suggestion is a viable one. It certainly is preferrable to a reboot IMHO. Just curious why he loses the connection. DSL at times will exhibit many of the behaviors that a dial-up will, at least I have read and been told. I suspect a lot of this has to do with the ISP and phone lines. Just would be adventagious to know where the problem lays - in the OS or the ISP. I know that in windows there are programs that will create the appearance of activity in systems that use modem/dial-ups that have idle connections. I wonder if this isn't and inherent behavior with ppp and ISPs. DSL use a suedo/parallel implementation of the ppp protocal and this is perhaps why he's being disconnected. Hmmm, wonder if sourceforge has something that might help? Cheers, Curtis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+fP3W7WVLiDrqeksRAg3NAJ4rFv/QhUF84G4i8saX6TT0MNyVigCgyL0p omtBt7ljjKSLRckh5GWnhig= =geZ1 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 22 March 2003 18:20, Curtis Rey wrote:
On Saturday 22 March 2003 17:30 pm, Patrick Shanahan wrote:
My suggestion was to defer the requirement for a *reboot*. That is the recovery methodology for another basically unstable system built on dos and, I believe, should be avoided, if at all possible.
Agreed! Hence why your suggestion is a viable one. It certainly is preferrable to a reboot IMHO. Just curious why he loses the connection. DSL at times will exhibit many of the behaviors that a dial-up will, at least I have read and been told. I suspect a lot of this has to do with the ISP and phone lines. Just would be adventagious to know where the problem lays - in the OS or the ISP.
About a month ago, our church had DSL installed, with a NetGear router as the interface. We were having the same problems as noted by the original poster, until we changed the timeout value to 0, meaning to never drop the DSL line. Since we are paying a flat monthly fee, there is no problem with this. Check with your providers AUP before doing this. - -- Mitch Thompson, San Antonio TX // WB5UZG Red Hat Certified Engineer (RHCE) http://home.satx.rr.com/mlthompson Independent Amsoil Dealer http://amsdealer.webhop.biz wget -O - http://home.satx.rr.com/mlthompson/pubkey.gpg | gpg --import - -- "There are 10 kinds of people in the world: those who understand binary, and those who don't." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+fQCcw6DOTK6+YTURAh7yAKCCAL4RMPc10Gi7XzfmX1NJcoMXLQCfQL4W /MFm7oL+Fp7Od2dToqlgZXM= =XVWO -----END PGP SIGNATURE-----
On Sunday 23 March 2003 01:32, Mitch Thompson wrote:
About a month ago, our church had DSL installed, with a NetGear router as the interface. We were having the same problems as noted by the original poster, until we changed the timeout value to 0, meaning to never drop the DSL line. Since we are paying a flat monthly fee, there is no problem with this. Check with your providers AUP before doing this.
I have a flat rate. Interestingly enough they just sent me a note basically saying "although we expected people to be on 24 hours a days, we didn't expect such bandwidth usage." So, those with more than 20GB a month get charged 50% more than those who have less. So if the problem is that something times out, this might be a solution. On the other hand, if I set the timeout to be longer than the time between mail checks (10 minutes, I think), then I should never have this problem anyway as I always check my mail before the time. Needless to say, the problem has not re-occurred. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.
On Sunday 23 March 2003 00:30, Patrick Shanahan wrote:
Myu suggestion was to defer the requirement for a *reboot*. That is the recovery methodology for another basically unstable system built on dos and, I believe, should be avoided, if at all possible.
I though I said that already. ;-) Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.
On Saturday 22 March 2003 22:58, Patrick Shanahan wrote:
Have you considered, as root, /sbin/rcnetwork restart ???
I've done /etc/init.d/network restart, which amounts to the same thing. However, there was no change. Therefore my gut feeling is that the problem is at a lower level. (Perhaps the DSL driver??). Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.
On Saturday 22 March 2003 22:39, Curtis Rey wrote: <snip>
Are you talking about a a filter in the sense of a noise filter?
Yes, that was what I was thinking of, sometimes phone calls and other activity on the line will kludge the connection, this might also be confounded by the NTBA/switchbox.
That *could* be it. Maybe when I have a connection and someone calls (in or out), or maybe when a DSL and phone connection exist and someone tries to call in. I can go days without this happening. <snip>
Precisely what may be suspect here. Consider when issueing the "crtl-c" will shut down the program and associated protocals as intended, rather than "yanking" the connection from the program that may get hung on something because of (perhaps) a keep alive protocal that keeps trying to re-establish the connect or is still running in the background. I think it would be most helpful to the list if you did indeed start this from the Konsole/command line and then posted the output when the signal is killed/dies.
As of this point, I am still working fine. It does not seem to be time related, rather some other "event". I just need to keep track of whatever we do on the phone. My gut feeling is that it is a combination of dialing in/out, but I am not sure. Still, yanking the DSL connection and waiting for the ISP to timeout is better than a re-boot if that's where the problem is, but does not help if the problem is in the hardware. <snip>
Well, consider. By reboot all "processes and programs" are dropped/stopped/killed - you are literally off the ISP radar (ping for lack of a better example), there is no longer any broadcast and your former IP address is not there. Hence the clue I got from the post. By reboot you can re-establish your connection to the ISP without issues/problems. So, it can be inferred that without the reboot you can't reconnect.... why? Perhaps this is due to communication between the ISP and machine (and vice verse) and my inclination to believe that something is hung or not sending the proper signal from machine to ISP (or vice verse).
One possibility. But HW is another. By doing a reboot, "everything" is reset. Note that even going to init 1 does not help.
Hmmm.... another thing, along with starting from the konsole/command line is to run top. Then run the program and see what it shows you (you may want to run top with "U" flag and choose from all, root, and <user> run programs - I do this under my <user-acct> to see what's up when something like wine or a program [aka game, etc..] is hung or being a pain). Now, with top running in a manner that lets you see what programs/jobs are running with the connect issue the crtl-c or other normal disconnect proceedures that are not problematic and look at what changes, then run top and wait for the problemed disconnect to occur and look at this and compare the difference. I'm betting that the forced/problematic disconnect will show that something/some job is still running when compared to a normal process/program shutdown. This will be especially evident by one of the process having a "defunct" tag/label associated with it.
I've looked and didn't see any defunkt processes. In fact, I saw nothing related to this other that [fcdsl_thread] which had been started by init. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --------------------------------------- NOTE: All messages sent to me in response to my posts to newsgroups, mailing lists or forums are subject to reposting.
James Mohr wrote:
That *could* be it. Maybe when I have a connection and someone calls (in or out), or maybe when a DSL and phone connection exist and someone tries to call in. I can go days without this happening.
Do you have call waiting? That sends a call waiting tone, which may cause you problems. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Web Address: http://www.mydestiny.net/~joe_morris Registered Linux user 231871 God said, I AM that I AM. I say, by the grace of God, I am what I am.
participants (5)
-
Curtis Rey -
James Mohr -
Joe Morris (NTM) -
Mitch Thompson -
Patrick Shanahan