Help request: network connectivity
bill
IP: 192.168.0.1
mask: 255.255.255.0
SCO box is connected to a switch
switch connects to SCO and 3 winXP boxes and to a Netgear
router/VPN/firewall
1 winblows box uses dhcp to get addy from the router
2 winblows boxes use static IPs
SCO uses a static IP
Following the reboot after the power outage I find:
from the sco box I can not ping anything
from the winblows boxes I can ping the sco box and each other
the winblows boxes can reach the SCO hosted apache webserver
vFS works fine on the SCO box
It looks as if the sco box is sending the wrong IP address as a return
address. I looked at the graphical TC/IP configuration data and it
shows the right address.
associated info:
Sendmail times out when starting from rc2.d .
netstat does not list anything in the amount of time I am willing to wait.
I would appreciate suggestions about where to look next.
Thanks,
-bill-
bill
ifconfig shows net1 as up and running with the correct inet
(there used to be two interfaces on the machine, net0 was removed some
time ago)
netstat -r after a long wait does list
Routing tables
Destination Gateway Flags Refs Use Interface
default 192.168.0.20 UGS 2 256 net1
localhost localhost UH 2 210 lo0
192.168 192.168.0.1 UC 1 0 net1
192.168.0.1 localhost UGHS 1 39 lo0
netstat -i (after a long wait) lists:
Name MTU Network Address Ipkts Ierrs Opkts Oerrs Coll
net1 1500 192.168 192.168.0.1 1995 0 2461 0 1455
lo0 8232 loopback localhost 267 0 267 0 0
atl0* 8232 none none No Statistics Available
--
bill
Technical Service Systems
bill (atsign) TechServSys (period) com
unix is user friendly, it is just careful who it befriends
Jeff Liebermann
>It looks as if the sco box is sending the wrong IP address as a return
>address. I looked at the graphical TC/IP configuration data and it
>shows the right address.
The long wait for netstat to return info implies that this is correct.
The SCO box is having a difficult time finding its own IP address. I
would look first in /etc/hosts and then in /etc/resolv.conf. My
guess(tm) is that someone changed the ip address, name, or removed an
interface (NIC) at some time in the past, and didn't finish the
tedious job of manually hacking the files. Netconfig doesn't catch
all the necessary changes.
>I would appreciate suggestions about where to look next.
Go through the shopping list at:
http://members.cruzio.com/~jeffl/sco/new_name.txt
and see if everything looks correct and sane.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
je...@comix.santa-cruz.ca.us je...@cruzio.com
John Schmidt
On Fri, 15 Aug 2003, bill wrote:
<snip>
> netstat -r after a long wait does list
<snip yet again>
> netstat -i (after a long wait) lists:
If you do "netstat -rn" and "netstat -in" are the same delays
present?
JS
bill
interestingly enough they were, BUT...
I changed the nameservers in reslov.conf to ones that were not still
down because of the power outage and the delays went away.
now I can ping domain.name and the ping resolves the host, but the pings
still don't come back.
I wonder if ipfilter is causing the problem...
yup, that was it. somehow an old ruleset was loaded (from when I had
two interfaces). Now, I know I never would have failed to move the new
ruleset to ipf.rules when I finished debugging it as ipf.rules-new.
Naw.......never...
Thanks for the suggestions.
bill
> On Fri, 15 Aug 2003 11:09:37 -0400, bill <nob...@spamcop.net> wrote:
>
>
>>It looks as if the sco box is sending the wrong IP address as a return
>>address. I looked at the graphical TC/IP configuration data and it
>>shows the right address.
>
>
> The long wait for netstat to return info implies that this is correct.
> The SCO box is having a difficult time finding its own IP address. I
> would look first in /etc/hosts and then in /etc/resolv.conf. My
> guess(tm) is that someone changed the ip address, name, or removed an
> interface (NIC) at some time in the past, and didn't finish the
> tedious job of manually hacking the files. Netconfig doesn't catch
> all the necessary changes.
>
>
>>I would appreciate suggestions about where to look next.
>
>
> Go through the shopping list at:
> http://members.cruzio.com/~jeffl/sco/new_name.txt
> and see if everything looks correct and sane.
>
your wonderful paper was what I used when I did change the IP address
some time ago and thanks for that.
it turns out that someone (read "me") debugged a new set of ipf rules
when I removed an interface and forgot to write the new rules to
ipf.rules. This box has been up ever since (over a year) and I was
using the test rules, but when I rebooted the old rules were reloaded.
fixed now and many thanks to those who helped.
Jeff Liebermann
>it turns out that someone (read "me") debugged a new set of ipf rules
>when I removed an interface and forgot to write the new rules to
>ipf.rules. This box has been up ever since (over a year) and I was
>using the test rules, but when I rebooted the old rules were reloaded.
Ah, IP filters wasn't around when I first scribbled that document.
I'd like to add those to the document. Could you save me the trouble
of reaching 3 ft to turn on the OSR5 server box and kindly supply the
full filenames that have IP's and/or names in IP filters? Nice to
hear about a box with >1 year uptime.
>fixed now and many thanks to those who helped.
One down and several million to go. Solving all the worlds problems
is hard work.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice http://www.LearnByDestroying.com
# je...@comix.santa-cruz.ca.us
# 831.421.6491 digital_pager je...@cruzio.com AE6KS
bill
> On Fri, 15 Aug 2003 14:52:34 -0400, bill <nob...@spamcop.net> wrote:
>
>
>>it turns out that someone (read "me") debugged a new set of ipf rules
>>when I removed an interface and forgot to write the new rules to
>>ipf.rules. This box has been up ever since (over a year) and I was
>>using the test rules, but when I rebooted the old rules were reloaded.
>
>
> Ah, IP filters wasn't around when I first scribbled that document.
> I'd like to add those to the document. Could you save me the trouble
> of reaching 3 ft to turn on the OSR5 server box and kindly supply the
> full filenames that have IP's and/or names in IP filters? Nice to
> hear about a box with >1 year uptime.
/etc/ipf.rules
>
>
>>fixed now and many thanks to those who helped.
>
>
> One down and several million to go. Solving all the worlds problems
> is hard work.
>
yeah, isn't it.
I just got done restoring power to Detroit. I appreciate your restoring
power to NY City.
bill
> Jeff Liebermann wrote:
>
>> On Fri, 15 Aug 2003 14:52:34 -0400, bill <nob...@spamcop.net> wrote:
>>
>>
>>> it turns out that someone (read "me") debugged a new set of ipf rules
>>> when I removed an interface and forgot to write the new rules to
>>> ipf.rules. This box has been up ever since (over a year) and I was
>>> using the test rules, but when I rebooted the old rules were reloaded.
>>
>>
>>
>> Ah, IP filters wasn't around when I first scribbled that document.
>> I'd like to add those to the document. Could you save me the trouble
>> of reaching 3 ft to turn on the OSR5 server box and kindly supply the
>> full filenames that have IP's and/or names in IP filters? Nice to
>> hear about a box with >1 year uptime.
>
>
>
> /etc/ipf.rules
>
/etc/ipf.rules may contain IPs (IPs not on the box, dividing into
trusted and untrusted) and interfaces (net0, net1,...)
Brian K. White
"bill" <nob...@spamcop.net> wrote in message
news:vjst1u2...@corp.supernews.com...
> Jeff Liebermann wrote:
>
> > On Fri, 15 Aug 2003 14:52:34 -0400, bill <nob...@spamcop.net> wrote:
> >
> >
> >>it turns out that someone (read "me") debugged a new set of ipf rules
> >>when I removed an interface and forgot to write the new rules to
> >>ipf.rules. This box has been up ever since (over a year) and I was
> >>using the test rules, but when I rebooted the old rules were reloaded.
> >
> >
> > Ah, IP filters wasn't around when I first scribbled that document.
> > I'd like to add those to the document. Could you save me the trouble
> > of reaching 3 ft to turn on the OSR5 server box and kindly supply the
> > full filenames that have IP's and/or names in IP filters? Nice to
> > hear about a box with >1 year uptime.
>
>
> /etc/ipf.rules
If I am not mistaken that is not a file Jeff should really list as if it
were a standard system file. Although I agree he should list it as a
possibility and/or a suggested replacement for whatever currently might be
found on joe random box.
I can't find anything in the man pages that ship with TLS709 or 5.0.7 that
even makes a suggestion about start scripts or config files so people will
have done all kinds of wierd things inventing their own arrangement from
scratch.
For example, on Tony Lawrences site, there is a nice post spelling out all
of someones live working ipf/ipnat setup so people can have a working
example to start from. That person used:
/etc/rc2.d/S99aroute
/usr/local/bin/firewallsetup
He should mention, somehow, to look for a file or files *like* this, but
that it might be named anything and that the script that runs it might
also be named anything or be called from anywhere in the rc startup maze.
Much the same way that until 5.0.6 there was no official place to put your
default route command.
Even the supplied /etc/mkfilters script avoids the issue by only printing
it's suggested rules to stdout.
Since sco's ipf/ipnat are just sco builds of an open source package that
already existed on other platforms, perhaps we should adopt the
arrangement used on one of those other platforms, or as close as can be
translated to OSR's directory structure? Your suggested /etc/ipf.rules
appears to follow that logic. Here is what I found...
netbsd:
/etc/rc.d/ipf.sh
/etc/rc.d/ipnat.sh
/etc/ipf.conf
/etc/ipnat.conf
openbsd:
?? probably /etc/rc.d/ip*.sh or /usr/local/etc/rc.d/ip*.sh
/etc/ipf.rules
/etc/ipnat.rules
freebsd:
/etc/rc.d/ipf.sh or /usr/local/etc/rc.d/ipf.sh
/etc/rc.d/ipnat.sh or /usr/local/etc/rc.d/ipnat.sh
/etc/ipf.rules
/etc/ipnat.rules
The start scripts obviously need to change.
I would suggest:
/etc/init.d/ipf
/etc/init.d/ipnat
and symlinks:
/etc/rc2.d/S98ipf
/etc/rc2.d/S99ipnat
The config files look good to me. I'd probably use .conf instead of .rules
so that they look like other config files to keep life simpler.
Supporting this idea, I found "man -a ipf" produced, among others,
ipf(SFF) which describes "ipf.conf" but does not say what directory to put
it in.
There is also a reasonable case for using
/etc/default/ipf
/etc/default/ipnat
instead of
/etc/ipf.conf
/etc/ipnat.conf
but I think I would slightly prefer the latter.
If anyone has a good rc script that also accounts for the event of the sco
box being a DHCP client perhaps it should be posted somewhere and
recommended to any who ask anything about ipf/ipnat.
Then answering questions would be a lot simpler. You could just answer
within this agreed-upon context and say: "this is not _the_ way to do it,
but it's _a_ way and it's the way most of us do it and as such it's the
way we will answer questions. get this tar, edit these files..."
The tar would contain the rc scripts, the symlinks (or the rc scripts
could have enable/disable options like the prngd & openssh ones have), and
the config files.
Then Jeff's page could list the files but only while at the same time
suggesting their use in the first place.
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani