Text 12, 115 rader
Skriven 2004-03-05 20:41:08 av Mike Luther (1:117/3001.0)
     Kommentar till text 11 av Peter Knapper (3:772/1.10)
Ärende: Privoxy - Ijfire help?
==============================
Well Peter and crew ..

Mikey may know more.  The thlot plickens!

 PK> Hi Mark,

 PK> I remember someone once saying that Injoy used resolve and
 PK> not resolv2, but I was ever able to confirm that.

 ml> without the 'e',

 PK> Thats just my typo, I don't use Injoy so I have never 
 PK> seen the file... It sounds like Injoy could be the 
 PK> cause of some of this confusion, I see Will has had 
 PK> past experience with this issue.

OK .. as of two AM this morning the whole thing collapsed again as to DNS
resolution with the new set of DNS servers that Cox gave me!  This time,again
for PRIVOXY and Telnet and all and .. even on the boxes that had no firewall!
Hours later I may know more, sigh.  It's back working again.


First as to Injoy and "resolv" as it is created to one way or another force DNS
service to what it gets on dialup; Will is dead correct in his post(s) to me. 
As well I may know more about the Injoy Firewall deal.  No, I haven't installed
it on any other boxes as yet - today's mess was bad enough.  But in that
research today I can tell you what I've found.

The Injoy firewall, when used without the Injoy dialer for connection, does
*NOT* need the Injoy created "resolv" file in \mptn\etc\ at all under normal
operation that way.  As well, you can simply delete the "resolv" file and it
makes no difference to the firewall operations.  Both such boxes here work just
fine without that file at all.  That even after many reboots.

Now .. behind the ZyXel Prestige Broadband Router, whatever numeric octet
defined DNS addresses are defined in its setup, as part of a fixed address such
use of it, will be the exact DNS service addresses that will be written into
"RESOLV2" in the \mptn\etc\ directory as well as "RESOLV" in the
\tcpip\dos\etc\ directory each and every time DHCPCD makes a new connection or
re-connection and re-lease to the router.  I can change to DNS servers at will
while on-line on the ZyXel.  I can bust the lease with the DCHP monitor and
re-lease.  Every time whatever is in the ZyXel will always be overwritten into
these files.  More important, every time I re-lease and reconnect with DHCP,
after every change in the ZyXel; it's listed DNS servers will switch
automatically with that re-link in the TCP/IP (Local) configuration.  That
without swapping anything in them at all by hand in the configuration.

So, if so, and suddenly, DNS no-workee any more after 2:00 AM in morning and
been working flawlessly for days now; why not?  More research with Cox. Here is
what I've found out from them.

I had several different pairs of DNS servers given to me by the tech weeks ago
when this erupted.  At that time, in looking at the PING times with PMPING for
OS/2, it turned out that the pair they gave me with Octet addresses which were
obviously here in the Bryan-College Station area with my same starting
208.180.##.## as my fixed IP address had faster service than some of the others
by 10MS or so most of the time.  During the huddle before, the request was that
I use this pair.  My reasoning as well; faster service.  The other key pair
isn't in the BC-S area, but is at the regional center in Tyler, Texas.  It's
worked beautifully until today, then bang; gone back to this same one minute
delays everywhere on every box with all the same application mess as before.

And even after the current collapse, I'm still able to ping every single one of
the Cox DNS service addresses given me!  Six of them!  What's wrong?

OK, back to Cox.  Answer is simple.  The 208.180.##.## pair of DNS servers are,
in fact, in BC-S and they really want customers in the 208.180,##.## market to
use them.  But they are CACHING servers, not actual primary DNS servers there! 
The reason they need that is to take the load off the key DNS servers which are
the ones in Tyler!  Although nothing has been changed as far as their network
is concerned in the system, the performance and the 'catchup' time for the
caching servers simply isn't what it is as to speed and service as it is with
the for-real servers.  Try the Tyler real ones.

I did.  Which means a complete DHCP re-set and sync, plus hand assignment in
all the Injoy dialers as well.  Poof .. right back to working again!  A
post-script.  Be sure you have turned off the option in the TCP/IP
configuration toolset, to re-connect for the old DHCP addresses on reboot!  I
guess this is how you guarantee that the delivered address by the DHCP client
will always be properly re-written into both "resolv2" and "resolv" as it is
needed on reboot or re-up for DHCP.  At least for this type use.

Bottom line.  For whatever reason with MPTN, TCP/IP 4.3, OS/2 and whatever, the
only reliable way to work out DNS service with hard assigned addresses and
fixed addressing that works with all applications, seems to be simple.  You
have to be assigned service and connected to a for-real server pair and not a
caching server!

Bottom line squared.  In that Injoy's firewall does not seem to require a
"resolv" file at all, and "resolv2" is always re-written with each re-lease,
the actual cleanup for a blown Injoy disconnect with a remaining "resolv" file
that isn't supposed to be there is simple.  For a DHCP connection box simply
delete any such "resolv" file in \mptn\etc\ as part of the boot run itself.  If
it is needed for Injoy, it will be replaced anyway as part of the Injoy
connection process.

Will's suggestion about homing the directory with a SET statement is also
needed, it seems, for some DOS and WIN 3.1 applications to correctly work. But
"resolv" in \mptn\etc\ better not be there at all if not needed, and for sure
without the proper addressing to match "resolv2", if it is!

Right now all is working again.  I have no idea what I will do if the primary
for-real DNS service fails again with Cox Tyler!  There may be more yet to this
problem I or we don't know still.  We'll see.

Thanks for the time you'all spent with this.  I deeply appreciate learning from
you folks and hope I've paid back some of the obligations.


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)