asked on

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_Kovarik

ASKER

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.

SOLUTION

gheist

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Geoff_Kovarik

ASKER

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?

Geoff_Kovarik

ASKER

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?

wesly_chen

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

gheist

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

Geoff_Kovarik

ASKER

Sorry - I didn't mention that we're behind a router and firewall with NAT - we're not using this out on the Net.

Geoff_Kovarik

ASKER

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

Geoff_Kovarik

ASKER

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

wesly_chen

> 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

Geoff_Kovarik

ASKER

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 . . . . . . . :

SOLUTION

wesly_chen

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER CERTIFIED SOLUTION

wesly_chen

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Geoff_Kovarik

ASKER

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.

SOLUTION

wesly_chen

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Geoff_Kovarik

ASKER

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.

wesly_chen

> Version wu-2.6.2
wu-ftp, check /etc/ftpaccess
comment out:
deny-uid xxxxxx

Wesly

Geoff_Kovarik

ASKER

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

wesly_chen

> 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

Geoff_Kovarik

ASKER

Thanks to both of you...I hope you think the point split is fair.