Kip Cranford wrote:

> (let's try it again, but with a subject this time... :)
>
> I have installed diald and ip masquerading successfully on
> my linux box at home.  I also have a Win95 box at home -- both
> machines are on a 10bt hub.
>
> The setup works fine (as far as I've tested it so far), but I have
> noticed a problem.  When I connect to my ISP, I'm given a dynamic IP
> address, which in and of itself isn't causing any problems.  However,
> on the Win95 box (for example), if I enter http://152.2.254.81 in
> Netscape, I never get the page to show up.
>
> I believe this is due to the fact that the original TCP request brings
> up the link, but is given the _default_ IP address as specified in
> the diald.conf.  When the link is actually established, I'm given the
> _actual_ IP address by my ISP, which the HTTP request can't "switch to".
> So, the request inside Netscape times out.
>
> I've noticed, though, that setting up DNS on the Win95 box to my ISP's
> nameserver, and then entering the name (and not the IP address) in
> Netscape, works ok.  This makes sense to me, since the hostname lookup
> will establish the link correctly, can recover (being UDP), then the
> HTTP request succeeds.
>
> So my question is, is there a way around this problem?  Is this just
> one of the drawbacks of having a dynamic IP address?  Are my first
> TCP requests always doomed to fail because of this problem?

The first tcp packets are doomed.  However the first tcp requests are
not
doomed if they retry long enough.
You just have to make sure the first tcp request continues to retry
until
the ppp link is up.   As long as one of the retries succeeds, the
request
will succeed even if many of its packets failed.

Set up a forwarding-only nameserver on the diald machine.  Add
the option "forward only" and enter your ISP nameservers
as forwarders - each one twice to increase the total number of
retries.  On your w95 machine, configure everything possible with
host names instead of IP numbers - to force the first tcp request
to be a DNS name lookup request.

You want a forwarding-only nameserver, not a caching nameserver.

Then your initial tcp requests, which are usually
DNS name lookups, will go to your nameserver on linux,
which will forward them out through diald until they succeed.

This will eliminate the DNS lookup timeouts.    However
the first packet out is not always DNS, so you will still get the
odd lockup forcing you to exit an app and restart it.

It may be possible to get around the problem by configuring
diald to KEEP the default route on sl0.  This is possible to do,
and it has a certain performance penalty - has anyone tried
this solution?



--

Jan Carlson
[EMAIL PROTECTED]   Scarborough, Ontario, Canada
Mailed with Netscape 4.5 on Red Hat Linux 5.2

-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]

Reply via email to