Re: diald slow to be useful...
Mike Jagdis <[email protected]> Thu, 30 May 2002 12:41:26 +0100
| Newsgroups | org.kernel.vger.linux-diald |
|---|---|
| Message-ID | <[email protected]> |
Matt Garman wrote: > Diald works almost as expected (connects to the Internet, hangs up > after timeout). Diald dials and gets PPP up and running rather > quickly. However, the connection that triggered diald has to timeout > and retry before it does anything useful. > > Here's a concrete example: diald runs on septictank, my workstation is > sewage. On sewage, I try to do a google search. Immediately the > modem dials, and after a few seconds, the PPP connection is up and > running---I can use any Internet protocol except http. I have to wait > for the browser to timeout trying to reach google, then retry the > search. But during that waiting period, I could do a fetchmail. > > The diald FAQ addresses this and says to try the option > "buffer-packets on". I've tried with this option both on and off, and > the problem persists both ways. Another suggestion I found on the > 'net was to set /proc/sys/net/ipv4/ip_dynaddr to 1. I did this on > septictank, and it also had no effect. > > Any thoughts? I _think_ I know what's going on. Your Internet connection is PPP with dynamic addressing, your proxy address is just a random local address, you surf from a browser on a workstation, and your Linux gateway uses masquerading to give you access to the Internet. What happens is that when the browser starts a connection it sends a SYN packet to the remote server. This goes to your Linux gateway, *gets masqueraded*, and is routed to diald's proxy interface. Diald brings the link up and forwards the buffered packet but because it has already been masqueraded with the wrong address you're stuffed. Worse, there is now an entry for this connection in the masquerade table *with the wrong address*, so it will never work and you have to abort it. (ip_dynaddr works for connections originated on the gateway *only*. These connections don't get masqueraded and setting ip_dynaddr tells the kernel network code to reselect the source address for the connection each time the initial SYN has to be resent) Ok, that's not good. But if that *is* what's happening there are three solutions. In order of ease: 1. Do you normally get allocated the same IP address? Some ISPs do it by account, some by modem port. If you generally get the same IP address change "dynamic" to "sticky" in your diald config. This causes diald to use the IP address last used on the link for the proxy. So once it has seen a connection the proxy address will be the same as the (expected) link address and the masquerade address will be right. If you set the proxy address to your expected address in diald's config this will only fail for the first connection after your address changes. 2. Run a proxy such as squid or junkbuster on the gateway and either configure your browser to talk to it or configure the gateway to do transparent redirection to it. Now your browser talks to the proxy and the proxy talks to the remote server. Since the proxy's connection is originated on the gateway the ip_dynaddr thing works. This only works for protocols which have available proxies - if you need the link to come up for telnet, ssh, ftp, pop3, imap etc. squid and junkbuster won't help - but an offsite home page might be sufficient? 3. Hacker voodoo :-). If you know what you are doing you can change your firewall set up so that it *doesn't* masquerade traffic sent to diald's proxy interface. How you do that depends on whether your use ipchains (-i ! sl+) or iptables (-o ! sl+), and how your distribution does firewall config. In dynamic (or sticky) mode diald forwards buffered packets back in to the kernel via the proxy rather than straight out on the real link. So the kernel first routes the packet to diald *without* masquerading it, diald brings the link up and sends the packet back to the kernel, which then routes it to the link and *does* masquerade it - with the correct address! This should work for all connections even if you get a different address every time. But you're probably going to have to understand firewalling, read man pages, and edit shell scripts to do it[*]. Mike [*] If anyone does this *please* let us know what you needed to change!