Other UNIX boces connect OK to SCO 5.0.7; Windows won't?

We're setting up a new server with SCO OpenServer 5.0.7. This box has integrated network interfaces at 10/100 and 1000. We had added another 10/100 D-Link card because that's what we were using in the server we're replacing, but we found that we couldn't connect to it in any way from the other two SCO servers. After some research, we removed the D-Link interface and were immediately able to talk to the other servers using the integrated 10/100 interface.

However, since this will be a production machine, users will need to hit it from Windows. When we try this (on the 10/100), we see the following results:

From a DOS window:
ping   - Request timed out.
telnet - Could not open a connection to <address>.
ftp     - Connect: 10060
Esker TUN (emulator software) - connection failed with error 10060

What's wrong here?
Geoff_KovarikAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Geoff_KovarikAuthor Commented:
More information: The Unix boxes and the PCs are all connected to a big honkin' HP ProCurve switch; no routers in the building except one headed to the outside world.
0
gheistCommented:
What happens when you ping from other side ???
0
Geoff_KovarikAuthor Commented:
I'm glad you brought that up. I pinged from a variety of machines and discovered that we may have a subnetting problem. The Unix boxes are on the 0 subnet; any PC there can ping/telnet/ftp/TUN ok, and I can ping in the other direction (from the Unix box). If on the 1 or 2 subnet, it's not happening.

We're using a class A 90.0.0.0 network inside our firewall - not sure why. You'd think it would be 192 etc. The netmask on the Unix box is 255.255.255.0 and the broadcast address is 90.0.0.255 - problem there?
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Geoff_KovarikAuthor Commented:
However - I note that on the production box (which all PCs can hit), we have an IP of 90.0.0.1, netmask of 255.255.255.0 and b'cast of 90.0.0.255 - the last two identical to that of the box we can't hit. Eh?
0
wesly_chenCommented:
network:  90.0.0.0
netmask: 255.255.255.0
broadcast: 90.0.0.255
---
Class A ip range with class C subnet mask is fine.

The only thing you may concern is 90.0.0.0 is not a private IP range which some machine out on the internet will have the same
IP then you will have problem to conect that machine.

The issue I think is your route, or default gateway.
Please make sure your default gateway setting on SCO is right (pingable from SCO) and the routing table on the default
gateway is right.

Wesly
0
gheistCommented:
please post ifconfig -a or ipconfig /all outputs of boxes not willing to communicate to help me better understand your routing oddities.

90/8 is unallocated network, but this does not give you authority to hijack it, read RFC1918 for some networks for your private disposal
0
Geoff_KovarikAuthor Commented:
Sorry - I didn't mention that we're behind a router and firewall with NAT - we're not using this out on the Net.
0
Geoff_KovarikAuthor Commented:
Here's the ifconfig -a and netstat -rn from the Unix box with the problem. After collecting this data, I tried to ping the gateway (90.0.1.254) and failed. Another sysadmin suggested it might be because the first hop off the machine has to be on the same network - but this config is identical to that on the production box, which connects to Windows and Unix alike.

net1: flags=4043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
      inet 90.0.0.98 netmask ffffff00 broadcast 90.0.0.255
      perf. params: recv size: 32768; send size: 32768; full-size frames: 1
      ether 00:0c:f1:ce:9d:4c
lo0: flags=4049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
      inet 127.0.0.1 netmask ff000000
      perf. params: recv size: 57344; send size: 57344; full-size frames: 1
atl0: flags=404a<BROADCAST,LOOPBACK,RUNNING,MULTICAST> mtu 8232
      inet 0.0.0.0 netmask ff000000
      perf. params: recv size: 4096; send size: 8192; full-size frames: 1
      
Routing tables
Destination      Gateway            Flags    Refs      Use  Interface
default            90.0.1.254        UGS         1        639  net1
90                  90.0.0.98          UC           1            0  net1
90.0.0.98        127.0.0.1          UGHS       4          26  lo0
127.0.0.1        127.0.0.1          UH           2            2  lo0
224                90.0.0.98          UCS         0            0  net1

0
Geoff_KovarikAuthor Commented:
For comparison, here's the same info from the production box.

net1: flags=4043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
      inet 90.0.0.1 netmask ffffff00 broadcast 90.0.0.255
      perf. params: recv size: 24576; send size: 24576; full-size frames: 1
      ether 00:e0:4c:8b:09:ce
lo0: flags=4049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
      inet 127.0.0.1 netmask ff000000
      perf. params: recv size: 57344; send size: 57344; full-size frames: 1
atl0: flags=404a<BROADCAST,LOOPBACK,RUNNING,MULTICAST> mtu 8232
      inet 0.0.0.0 netmask ff000000
      perf. params: recv size: 4096; send size: 8192; full-size frames: 1

Routing tables
Destination      Gateway            Flags    Refs      Use  Interface
default            90.0.1.254         UGS         0       20    net1
90                  90.0.0.1             UC           1        0    net1
90                  90.0.0.1             UC           0        0    net1
90.0.0.1          127.0.0.1           UGHS       3       50    lo0
127.0.0.1        127.0.0.1           UH           2        2     lo0
224                90.0.0.1             UCS         0        0     net1
0
wesly_chenCommented:
> this will be a production machine, users will need to hit it from Windows
Could you provide the output of "ipconfig /all" and "route print" from one of Windows PC?

Wesly
0
Geoff_KovarikAuthor Commented:
This is from a PC that won't connect to the Unix box:

Active Routes:
Network Destination        Netmask               Gateway        Interface             Metric
          0.0.0.0                    0.0.0.0              90.0.1.254      90.0.1.104        1
         90.0.0.0                255.0.0.0              90.0.1.104      90.0.1.104        1
       90.0.1.104              255.255.255.255   127.0.0.1       127.0.0.1        1
   90.255.255.255           255.255.255.255     90.0.1.104      90.0.1.104        1
        127.0.0.0               255.0.0.0              127.0.0.1       127.0.0.1        1
        224.0.0.0               224.0.0.0                90.0.1.104    90.0.1.104        1
  255.255.255.255          255.255.255.255      90.0.1.104                  2        1
Default Gateway:             90.0.1.254

Persistent Routes:
  None

0 Ethernet adapter :



      Description . . . . . . . . : 3Com EtherLink PCI

      Physical Address. . . . . . : 00-01-02-74-58-69

      DHCP Enabled. . . . . . . . : No

      IP Address. . . . . . . . . : 90.0.1.104

      Subnet Mask . . . . . . . . : 255.0.0.0

      Default Gateway . . . . . . : 90.0.1.254

      Primary WINS Server . . . . :

      Secondary WINS Server . . . :

      Lease Obtained. . . . . . . :

      Lease Expires . . . . . . . :

0
wesly_chenCommented:
> 90.0.0.0                255.0.0.0              90.0.1.104      90.0.1.104       1
This route on the Windows PC tell you that all the class A network IP in 90.0.0.0 with use "broadcast"
with subnet mask 255.0.0.0 to get the mac ip then make a connection.
Your Unix boxes use class C subnet mask, but it's IP is within 90.0.0.0/8 range. So the package won't go to
default gateway. But the subnetmask mismatch might cause the problem.

> IP Address. . . . . . . . . : 90.0.1.104
> Subnet Mask . . . . . . . . : 255.0.0.0
> Default Gateway . . . . . . : 90.0.1.254

IMHO, this network infrastructure is not reliable.
1. Change the DHCP server to serve the scope 90.0.1.0/24 instead of 90.0.1.0/8, I mean change the subnet mask
    to 255.255.255.0
2. Create the routes on the default gateway 90.0.1.254. So the default serves the route among different subnet
    90.0.0.0/24, 90.0.1.0/24, 90.0.2.0/24.....
    Then all the 90.0.1.0/24 need to go through router to get to 90.0.0.0/24. There is no subnet mask mismatch issue.
3. (Highly recommended) change 90.0.0.0 to so other private range ( 10.0.0.0/8 or 172.16.0.0/16 - 172.31.0.0/16)
    according to RFC1918.

Wesly
0
wesly_chenCommented:
By the way, chagne the subnet mask of Unix boxes to 255.0.0.0 will resolve the issue, too.

Wesly
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Geoff_KovarikAuthor Commented:
Wesly, you're right! I can ping and telnet to the machine now from a PC on the 1 subnet, but can't ftp for some reason - daemon is running, but "connection closed by remote host" is the result.

 I wonder, though, why the 255.255.255.0 mask works for the production box.
0
wesly_chenCommented:
> can't ftp for some reason - daemon is running, but "connection closed by remote host" is the result
It's ftp issue, not network issue.
I'm not sure what's the ftp daemon on SCO, but you can check with
# telnet <IP> 21

Wesly
0
Geoff_KovarikAuthor Commented:
Here's the result:

220-
220 atp4 FTP server (Version wu-2.6.2(1) Tue Feb 18 02:26:24 PST 2003) ready.

I was able to log in to the server after this message.
0
wesly_chenCommented:
>  Version wu-2.6.2
wu-ftp, check /etc/ftpaccess
comment out:
deny-uid xxxxxx

Wesly
0
Geoff_KovarikAuthor Commented:
The "deny" parameter doesn't appear in /etc/ftpaccess, though it is described in the man page.

I'm still wondering, though, why the 255.255.255.0 mask works in production. Any more thoughts on that?

Thanks! You've all been really helpful so far...

0
wesly_chenCommented:
> why the 255.255.255.0 mask works in production. Any more thoughts on that?
It depends. If your PC can find the mac address of production server through broadcast, then the conection will be ok.
Apparently, your Windows PC could find the path to the SCO box so it fail. Subnet mask plays the major role here.
However, there are a lot of network factors involved (most of are layer 3 in OSI with some in layer 2).
You might need package sniffer to analyize where the package got drop.

For ftp , you might want to check for the firewall.
Do
# netstat -a
to check any daemon listening to TCP port 21.

Also ftp is the different issue from your topic.

Wesly
0
Geoff_KovarikAuthor Commented:
Thanks to both of you...I hope you think the point split is fair.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.