Help request: network connectivity

[bill]

SCO 5.0.5
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]

bill wrote:

> SCO 5.0.5
> 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.
>

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

[bill]

John Schmidt wrote:

> 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?
>

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
Technical Service Systems
bill (atsign) TechServSys (period) com

unix is user friendly, it is just careful who it befriends

[Jeff Liebermann]

On Fri, 15 Aug 2003 14:52:34 -0400, bill <nobody@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.

>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 [url]http://www.LearnByDestroying.com[/url]
# [email]jeffl@comix.santa-cruz.ca.us[/email]
# 831.421.6491 digital_pager [email]jeffl@cruzio.com[/email] AE6KS

[bill]

Jeff Liebermann wrote:

> On Fri, 15 Aug 2003 14:52:34 -0400, bill <nobody@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
Technical Service Systems
bill (atsign) TechServSys (period) com

unix is user friendly, it is just careful who it befriends

[bill]

bill wrote:

> Jeff Liebermann wrote:
>

>> On Fri, 15 Aug 2003 14:52:34 -0400, bill <nobody@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,...)

>>
>>

>>> 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
Technical Service Systems
bill (atsign) TechServSys (period) com

unix is user friendly, it is just careful who it befriends

[Brian K. White]

"bill" <nobody@spamcop.net> wrote in message
news:vjst1u2aoe1l18@corp.supernews.com...

> Jeff Liebermann wrote:
>

> > On Fri, 15 Aug 2003 14:52:34 -0400, bill <nobody@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 -- [email]brian@aljex.com[/email] -- [url]http://www.aljex.com/bkw/[/url]
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani