network configuration woes,gateway,DNS
s_c_...@my-deja.com
I am having difficulty figuring out how to tell my SCO 5.0.5 box
(Prosignia 486/66, 3Com579 EISA NIC, X installed, IP 192.168.1.253)
how to find my Linux firewall/gateway (IP 192.168.1.254)
I have no problems connecting to/through my firewall from my
M$ Win98/NT boxen. I have not added local network connections to or
from the M$ boxen to the SCO box.
Do I point the SCO box at the gateway machine using the route command?
If so please help with syntax.
Once I get the SCO box to recognize gateway, how do I configure system
to query name servers on external network?
Please advise, or point me to documentation that can hold my hand
through this.
Thanks.
Schro
Sent via Deja.com http://www.deja.com/
Before you buy.
Jeff Liebermann
>I am a newbie to SCO.
Welcome to SCOland.
>I am having difficulty figuring out how to tell my SCO 5.0.5 box
>(Prosignia 486/66, 3Com579 EISA NIC, X installed, IP 192.168.1.253)
>how to find my Linux firewall/gateway (IP 192.168.1.254)
Run:
route add default 192.168.1.254
If that works, edit the file:
/etc/rc2.d/S91route
and add the route add default 192... line. If the file does not exist,
create it.
>Once I get the SCO box to recognize gateway, how do I configure system
>to query name servers on external network?
Edit the file:
/etc/resolv.conf
If the file does not exist, create it. Note the weird spelling. The proper
syntax can be found in the man pages for "resolver". Here's what mine looks
like:
domain comix.santa-cruz.ca.us
hostresorder local bind
nameserver 206.13.28.12 206.13.31.12
Substitute your own ISP's DNS servers.
--
Jeff Liebermann je...@comix.santa-cruz.ca.us
150 Felker St #D Santa Cruz CA 95060
831-421-6491 pager 831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/ SCO stuff
Jean-Pierre Radley
| domain comix.santa-cruz.ca.us
| hostresorder local bind
| nameserver 206.13.28.12 206.13.31.12
| Substitute your own ISP's DNS servers.
One nameserver per keyword. That should be
domain my.domain
hostresorder local bind
nameserver d.e.f.g
namesever w.x.y.z
--
JP
LFessen106
Me too :-)
>I am having difficulty figuring out how to tell my SCO 5.0.5 box
>(Prosignia 486/66, 3Com579 EISA NIC, X installed, IP 192.168.1.253)
>how to find my Linux firewall/gateway (IP 192.168.1.254)
>
>I have no problems connecting to/through my firewall from my
>M$ Win98/NT boxen. I have not added local network connections to or
>from the M$ boxen to the SCO box.
>
>Do I point the SCO box at the gateway machine using the route command?
>If so please help with syntax.
route add default 192.168.1.254
>
>Once I get the SCO box to recognize gateway, how do I configure system
>to query name servers on external network?
Add your dns info into a file called /etc/resolv.conf
format is like thus:
nameserver xxx.xxx.xxx.xxx
nameserver xxx.xxx.xxx.xxx
>
>Please advise, or point me to documentation that can hold my hand
>through this.
>
>Thanks.
You're welcome :-)
-Linc.
HeeD
wrote:
But if nameserver is down, or internet connection is lost
temporarily... then SCO goes brain-dead, with it taking many minutes
to telnet in on the LAN for example.
Is there easy way around this?
I was told to run DNS on SCO machine but that seemed difficult and
beyond my intelligence without more detailed instructions.
HeeD
Ken Wolff
Yes,
I truly do not understand when you specify 'hostresorder local bind'
OpenServer can't follow directions and look to /etc/hosts first then to DNS
when resolving names. Our Redhat machine doesn't have this problem.
Anyway, the only way I've come up with to handle this is to change
resolv.conf depending on if our gateway to our ISP is running. Such as:
# Domain name resolver configuration file
#
domain cscc.maximus.com
hostresorder local bind
#hostresorder local
search cscc.maximus.com
nameserver 172.20.1.3
This is now our resolv.conf looks when the gateway is working. When it's
not working I make the following changes:
# Domain name resolver configuration file
#
domain cscc.maximus.com
#hostresorder local bind
hostresorder local
search cscc.maximus.com
#nameserver 172.20.1.3
...and restart routed.
Not the most eloquent way, but it gets the job done. Luckily we only run
into this once every few months.
Ken
Jeff Liebermann
>On Tue, 30 May 2000 11:59:56 GMT, Jean-Pierre Radley <j...@jpr.com>
>wrote:
>
>>Jeff Liebermann propounded (on Tue, May 30, 2000 at 12:01:34AM -0700):
>>| domain comix.santa-cruz.ca.us
>>| hostresorder local bind
>>| nameserver 206.13.28.12 206.13.31.12
>>| Substitute your own ISP's DNS servers.
>>
>>One nameserver per keyword. That should be
>> domain my.domain
>> hostresorder local bind
>> nameserver d.e.f.g
>> namesever w.x.y.z
>
>But if nameserver is down, or internet connection is lost
>temporarily... then SCO goes brain-dead, with it taking many minutes
>to telnet in on the LAN for example.
>
>Is there easy way around this?
Yes. Add all your fixed IP addresses on your local network to /etc/hosts.
If running Windoze, LanMan, or SMB networking, also add them to
/etc/lmhosts. Similarly, add them to c:\windoze\hosts and lmhosts.
Since hostresorder looks for local name resolutions before going to the
internet for name resolution, you should not have any delays. I keep one
copy of hosts and lhosts on all my machines with provisions for updating all
the others every time a change is made. (Yeah, I know it's lots of work).
>I was told to run DNS on SCO machine but that seemed difficult and
>beyond my intelligence without more detailed instructions.
No guts, no gain. Learn by Destroying. Make backups and try setting up a
DNS server. If it fails, go back to where you started. Nothing is too
difficult to try if you can undo the mess afterwards.
DNS is the alternative to maintaining hosts and lmhosts. It had the
advantage of centrally locating all the names and IP's so one does not need
to do all the updates as detailed above. See:
How do I set up a primary nameserver and nameserver clients?
http://www.sco.com/cgi-bin/ssl_reference?107297
Also, go to:
http://www.sco.com/ta/
and use "dns server" as the search buzzword for additional help.
I use a different approach to DNS. I use a cacheing DNS server for my
internet gateway, firewall, NAT, etc. I cache all DNS address lookups
including local addresses. My workstations (clients) point to the cacheing
DNS server for address resolution instead of the worthless PacHell DNS
servers. If my DSL line goes comatose or PacHell's worthless DNS servers go
dead, the local DNS cache will still resolve addresses. The timeout on the
cacheing DNS server is short (5 seconds) and will return a "cannot resolve"
error message almost immediately if the DNS servers are unavailable.
http://www.freesco.org (That's Free Cisco, not Free SCO).
Incidentally, the firewall also has a dialup modem which will eventually
dial a different ISP if my DSL goes comatose.
Richard Seeder
>
> At 03:53 PM 6/12/00 -0700, Jeff Liebermann wrote:
>
> <snip>
>
> > >
> > >Is there easy way around this?
> >
> >Yes. Add all your fixed IP addresses on your local network to /etc/hosts.
> >If running Windoze, LanMan, or SMB networking, also add them to
> >/etc/lmhosts. Similarly, add them to c:\windoze\hosts and lmhosts.
> >Since hostresorder looks for local name resolutions before going to the
> >internet for name resolution, you should not have any delays. I keep one
> >copy of hosts and lhosts on all my machines with provisions for updating all
> >the others every time a change is made. (Yeah, I know it's lots of work).
>
>
> We've got all internal IPs in /etc/hosts. We also have 'hostresorder local
> bind', but if our internet connection goes down, telnet/ftp/pop takes about
> 2 minutes to connect. I just don't see where the hostresorder line is even
> being looked at. We're not running named on our OpenServer machine but are
> running routed. If what you say is suppose to work, what are we doing wrong?
>
> Ken
I've noted before that on OpenServer if you have ever had DNS running,
something gets set that causes certain applications to appear to ignore
the hostresorder line even when named is no longer running. If DNS has
never been run, then this does not happen. No luck so far in tracking
down where the problem is.
--
Richard Seeder
aa...@worldnet.att.net
HeeD
>Yes. Add all your fixed IP addresses on your local network to /etc/hosts.
>If running Windoze, LanMan, or SMB networking, also add them to
>/etc/lmhosts. Similarly, add them to c:\windoze\hosts and lmhosts.
>Since hostresorder looks for local name resolutions before going to the
>internet for name resolution, you should not have any delays. I keep one
>copy of hosts and lhosts on all my machines with provisions for updating all
>the others every time a change is made. (Yeah, I know it's lots of work).
Thank you, I tried that and it works!
I made sure I had the line in /etc/resolv.conf
hostresorder local bind
I edited the /etc/hosts and put entries like this:
192.168.1.2 192.168.1.2
192.168.1.3 192.168.1.3
etc.
seems that putting the IP in for hostname did the trick (I didn't feel
like figuring out real names for them).
I tested from machine 192.168.1.2 then by pulling the plug on the
router to kill the internet connection and temporary commenting out
192.168.1.2 line in /etc/hosts - trying to login and it takes long
time. Now when I uncomment line it logs in quick, like normal.
Ken Wolff
>Ken Wolff wrote:
> >
> > At 03:53 PM 6/12/00 -0700, Jeff Liebermann wrote:
> >
> > <snip>
> >
> > > >
> > > >Is there easy way around this?
> > >
> > >If running Windoze, LanMan, or SMB networking, also add them to
> > >/etc/lmhosts. Similarly, add them to c:\windoze\hosts and lmhosts.
> > >Since hostresorder looks for local name resolutions before going to the
> > >internet for name resolution, you should not have any delays. I keep one
> > >copy of hosts and lhosts on all my machines with provisions for
> updating all
> > >the others every time a change is made. (Yeah, I know it's lots of work).
> >
> >
> > We've got all internal IPs in /etc/hosts. We also have 'hostresorder local
> > bind', but if our internet connection goes down, telnet/ftp/pop takes about
> > 2 minutes to connect. I just don't see where the hostresorder line is even
> > being looked at. We're not running named on our OpenServer machine but are
> > running routed. If what you say is suppose to work, what are we doing
> wrong?
> >
> > Ken
>
>I've noted before that on OpenServer if you have ever had DNS running,
>something gets set that causes certain applications to appear to ignore
>the hostresorder line even when named is no longer running. If DNS has
>never been run, then this does not happen. No luck so far in tracking
>down where the problem is.
>
>--
>
>Richard Seeder
>aa...@worldnet.att.net
That would explain it. We did try running DNS shortly a while back. If
you do ever find out what I causing this, I'd sure like to know.
Ken
Jeff Liebermann
wrote:
>We've got all internal IPs in /etc/hosts. We also have 'hostresorder local
>bind', but if our internet connection goes down, telnet/ftp/pop takes about
>2 minutes to connect. I just don't see where the hostresorder line is even
>being looked at. We're not running named on our OpenServer machine but are
>running routed. If what you say is suppose to work, what are we doing wrong?
To keep things exact, we are talking about running telnet/ftp/pop3
*FROM* an OSR5 box to somewhere else. If this is in reference to
Windoze workstations, doing DNS lookups for netbios names, the
following discussion does *NOT* apply. In these cases, the Windoze
workstations initiate their own DNS lookups. Unfortunately, a variety
of bugs and registry tweaks seem to be required to stop these DNS
lookups. (I have a list of MS Q numbers somewhere on the topic). The
common practice is to block these Windoze initiated netbios lookups at
the firewall.
Now, back to OSR5.
Resolv.conf has one nasty habit. You can horribly misconfigure it and
not one single program will ever complain. It even says this in the
man pages.
Everything you've done is correct. I don't know if routed has any
effect. Probably not. In theory, a telnet or ftp to a local machine
listed in /etc/hosts should NOT require a DNS lookup. However, POP3
might require a reverse DNS lookup to authenticate the HELO line.
Checking.... yep. If my domain does not agree with my connected IP,
Qpop claims I'm a charlatin. POP3 is going to lookup the name. Later
versions of Qpopper allow the reverse DNS feature to be disarmed.
http://www.eudora.com/qpopper/
I can test if telnet and ftp initiate DNS lookups easily enough in my
office while sniffing the network. I have a test setup that should
work. However, I won't be there until Thurs or Fri.
Incidentally, the reason most systems use DNS caches is not to speed
up DNS lookups. It's to reduce the tendency to bring up a dialup link
every time there's a DNS lookup. In my case, if my full time
connection is dead, the DNS cache will return an almost immediate
"nothing found" allowing the application to continue instead of
waiting 3 minutes for a response. [Insert plug for configurable
timeouts on everything]. The DNS servers return fast responses. It's
the applications that are waiting around for 3 or more minutes for a
response.
Ken Wolff
>On Mon, 12 Jun 2000 23:39:52 GMT, Ken Wolff <ke...@cscc.maximus.com>
>wrote:
>
> >We've got all internal IPs in /etc/hosts. We also have 'hostresorder local
> >bind', but if our internet connection goes down, telnet/ftp/pop takes about
> >2 minutes to connect. I just don't see where the hostresorder line is even
> >being looked at. We're not running named on our OpenServer machine but are
> >running routed. If what you say is suppose to work, what are we doing
> wrong?
>
>To keep things exact, we are talking about running telnet/ftp/pop3
>*FROM* an OSR5 box to somewhere else. If this is in reference to
>Windoze workstations, doing DNS lookups for netbios names, the
>following discussion does *NOT* apply. In these cases, the Windoze
>workstations initiate their own DNS lookups. Unfortunately, a variety
>of bugs and registry tweaks seem to be required to stop these DNS
>lookups. (I have a list of MS Q numbers somewhere on the topic). The
>common practice is to block these Windoze initiated netbios lookups at
>the firewall.
My problem I with win95 machines, defined in /etc/hosts, running into the 2
minute (or there abouts) delay trying to telnet/ftp/pop to the OpenServer
machine when DNS is down.
>Now, back to OSR5.
>
>Resolv.conf has one nasty habit. You can horribly misconfigure it and
>not one single program will ever complain. It even says this in the
>man pages.
>
>Everything you've done is correct. I don't know if routed has any
>effect. Probably not. In theory, a telnet or ftp to a local machine
>listed in /etc/hosts should NOT require a DNS lookup.
<snip>
That's the theory I understood, but in practice, it does not appear to work
that way.
Even though all internal machines are defined in /etc/hosts, and even
though /etc/resolv.conf contains 'hostresorder local bind', if DNS is down
(ie gateway to ISP is down) telnet/ftp/pop takes 2 minutes to connect.
See Richard's post on this. He states this has to do with DNS ever being
run on the SCO box (which is the case with our site).
Ken
Jeff Liebermann
wrote:
>My problem I with win95 machines, defined in /etc/hosts, running into the 2
>minute (or there abouts) delay trying to telnet/ftp/pop to the OpenServer
>machine when DNS is down.
Stop. This is a Windoze problem, not an OSR5 problem. I don't know
your network topology, but I'm guessing that you have your Windoze
boxes configured with the DNS servers pointing to your ISP's DNS
servers. The OSR5 box is not involved in the DNS lookups. Tweaking
of /etc/resolv.conf only affects lookups initiated by programs running
on the OSR5 box. (Disclaimer: This assumes the you're not running
Merge, VisionFS, or AFPS, which will make the DNS configuration
different).
Here's how to fix your problem:
1. On your Windoze boxes, created files called:
c:\windoze\hosts
c:\windoze\lmhosts
and fill them with various hostnames and IP addresses found on your
local network, especially the the OSR5 box. See the files:
c:\windoze\hosts.sam
c:\windoze\lmhosts.sam
for a sample configurations. If you're running Windoze NT, the files
are:
c:\winnt\system32\drivers\etc\hosts
c:\winnt\system32\drivers\etc\hosts
There is no need to reboot Windoze or perform other un-naturals acts
to activate these files.
The lmhosts file is not optional and is required to keep Windoze from
doing DNS lookups for Netbios name lookups.
2. There are bugs in various Windoze mutations which prevent things
from working as expected. Read:
How to Disable NetBIOS Name Resolution on DNS
http://support.microsoft.com/support/kb/articles/Q137/3/68.asp
NetBIOS over tcp/ip name resolution and WINS
http://support.microsoft.com/support/kb/articles/Q119/4/93.asp
Windoze Does Not Parse LMHOSTS File with DNS enabled
http://support.microsoft.com/support/kb/articles/Q137/8/56.asp
Windoze Sockets 2.0 Does Not Use DnsNbtLookupOrder Value
http://support.microsoft.com/support/kb/articles/Q216/4/70.asp
In general, I do not think it possible to completely prevent a random
Windoze machine from doing NetBios DNS lookups. Therefore, these
calls must be trapped at the firewall or router. Just about every
router worth spending money on has this feature.
3. In the future, when you are discussing more than one machine,
please be a bit more obvious as to which machine you're working on.
Brian K. White
>
> At 02:15 PM 6/13/00 +0000, Richard Seeder wrote:
> >Ken Wolff wrote:
> > >
> > > At 03:53 PM 6/12/00 -0700, Jeff Liebermann wrote:
> > >
> > > <snip>
> > >
> > > > >
> > > > >Is there easy way around this?
> > > >
> > > >Yes. Add all your fixed IP addresses on your local network to /etc/hosts.
> > > >If running Windoze, LanMan, or SMB networking, also add them to
> > > >/etc/lmhosts. Similarly, add them to c:\windoze\hosts and lmhosts.
> > > >Since hostresorder looks for local name resolutions before going to the
> > > >internet for name resolution, you should not have any delays. I keep one
> > > >copy of hosts and lhosts on all my machines with provisions for
> > updating all
> > > >the others every time a change is made. (Yeah, I know it's lots of work).
> > >
> > > Jeff,
> > >
> > > bind', but if our internet connection goes down, telnet/ftp/pop takes about
> > > 2 minutes to connect. I just don't see where the hostresorder line is even
> > > being looked at. We're not running named on our OpenServer machine but are
> > > running routed. If what you say is suppose to work, what are we doing
> > wrong?
> > >
> >
> >I've noted before that on OpenServer if you have ever had DNS running,
> >something gets set that causes certain applications to appear to ignore
> >the hostresorder line even when named is no longer running. If DNS has
> >never been run, then this does not happen. No luck so far in tracking
> >down where the problem is.
> >
> >--
> >
> >Richard Seeder
> >aa...@worldnet.att.net
>
> That would explain it. We did try running DNS shortly a while back. If
> you do ever find out what I causing this, I'd sure like to know.
>
> Ken
I have had named running for a little while when my box was first set up. I
don't run it any more, and it does not take me 2 minutes to telnet in,
though I too used to have that problem. I'm not sure what the crucial thing
was that fixed the 2 minute problem, but here are some of my config files:
"alburner" is the sco5 box, "toybox" is a win98 box on a crossover ethernet
cable (no hub), xxx.xxx.xxx.xxx is my ISP's dns server, which is unavailable
90% of the time (dialup PPP connection)
For The Record: I did not really have a very good idea of what I was doing
when I set these files up. this is the result of some blind groping that you
could call trial&error if you wanted to gloss it over and be nice. :)
/etc/resolv.conf
hostresorder local bind
domain alburn
nameserver xxx.xxx.xxx.xxx
localhost 127.0.0.1
alburner 125.125.125.50
toybox 125.125.125.51
/etc/hosts
127.0.0.1 localhost
125.125.125.50 alburner alburner.alburn
125.125.125.51 toybox toybox.alburn
/etc/lmhosts
# I have entries in here, but they are commented out
# Yes I am using netbios in VisionFS and all is working well.
#125.125.125.50 alburner
#125.125.125.51 toybox
/etc/named.conf has been renamed (to /etc/named.conf.disabled) in order to
disable it. there is an rc script that will try to start named if named.conf
exists
/etc/default/tcp
DOMAIN=alburn
NETMASK=255.255.255.0
BROADCAST=125.125.125.255
/etc/rc.2/S83tcp
...(skip to about line 110)...
if [ "$do_ifs" = 1 ]; then
#
# Interface configuration -- edit as appropriate.
#
ifconfig lo0 127.0.0.1 perf 57344 57344 1
ifconfig -p net1 125.125.125.50 netmask 255.255.255.0 broadcast
125.125.125.255 perf 24576 24576 1
#ifconfig en0 `uname -n` $NETMASK $BROADCAST
#/etc/route add 224.0.0.0 125.125.125.50 0 > /dev/null 2>&1
fi
...(note I have two lines commented out. don't ask me why. later at about
line 201 I have routed, gated, and irdd commented out also)...
--
Brian K. White http://www.squonk.net/users/linut
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Brian K. White
addendum to my previous post:
on the win98 box (also the same when it was a win95 box)
I _do_not_have_ either c:\windows\hosts or lmhosts at all, only hosts.sam
and lmhosts.sam (and even neither of those has anything but comments)
I use telnet(several different free clients tried, including sco's
TermLite), http, ftp, and VisionFS clients to connect to the SCO box and no
2 minute delay. Though as I said, I *did* have this 2 minute thing sometime
last year for a few days. I got rid of it somehow. I don't remember which of
the many things I tried finally cleared it up. I'm using the stock sco
telnetd on the sco box.
Jeff Liebermann
wrote:
>Well, you made a bad guess. My win95 machines have a c:\windows\hosts and
>c:\windows\lmhosts that include our SCO machines IP. As far as the SCO box
>not being involved in DNS lookups, you are correct, EXCEPT that for some
>reason 'telnetd' wants to ignore /etc/hosts and do a DNS lookup when a
>win95 (or linux, or I would imagine any OS) machine trys to connect to the
>SCO machine. As far as /etc/resolv.conf only effecting programs on the SCO
>machine, I realize that. That's where telnetd is being run and where my
>problem lies.
Ok, that makes sense. So, you're getting a delay getting the initial
telnet login prompt? telnetd is probably trying to do a reverse DNS
lookup on your connected IP address in order to give you a human
readable connect line or something. From the man page at:
http://www.sco.com/cgi-bin/ssl_getmanpage?telnetd+ADMN+OS5
Quoting...
Normally, telnetd displays the system release, hostname, and
terminal port prior to the login prompt. The -h option
stops telnetd from displaying this information.
My guess(tm) is that the -h might turn off the reverse DNS lookup.
>Just an FYI, the win95 machines only run TCP/IP. They do not run
>netbuei. They have no DNS configured.
Drivel: The way Windoze tcp/ip networking works is to use Netbios
over tcp/ip. The DNS name lookup from Windoze I was refering to is fo
Netbios name lookups. My references are to Netbios and not Netbeui.
I've seen Windoze boxes that have both hosts and lmhosts configured,
yet still insist on doing Netbios name lookups. See the references in
my previous tirade on Windoze Netbios name lookup resolution order
bugs.
If you have no DNS configured, Windoze can still assign a DNS server
if you have DHCP running somewhere. Run:
winipcfg
or open an MSDOS window and run:
ipconfig /all | more
and see if you have DNS servers. I had one user fire up a DHCP server
on a company lan and send all the Windoze boxes off into the DNS
wonderland. It seems that "Disable DNS" really means "Get it from
DHCP".
>Wrong Jeff, this IS an SCO problem. It has nothing to do with our win95
>machines.When our gateway to our ISP is working....no problem. When it's
>not, I change /etc/resolv.conf to remove the 'nameserver' lines and change
>'hostresorder' from 'local bind' to 'local', then restart routed and
>everything works ok. I'm not changing anything anywhere else. It's
>OSR5.0.5 that's delaying the connect from telnet/ftp/pop, it's not that my
>win95 machines can't find the SCO box. 'ping' works just fine, also
>'tracert' works fine from the win95 machines to the SCO box. It's SCO's
>problem, always has been.
Dumb question: Why are you running routed? Are you using RIP-1
router updates to change the default route or add routes on the fly?
This is great stuff if you're running an ISP or a WAN with multiple
routes between sites, but for a small system, it's overkill.
One common problem is mis-spelling hostresorder. I know because I've
done it and experienced what the resolver does by default when no
order is specified. Learn by Destroying(tm). First, it tries the DNS
server. (This is from DNS and BIND in a Nutshell Pg 107). It tries 4
times. If it gets 4 errors (bogus domain), then it goes on to
/etc/hosts. However, if it gets only one timeout, as in the DNS
server not there, the application does NOT fall back on /etc/hosts. I
don't consider this to be particularly useful behavior, but that's
what I found when I was trying to figure out why various applications
were ignoring /etc/hosts. The logic is that the well maintained DNS
server will be more up to date than a local hosts file. Ugh.
You say the ping and tracert work immediately, yet telnet, ftp, and
pop3 have a delay. That doesn't make sense because both ping and
tracert use name resolution by default. Are you perhaps running:
ping -n osr5box
tracert -d osr5box
which disables name resolution?
I have about 6 customers using various Windoze telnet mutations used
to connect to 3.2v5.0.5 boxes running mostly Foxplus apps. Only one
has a full time internet connection. The rest are dial on demand.
None are running local DNS servers. I have seen the login prompt
delay problem on occassion, but it was never caused by the OSR5 box
configuration. If these customers were experiencing a telnet or pop3
connection delay, equal to the dialup time, they would be screaming at
me. While this is anecdotal evidence that the problem does not exist,
I'll certainly try it out when I drag myself to the office on Thurs or
Fri. Tcpdump, IPTraf, Netmon, and my cacheing DNS server logs, should
show any reverse DNS lookups issued by telnetd and such on initial
connection.
Jeff Liebermann
<je...@comix.santa-cruz.ca.us> wrote:
>You say the ping and tracert work immediately, yet telnet, ftp, and
>pop3 have a delay. That doesn't make sense because both ping and
>tracert use name resolution by default. Are you perhaps running:
> ping -n osr5box
> tracert -d osr5box
>which disables name resolution?
Oops, I goofed. ping and tracert do their DNS lookups on the client
(Windoze) side and not the OSR5 side. Never mind on that idea.
However, it is interesting that telnet, ftp, and pop3 all require
server daemons, while ping and tracert do not. If the server daemons
are doing reverse DNS lookups to get FQDN names for the prompt, that
might explain the differences in delays.
Ken Wolff
>On Tue, 13 Jun 2000 20:11:51 GMT, Ken Wolff <ke...@cscc.maximus.com>
>wrote:
>
> >My problem I with win95 machines, defined in /etc/hosts, running into the 2
> >minute (or there abouts) delay trying to telnet/ftp/pop to the OpenServer
> >machine when DNS is down.
>
>Stop. This is a Windoze problem, not an OSR5 problem. I don't know
>your network topology, but I'm guessing that you have your Windoze
>boxes configured with the DNS servers pointing to your ISP's DNS
>servers. The OSR5 box is not involved in the DNS lookups. Tweaking
>of /etc/resolv.conf only affects lookups initiated by programs running
>on the OSR5 box. (Disclaimer: This assumes the you're not running
>Merge, VisionFS, or AFPS, which will make the DNS configuration
Well, you made a bad guess. My win95 machines have a c:\windows\hosts and
c:\windows\lmhosts that include our SCO machines IP. As far as the SCO box
not being involved in DNS lookups, you are correct, EXCEPT that for some
reason 'telnetd' wants to ignore /etc/hosts and do a DNS lookup when a
win95 (or linux, or I would imagine any OS) machine trys to connect to the
SCO machine. As far as /etc/resolv.conf only effecting programs on the SCO
machine, I realize that. That's where telnetd is being run and where my
problem lies.
>different).
>
>Here's how to fix your problem:
>1. On your Windoze boxes, created files called:
> c:\windoze\hosts
> c:\windoze\lmhosts
>and fill them with various hostnames and IP addresses found on your
>local network, especially the the OSR5 box. See the files:
> c:\windoze\hosts.sam
> c:\windoze\lmhosts.sam
>for a sample configurations. If you're running Windoze NT, the files
>are:
> c:\winnt\system32\drivers\etc\hosts
> c:\winnt\system32\drivers\etc\hosts
>There is no need to reboot Windoze or perform other un-naturals acts
>to activate these files.
Per above, these files are already there.
>The lmhosts file is not optional and is required to keep Windoze from
>doing DNS lookups for Netbios name lookups.
Just an FYI, the win95 machines only run TCP/IP. They do not run
netbuei. They have no DNS configured.
>2. There are bugs in various Windoze mutations which prevent things
>from working as expected. Read:
>
>How to Disable NetBIOS Name Resolution on DNS
> http://support.microsoft.com/support/kb/articles/Q137/3/68.asp
>
>NetBIOS over tcp/ip name resolution and WINS
> http://support.microsoft.com/support/kb/articles/Q119/4/93.asp
>
>Windoze Does Not Parse LMHOSTS File with DNS enabled
> http://support.microsoft.com/support/kb/articles/Q137/8/56.asp
>
>Windoze Sockets 2.0 Does Not Use DnsNbtLookupOrder Value
> http://support.microsoft.com/support/kb/articles/Q216/4/70.asp
>
>In general, I do not think it possible to completely prevent a random
>Windoze machine from doing NetBios DNS lookups. Therefore, these
>calls must be trapped at the firewall or router. Just about every
>router worth spending money on has this feature.
>
>3. In the future, when you are discussing more than one machine,
>please be a bit more obvious as to which machine you're working on.
>
>
>
>--
>Jeff Liebermann je...@comix.santa-cruz.ca.us
>150 Felker St #D Santa Cruz CA 95060
>831-421-6491 pager 831-429-1240 fax
>http://www.cruzio.com/~jeffl/sco/ SCO stuff
Wrong Jeff, this IS an SCO problem. It has nothing to do with our win95
machines.When our gateway to our ISP is working....no problem. When it's
not, I change /etc/resolv.conf to remove the 'nameserver' lines and change
'hostresorder' from 'local bind' to 'local', then restart routed and
everything works ok. I'm not changing anything anywhere else. It's
OSR5.0.5 that's delaying the connect from telnet/ftp/pop, it's not that my
win95 machines can't find the SCO box. 'ping' works just fine, also
'tracert' works fine from the win95 machines to the SCO box. It's SCO's
problem, always has been.
Ken
David Mabo
our dns on our network, and using that, we are able to minimize these
problems when our connection is down. Now, I must admit, we have 2 SCO
and 5 HP-9000s runnig, and 3 HP and 1 SCO run as dns servers, but even 1
caching server would make life a little easier.
--
David H. Mabo, CPCM
Adaptix Corp. - Cincinnati, Ohio
Richard Seeder
If you have never run named on the SCO box, then you just need to make
sure that /etc/hosts is properly set up, and you don't need
hosts/lmhosts on the Winxx boxes. BTW, the .sam apparently stands for
"sample"; if you ever do set them up on Windows they need to be copied
without the extension.
--
Richard Seeder
aa...@worldnet.att.net
Richard Seeder
>
> On Tue, 13 Jun 2000 20:11:51 GMT, Ken Wolff <ke...@cscc.maximus.com>
> wrote:
>
> >My problem I with win95 machines, defined in /etc/hosts, running into the 2
> >minute (or there abouts) delay trying to telnet/ftp/pop to the OpenServer
> >machine when DNS is down.
>
> Stop. This is a Windoze problem, not an OSR5 problem. I don't know
> your network topology, but I'm guessing that you have your Windoze
> boxes configured with the DNS servers pointing to your ISP's DNS
> servers. The OSR5 box is not involved in the DNS lookups. Tweaking
> of /etc/resolv.conf only affects lookups initiated by programs running
> on the OSR5 box. (Disclaimer: This assumes the you're not running
> Merge, VisionFS, or AFPS, which will make the DNS configuration
>
<snip>
>
> --
> Jeff Liebermann je...@comix.santa-cruz.ca.us
> 150 Felker St #D Santa Cruz CA 95060
> 831-421-6491 pager 831-429-1240 fax
> http://www.cruzio.com/~jeffl/sco/ SCO stuff
No, it is an SCO problem. I have also seen it block Unix application
programs from finding Windows machines on the network, even though
everything is fine in /etc/resolv.conf and /etc/hosts. The odd thing
is, it only comes into play if you have ever run DNS on SCO (even a
caching only name server). This occurs whether or not routed is running
(routinely disabled on my installations).
--
Richard Seeder
aa...@worldnet.att.net
Ken Wolff
>On Wed, 14 Jun 2000 00:32:14 GMT, Ken Wolff <ke...@cscc.maximus.com>
>wrote:
>
> >Well, you made a bad guess. My win95 machines have a c:\windows\hosts and
> >c:\windows\lmhosts that include our SCO machines IP. As far as the SCO box
> >not being involved in DNS lookups, you are correct, EXCEPT that for some
> >reason 'telnetd' wants to ignore /etc/hosts and do a DNS lookup when a
> >win95 (or linux, or I would imagine any OS) machine trys to connect to the
> >SCO machine. As far as /etc/resolv.conf only effecting programs on the SCO
> >machine, I realize that. That's where telnetd is being run and where my
> >problem lies.
>
>telnet login prompt? telnetd is probably trying to do a reverse DNS
>lookup on your connected IP address in order to give you a human
>readable connect line or something. From the man page at:
> http://www.sco.com/cgi-bin/ssl_getmanpage?telnetd+ADMN+OS5
>Quoting...
> Normally, telnetd displays the system release, hostname, and
> terminal port prior to the login prompt. The -h option
> stops telnetd from displaying this information.
>My guess(tm) is that the -h might turn off the reverse DNS lookup.
I may give this a try. But in the next week I'm also going to be
installing our own local DNS server (Linux) and adding internal 172.20.1.x
addresses for all internal machines to that. I hope that may solve the
problem.
> >Just an FYI, the win95 machines only run TCP/IP. They do not run
> >netbuei. They have no DNS configured.
>
>Drivel: The way Windoze tcp/ip networking works is to use Netbios
>over tcp/ip. The DNS name lookup from Windoze I was refering to is fo
>Netbios name lookups. My references are to Netbios and not Netbeui.
>I've seen Windoze boxes that have both hosts and lmhosts configured,
>yet still insist on doing Netbios name lookups. See the references in
>my previous tirade on Windoze Netbios name lookup resolution order
>bugs.
I agree that netbios runs over tcp/ip. But that should have no bearing on
connecting to a specific SCO server via TCP/IP. Again, when our gateway to
our ISP is up, no problem. When it's down, I remove the 'nameserver' lines
from /etc/resolv.conf and everything works fine.
>If you have no DNS configured, Windoze can still assign a DNS server
>if you have DHCP running somewhere. Run:
> winipcfg
>or open an MSDOS window and run:
> ipconfig /all | more
>and see if you have DNS servers. I had one user fire up a DHCP server
>on a company lan and send all the Windoze boxes off into the DNS
>wonderland. It seems that "Disable DNS" really means "Get it from
>DHCP".
The only DNS servers we have is our ISP's. No WINS, no DHCP.
> >Wrong Jeff, this IS an SCO problem. It has nothing to do with our win95
> >machines.When our gateway to our ISP is working....no problem. When it's
> >not, I change /etc/resolv.conf to remove the 'nameserver' lines and change
> >'hostresorder' from 'local bind' to 'local', then restart routed and
> >everything works ok. I'm not changing anything anywhere else. It's
> >OSR5.0.5 that's delaying the connect from telnet/ftp/pop, it's not that my
> >win95 machines can't find the SCO box. 'ping' works just fine, also
> >'tracert' works fine from the win95 machines to the SCO box. It's SCO's
> >problem, always has been.
>
>Dumb question: Why are you running routed? Are you using RIP-1
>router updates to change the default route or add routes on the fly?
>This is great stuff if you're running an ISP or a WAN with multiple
>routes between sites, but for a small system, it's overkill.
I may be dumb here, but I thought I needed to run routed to set my system's
default route to my gateway. Do I not need to run routed? Can I do a
route add default xxx.xxx.xxx.xxx without routed running and will it
work. If so, I guess I don't need routed. BTW, this was advice I received
from one of the few calls I placed to SCO Support (what are they, services
and sales?).
<snip>
Ken
Jeff Liebermann
wrote:
>I may give this a try. But in the next week I'm also going to be
>installing our own local DNS server (Linux) and adding internal 172.20.1.x
>addresses for all internal machines to that. I hope that may solve the
>problem.
It probably will. Any response, from any nameserver will speed up the
logins if the ISP goes away. The problem comes from the application
waiting for a response on the assumption that the nameserver is simply
busy, and subsequent retried. DNS (named) is almost identical between
Linux and OSR5. If you can do one, you can do the other. Be sure to
do lots of testing with nslookup. You'll also find the OSR5 "host"
command to be quite useful as a less user-hostile front end to
nslookup.
>I may be dumb here, but I thought I needed to run routed to set my system's
>default route to my gateway. Do I not need to run routed?
You do NOT need to run routed unless you are running RIP. The
similarity of the "route" command, and the "routed" daemon is
undoubtably the source of this confusion.
>Can I do a
>route add default xxx.xxx.xxx.xxx without routed running and will it
>work.
Yep. I kill of routed on every one of my OSR5 servers and still have
a default route. Try it. Kill route and run:
netstat -rn
to see the routeing table.
>BTW, this was advice I received
>from one of the few calls I placed to SCO Support (what are they, services
>and sales?).
SCO Service Sales also known as 1-800-SCO-UNIX. Usually, they're a
bit better than that. They're not really SCO support but they are
suppose to be able to answer some techy questions.
I didn't get a chance to attempt to reproduce the telnet delay problem
(thanks to playing with a new digital camera and vehicle problems).
While I believe this is what you're seeing, I want to convince myself
it's real.
Dean Northam
I've been running OpenServer 3.24v5.05 Visionfs (currently 3.00.925) for
some time now with more or less no problems. I tried to upgrade one of the
Win98 nodes to Windows 2000 Professional. I can connect to other pc's on the
network but when I try to connect to the server i get the message:
\\servername is not accessible
A remote procedure call (RPC) protocol error occurred.
and when I right click on the server I get:
The server does not accept remote requests.
I'm not a expert setting up networks by any means but would GREATLY
appreciate any help.
PS - I've setup the "hosts" files on all the pc's and sco box, other than
using Wins Server in VisionFS I'm not running DCHP or DNS. I've been using
the ip addresses of 192.0.0.100 thru 192.0.0.150 and sub 255.255.255.0 with
my server at 192.0.0.113
Thank-you, Dean N.
Roberto Zini
We've been able to solve this particular issue by changing the
way VisionFS uses when dealing with passwords; AFAIK, VisionFS
*should* use UNENCRYPTED password by default while W2K uses
ENCRYPTED ones. To change the VFS password behavior, please
use the "visionfs password --wizard" command while operating
as root (please notice that if your W98 clients are using
PLAIN (unencrypted) passwords you'll have to change 'em
in order to send encrypted ones).
As a sidenote, the new version of VisionFS (3.1) due out
in mid-August should be W2K ready (see below) :
> SCO Vision2K Suite Release 2.1 is a major new release of the SCO Vision2K
> suite. This release supports Windows 2000 and contains major enhancements
> to SCO VisionFS and SCO TermVision. The infrastructure and robustness of
> each individual product have also been improved.
>
> - All SCO Vision2K products support Windows 2000 as a client
> - Host Wizard
> - Proxy Wizard
> - Roaming Profiles Support
> - Support for Passive FTP in UNIX neighborhood
> - Netscape Communicator 4.7 and RealPlayer software are included with
> the suite.
>
> SCO VisionFS 3.1
> The following enhancements and new features have been added to the SCO
> VisionFS product:
> - Ability to print from UNIX Server using lp
> - The new visionfs print install command automatically sets up a UNIX
> printer that prints to a Windows shared printer on the network. This
> means users can print to Windows printers from the UNIX command line,
> using lp or a UNIX application. Administrators can add as many of
> these printers as they need.
> - Mixed case share name and UNIX user names
> - SCO VisionFS now supports share names that include upper-case
> characters. UNIX printers names, used when generating automatic
> shared printers, may also include upper-case characters.
> - Improved performance
> - Improved name handling
> - Software fixes and incorporates all patches
Best,
Roberto
--
---------------------------------------------------------------------
Roberto Zini email : fr...@strhold.it
Technical Support Manager -- Strhold Sistemi EDP Reggio Emilia(ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)
Dean Northam
switched over to encrypted passwords, so it can't be that.
# ./visionfs status
SCO VisionFS 3.00.925 (Using OpenServer licensing)
Server names: fred
Netlogon services for: alltemp
Authentication: VisionFS (encrypted) passwords
VisionFS Administrators: dean, root, allan
The server is running.
I was thinking its something in W2K. I've loaded Windows network, Netbeui,
TCP/IP. Do I put ALLTEMP under domain or workgroup (under domain it says it
can't find it). The only other settings I have setup is the fixed ip address
& subnet and I loaded the WINS as my servers ip address. And I have Netbeui
over TCP/IP enabled.
Thanks Dean
"Roberto Zini" <fr...@strhold.it> wrote in message
news:396D70A4...@strhold.it...
Jim Richardson
"Dean Northam" <all...@globalserve.net> wrote:
> Thanks for the reply Robert, but a few days after setting up VisionFS
I
> switched over to encrypted passwords, so it can't be that.
>
Dean;
We are connecting from W2k to Unixware & Vision 3.x with no problems.
The way we do it is to use passthrough password varification to our NT
server. We have W2k Advanced server, NT 4, NT TSE, Unixware 7.1.x.
Woork stations are X-terms, 95/8 PCs, NT workstation and W2K
Professional. If you do not have an NT server, it's really easy to set
one up and most any old PC will do.
HTH
--
Jim Richardson
I like NT because it constantly reminds me of my daughter.
"Honest Daddy, I wasn't doing anything and it just broke."
Sent via Deja.com http://www.deja.com/
Before you buy.
Dean Northam
the extra system or the expense of buy NT server (at least thats what by
boss tells me). I have noticed something strange now that I've gotten into
this more. I get a RPC protocol error when try to browse the server but I
can make "net use drive: \\server\share" but I get an error in dos trying to
use "net view \\server" so its like the password is being passed thru but
something else blocking it. I give up thou.
Thanks all for the help!
--
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/free_video/
"Jim Richardson" <james_ri...@coastal.dnr.state.ga.us> wrote in message
news:8kn0fn$828$1...@nnrp1.deja.com...