Text 1, 147 rader
Skriven 2004-03-03 11:26:12 av Mike Luther (1:117/3001.0)
     Kommentar till en text av Mark Lewis (1:3634/12)
Ärende: Privoxy - Ijfire help?
==============================
Thank you for taking the time to help me Mark.  The problem is solved, but
although a 'simple' solution, the effects are still beyond me, technically.

 ml> mike, you're making this stuff much more convoluted than it really is...

 ml> 1. if you use dhcp on the internal lan, the zyxel will set the dns to 
 ml> 192.168.1.1 for the dhcp clients no matter what it 
 ml> uses on the wan side.

Yes, but no matter WHAT I do with the LAN setup for domain service and hosts I
cannot use this for DNS service, somehow.  I can only get service if I ask for
it at at least one of the valid COX supported octets.  192.168.1.1 doesn't work
here .. at least with the ZyXel 310.  The reason may be that there are
documented issues with REVERSE DNS service both with ZyXel as well as the Injoy
software firewalls!  In short something like reverse DNS may cause problems for
some users and some IP service sources!

 ml> 2. if the zyxel is using dhcp to log into the wan, 
 ml> then the wan's dhcp will tell the zyxel what dns 
 ml> servers to use on the wan side...

It's not.  It's on a fixed address.

 ml> 3. you can hardcode #1 in each of the clients which 
 ml> appears to be what you have done.

 ml> 4. you can hardcode #2 in the zyxel which appears to 
 ml> be what you have done.

 ml> 5. hardcoding things can cause problems and lead to a 
 ml> lot of work which you have done.

Well in this case part of the reason for doing it is that the boxes don't
necessarily always have to run behind the ZyXel.  For serious emergency
connection routes, at least the ones behind the Injoy software firewall which
is behind the ZyXel have to be able to hit one or more IP's via POTS. And
although usually that's still COX, elsewhere has to be available to INJOY for
service and emergency purposes too.  The boxes support not only what most folks
know as IP and Internet, but RF TNC and network service over the VHF and even
in some cases actually HF data links here.

 ml> 6. the key to #'s 1 and 2 being automatic is the use 
 ml> of dhcp... if you hardcode the address of the box 
 ml> (static ip), then dhcp will never be used and the dns 
 ml> stuff will have to be hardcoded, too...

True.  But behind internal firewall as well this surfaces differently.

 ml> where is the proxy installed? that is the machine that the browsers 
 ml> would need to be configured to use... also note that 
 ml> there is a possibility of "discovery" being used by 
 ml> the browsers to determine if/where the proxy is 
 ml> located and/or if one is being used... however, this 
 ml> doesn't go by dhcp and i'm not sure, really, how it 
 ml> works... i only know that i had it working one time on 
 ml> some win boxen and didn't like the delay during the 
 ml> "discovery" phase and so i just hardcoded it...

Yes, and it gets even worse, as I've found - now that it is fixed!


                (Fixed Address)
      zyxel broadband router and firewall - 192.168.1.1
                       |
                       |
       Workgroup hub  (45 and coax as well)
                       |
                      /|\
                     / | \
                other machines

Under normal service the other machines all use DCHP which the ZyXel remembers
conveniently effectively forever under RJ-45.  But coax is a different matter
at times.  Of the system here, three ports are used more or less in a stable -
but disconnectable - fashion.  One port is normally used for de-bugging and
bench work with a discrete box.  Other ports are used for bench service and
sytem configuraion - all of which have to function with the ZyXel .. as well as
DOIP with Injoy as well.

You have to remember that in COAX LAN service, you don't even get the ability
to trace a box back to the NIC in some cases!  Texas A&M's TAEX station crew
had to remove all the coax lan service to keep from coy Aggie nasty WAN
pranging .. originally from a well known local FidoNet user who now runs good
San Antonio IP service after he got out of the mess from an agreed upon service
in the armed forces of the USA after the little episode!

Chuckle.   But coax is still very much an interesting issue where HF and VHF
barely above the noise level signals are needed and you simply can't afford to
let a LAN make noise all over the HF and VHF spectrum.  So it is here as needed
as well still.

It's obvious that the address which will be given is different with the ZyXel
for each one.  But, curiously I've found that the issue of localhost and
127.0.0.1 which is the preferred way of IJB and PRIVOXY setup as the address to
watch for port 8118 (moved with IJB from the default 8000 there) blows up under
this same error which I have found!  Read on..

 ml> if this is accurate... then i'd set the machines to proxy on 192.168.1.2 
 ml> and dns to 192.168.1.1... that will eliminate a lot of 
 ml> dns traffic to the outside since the machines will all 
 ml> be looking to the zyxel for their dns responses... and 
 ml> since they're all configured to look to the 
 ml> proxy/firewall at 192.168.1.2, there should be no 
 ml> problems there, either...

Doesn't work with software firewalled Injoy boxes here.  That was the reason or
part of it for the original discrete address in the proxy setup on the browsers
for the assigned addresses given by ZyXel.

 ml> FWIW: also use numbers not names where you can...

Yes .. in fact that's the only way I can do this with Injoy's dialer, some
parts of that setup, and as well with the LAN setup file,   But watch out!

It's for some insane reason how this blows up in the error I've just found that
spawns this!  ZOC, for example, blows up with numbers, but not names behind the
software firewalled boxes!

 ml> i know that you've also talked about dhcp problems in 
 ml> the past... are you still using dhcp? why? where?

I've tried to explain that.  For emergency connections for civil defense
purposes, the RACES circuits, EOC links in time or real emergency, I have to be
able to service boxes from POTS as well as an alternate.  Rare, but there. 

Now .. let's defer the FIX to the following message that Peter Knapper posted,
if you will.  I'll cite the short answer here.  Then post the details in
Peter's message.

Bottom line.  Regardless of how they get there in the Injoy firewalled boxes,
there is an addition RESOLVE file in MPTN\ETC that is involved!  In addition to
RESOLV2 there is also RESOLV as well!   Bottom line; you have to be able to
"resolv" before you can "resolv2" in at least today's version of MPTN and
TCP/IP for MCP2 .. 4.3 and so on.

And it DOESN'T get changed to the correct DNS addressing and domain unless I
hand edit it here, now that it is on the boxes!

To be continued ... wry grin.


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

Mike @ 1:117/3001

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