Text 18, 84 rader
Skriven 2004-03-07 22:32:10 av Mike Luther (1:117/3001.0)
     Kommentar till text 17 av Will Honea (1:106/2000.0)
Ärende: Privoxy - Ijfire help?
==============================
Your suggestion Will ..

ML> Inquiring mind wants to know.  Even one not yet addicted to coffee

 WH> I'll bet you figured you were the first one to think of that <g>.  Tel
 WH> you what, make a dialup connection then go in and sub some strange
 WH> addresses for the DNS server.  I think you will find that the ARP
 WH> resolution has beat you to it it and has cached the addresses already. 
 WH> There are some interesting caching issues in that stack - the Nutshell
 WH> book on TCP/IP makes for some interestingreading.

is what made me post this.

Unless I did the above wrong, I'd already done it out at the remote site
against an Injoy connection.  And .. where Privoxy is in use, the instant that
you swap a bogus connection address into the "resolv" file with Privoxy
running, you are right back into the delay for one minute game. Yep, you will
eventually get to the 'older correct' address in "resolv2" when you do this.
But you don't get there until the entire timeout game for the bogus one has run
its course.  About 56 seconds or so per what I see.  And what I see of Injoy
there is also that it chunks in the 'correct' addresses which you have coded
into the Injoy DNS server fields when it connects, right or wrong. But it also
simply shifts the OLD "resolv" into "resolv.inj" here, whether they were right
or wrong.  And in this case it does not alter the DNS addresses which you have
coded into the HOSTS with TCP/IP Configuration, as long as you do not have DHCP
set up in the LAN0 choices as well!  You can set good ones there.  When
"resolv" fails as in the above, it will, indeed home in on them.  But without
DHCP enabled in the basic configuration, no update of them takes place from
just Injoy's work.

That's also why, the instant you erase the "resolv" file with bad data in it on
the fixed address boxes with Privoxy, instantly you see the proxy come alive
here in town as well.

Now Mikey doesn't have a bogus DNS server to play with at the moment, and isn't
trained well enough to play with this some more at this point.  But once I know
that it went looking for the bogus one, couldn't find it, then in due time went
to the other 'good' one, I had the curiousity to ask the above question.  It's
suggestive to me that if I had an address there which was to a naughty DNS
server, at least in the case of Privoxy, and maybe in these other cases, it
ought to be compromiso, seenyor.

And .. that .. leads me to wonder if, as another reason for what has surfaced,
the author of SmartCache is frothing over a supposed hole in that proxy
application and vows to stop development of it?

Now .. to be fair about the observations, curiously, if you use the old
Internet Junk Buster, you don't see the one minute delay, even though the bogus
address is in there.  Or, in my previous case when I hit this, the caching
server was busting up Privoxy, but not .. IJB.  Since IJB works, but Privoxy
fails, something is different than ARP resolution caching for some
applications, perhaps?

Furthermore, if you put the bogus addresses in the "resolv" file, you go right
back to the glitch in ZOC where NUMERIC addresses for a Telnet connection delay
by a minute, but ALPHA addresses do not!  And you go right back into the deal
with FTPSERVE where, say ONE path (directory) has the one minute delay, but all
the rest of the whole FTP server does not!

Now .. of course, here I go having to read into what's in a Nutshell, grin, but
even with what you've posted, at least in the case of Privoxy and some other
applications for OS/2, that one minute timeout delay hints to me that there is
still a boll weevil in the cotton patch.  Even if, grin, it's an albino weevit
that even ARPaphene won't see!  Maybe more than one, and in different bolls
too!  Else why does numeric fail with ZOC and alpha work?


          Jus' a lookin' for a home!   ^(#)*@
                                        ~~~  )

I just checked this out again at my W5WQN ham site in the country tonight while
I was out there to run the echo on 80 meter CW of Bob, W6TI's NCDX bulletin on
40 and 20 CW which I do every Sunday night.  Absolutely the same curious delay
I'd seen last Sunday when I first caught this there too.  But onlu on some
applications and not others.  Which still says more than one error seems to be
at work here considering what you suggest for ARP...


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

Mike @ 1:117/3001

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