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!