Messages in this thread | | | Date | Mon, 30 Mar 1998 17:49:13 +0200 | From | Erik Corry <> | Subject | Re: TCP socket timeout problem. |
| |
On Mon, Mar 30, 1998 at 10:49:52AM +0200, Robin Smidsrød wrote: > > If you do this you will still get one redial, but not > > several like you are getting now. If you want to stop > > that one redial, you can start getting clever with ipfwadm > > commands in /etc/ppp/ip-down and ip-up. > > Somebody suggested that I should only "open" the interface on UDP (DNS) and > TCP SYN. Anybody know if this is right, and if so, how do I set up the > _correct_ rules? Examples are more than welcome... (the interface is ippp0).
Sounds right, if you have dynamic adresses, but I don't think it's possible with ippp. It can very likely be done in diald, but using diald with SyncPPP is something of a black art (contradictions welcome) and you probably don't want to switch to async PPP with ttyI/X.75 ISDN 'modem emulation'.
It has the advantage of avoiding that one dialup, but the disadvantage of not notifying the app that it's socket has died. Many apps take a long time to time out such a socket (eg. squid) and the kernel takes even longer.
With ipfwadm you can get the best of both worlds. In ip-down you set the old IP to reject, which kills any sockets that try to transmit while the interface is down. Then in ip-up you clear any reject rule on the new address and convert the reject rule on the old address to a deny rule. You have to do this because otherwise the reject packets go out (keeping up the link) instead of back to the source (because you don't have the IP any more that they are sent to). Shortly after, you get a retransmit, and the RST-provoker changes the address and you get a RST which kills the socket. You need to time out old deny rules after a few hours to avoid them building up and damaging performance.
I regard that solution as too complex to be practical.
-- Erik Corry
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |