-----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-----