Professional Web Applications Themes

Help request: network connectivity - SCO

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 wins box uses dhcp to get addy from the router 2 wins 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 wins boxes I can ping the sco box and each other the wins boxes can reach the SCO hosted apache webserver vFS works fine on the SCO box It looks as if ...

  1. #1

    Default Help request: network connectivity

    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 wins box uses dhcp to get addy from the router
    2 wins 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 wins boxes I can ping the sco box and each other
    the wins 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 Guest

  2. #2

    Default Re: Help request: network connectivity: additional

    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 wins box uses dhcp to get addy from the router
    > 2 wins 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 wins boxes I can ping the sco box and each other
    > the wins 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 Guest

  3. #3

    Default Re: Help request: network connectivity: additional

    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

    bill Guest

  4. #4

    Default Re: Help request: network connectivity

    On Fri, 15 Aug 2003 14:52:34 -0400, bill <nobodyspamcop.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 doent.
    I'd like to add those to the doent. 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]jefflcomix.santa-cruz.ca.us[/email]
    # 831.421.6491 digital_pager [email]jefflcruzio.com[/email] AE6KS
    Jeff Liebermann Guest

  5. #5

    Default Re: Help request: network connectivity

    Jeff Liebermann wrote:
    > On Fri, 15 Aug 2003 14:52:34 -0400, bill <nobodyspamcop.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 doent.
    > I'd like to add those to the doent. 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 Guest

  6. #6

    Default Re: Help request: network connectivity

    bill wrote:
    > Jeff Liebermann wrote:
    >
    >> On Fri, 15 Aug 2003 14:52:34 -0400, bill <nobodyspamcop.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 doent.
    >> I'd like to add those to the doent. 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

    bill Guest

  7. #7

    Default Re: Help request: network connectivity


    "bill" <nobodyspamcop.net> wrote in message
    news:vjst1u2aoe1l18corp.supernews.com...
    > Jeff Liebermann wrote:
    >
    > > On Fri, 15 Aug 2003 14:52:34 -0400, bill <nobodyspamcop.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 doent.
    > > I'd like to add those to the doent. 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]brianaljex.com[/email] -- [url]http://www.aljex.com/bkw/[/url]
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani

    Brian K. White Guest

Similar Threads

  1. How do you test for FTP connectivity over a network?
    By lukaro in forum Macromedia Contribute Connection Administrtion
    Replies: 1
    Last Post: March 15th, 07:04 PM
  2. Replies: 1
    Last Post: July 29th, 05:27 AM
  3. No Network Connectivity After WIndows Update
    By Robert Neville in forum Windows Networking
    Replies: 0
    Last Post: July 17th, 07:25 AM
  4. DNS and network connectivity issues
    By ian in forum Windows Networking
    Replies: 1
    Last Post: July 15th, 03:31 PM
  5. network connectivity issues - esp w/ FTP
    By Jeff in forum Windows Networking
    Replies: 0
    Last Post: July 8th, 06:22 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139