On Mon, 02 Dec 2002, Steffen Dettmer wrote:
* Togan Muftuoglu wrote on Sun, Dec 01, 2002 at 16:45 +0200:
* ce-em; <ce-em@onlinehome.de> on 01 Dec, 2002 wrote:
Hi all, I think it must be the firewall who disconnects me, because if I restart the firewall without dialin in, my PuTTY session just hangs about 2 seconds. But if I am dialed in (so my ppp interface is up) and I restart the firewall, the "connection abort" error occours again.
When the firewall restarts all the rules are flushed so your ssh connection can not continue as their is no rule to allow that.
This results in a 2 second delay, not in a connection drop. When I restart my firewall script, which also recreates all rules, the SSH don't stop, independent if I'm dialed-up or not. Ohh, and please note, it can be dangerous, when you do a restart on a shell, ssh gets closed and dropped, there is no controlling terminal and the script execution stops - at closed SSH...
If you want to manually start the dialin process ( why you want it is not clear for my understaning) you may use a serial console access which is not affected by the firewall rules
Sorry for late follow-up to this thread. I did not see the version that ce-em is using. However I successfully remote control my SuSE Linux 7.3 gateway with wvdial in a bash ssh session. I just tried with the script /usr/sbin/cinternet --start that also works ok without interrupting putty. My gateway runs SuSE Linux 7.3 and has used 33.6 and 56k dial-up modems (dial out only.) (ssh remote control by PuTTY release 0.52 on W2K SP2 and SP3 , but I also do this same task from OpenSSH (ssh) on a SuSE 7.3 laptop with dhclient -- gateway runs dhcpd.) I have done this with either personal-firewall or SuSEfirewall2 running on the gateway. SSH session from local LAN (eth0) is never dropped. I can't troubleshoot your situation - sorry - but just for information that it can work in case you to choose to persist and find the bug. It just seemed easy enough to me that I did not experiment with dial-on-demand yet. Maybe ce-em's situation is exposing an obscure bug in one of the dial-out scripts that mine does not. ??? dproc