News Group Posts

ifconfig atl0

The atl0 also has to do with virtual domains.

Other than that, atl0 is not easy to find in SCO docs.. it is needed, but unexplained.

If you happen to know anything more, drop a comment, please.

From: Tony Earnshaw <tearnshaw@landis.nl>
Newsgroups: comp.unix.sco.misc
Subject: Re: networking problem
Date: Fri, 28 Jan 2000 13:14:09 +0100
Message-ID: <38918811.73111F42@landis.nl> 
Cache-Post-Path: news.knoware.nl!unknown@frigg.ilion.nl

James Andrews wrote:

> (oss600a, rs505a, and oss497c), we downloaded the Realtek PCI 10/100
> network
> card driver

This has been commented on many times here. Realtek cards are not
suitable for SCO machines.

> >From searching the man pages and the SCO site, the only information
> I could gather about the atl0 interface is that it is some kind of
> "binding post" for IP aliases.  I had nothing of the sort set up,
> so the appearance of this atl0 was odd.

atl0 is so that the loopback will work at all. It seems to be peculiar
to SCO's Open Server.

You should never have to alter _anything_ on l0 or atl0, it won't help.

> An ifconfig atl0 revealed that the interface was down, the IP was
> set to 0.0.0.0 and the netmask was "0".  Not "0.0.0.0", just "0"

Proper netmask is xff0000.

> (and of course the MTU was 8???.

That's what it should be.

> On a hunch, I set the MTU of
> atl0 to 1500 (ifconfig atl0 mtu 1500) and guess what - I could
> now ping and telnet to all the internal machines, and they could
> do the same.  HOWEVER, I now could no longer ping or telnet any
> EXTERNAL machines.  (On a side note, the ifconfig atl0 also
> showed the LOOPBACK flag configured, just like the lo0 interface).
> Another ifconfig atl0 (and net1 and lo0) revealed that the atl0
> interface (still down!) now suddenly had a netmask of ff000000
> (255.0.0.0), identical (again) to the loopback device!  The error
> I got was 'no route to host' when trying to connect to 10.1.1.254
> or any other external IP with a traceroute.  In addition, after
> the no route to host message, it still tried to send a packet
> _directly_ to 10.1.1.254, NOT to the router (the routing table
> still showed the correct default route to 10.3.1.254).

______ snip ______

> At this point, I decided to try a completely new machine with a
> 3Com 3c905 PCI 10/100 network card (brand new Dell, known working
> 3Com card).

O.k., so now you're using a proper NIC. We have one of these on the
internal network and a 3C509 on the external one (connection to the
Internet via a 512 Kb leased line).

> 2) Add a default route (route add default 10.3.1.254).  This
>    has the effect of allowing me to ping and telnet to any
>    external machine (10.1.x.x, 10.2.x.x, etc.), but I am now
>    _completely_unable_ to connect to any local machine (10.3.x.x).

You only seem to have one NIC, therefore you're not using the SCO
machine as a router.

You should be able to route in the following situation:

SCO machine on 10.3.0.0, IP 10.3.0.1, netmask 255.255.0.0, default
gateway (netstat -rn) should show up as 10.0.3.2 (either through static
configuration or RIP), actual router IP on 10.3.0.0 could be 10.0.3.2,
netmask 255.255.0.0. Router IP on 10.1.0.0 is 10.1.0.1, netmask
255.255.0.0 (could be anything, but these are examples). IP forwarding
in router 'on'. Depending on the RIP version the router is using, each
hardware node on the router should know of the others' addresses as
gateways to the respective subnets. On all new hardware routers, default
RIP version is 2. On 5.0.5 it is also 2, so make sure you're running
routed if you're using RIP 2 on the rest of your network. 

> Considering both the upgrade and fresh install displayed identical
> behaviour, this leads me to believe that the operating system
> itself (SCO 5.0.5 + patches) is completely unuseable as a networked
> OS.

There's nothing wrong with SCO 5.0.anything as a networked OS. We use
it, hundreds of our customers use it and you can multiply this for each
SCO distributor throughout the world.

> I have an incredibly hard time believing that I am the first
> one to come across this problem.

Oh, you aren't. I did, when I started with network-coupling. But it was
because I didn't know enough at the time.

> I had thought perhaps it had to
> do with using a class B netmask on a class A address (which is
> an EXRTREMELY common thing to do), so I tried using a class B
> 172.16 address instead - again with identical results.  Perhaps
> it has something to do with the way the kernel handles using the
> 10.0.0.0 range of reserved (non-routed) IP addresses (or other
> reserved address ranges).

Actually, the kernel doesn't handle IP addresses at all, it handles
hard-coded MAC numbers. IP, netbios IPX/SPX etc are purely used to link
network protocols to the MAC layers. The kernel dosn't care what IP
number you have. The only place that reserved numbers won't be routed is
on the Internet - that is, if your router doesn't block out all RFC1918
private networks.

> Perhaps some logic somewhere is broken
> and automatically assumes a netmask based on the reserved IP,
> rather than checking.  Of course, this is highly unlikely.  And
> what is this rediculous atl0 interface?  This seems to be at the
> core of all the problems, considering the effect when I modified
> the atl0 settings (even while it was _down_).

As I said, you shouldn't have to _touch_ either the atl0 or l0
configurations - they work perfectly well as they are configured after
you've run netconfig. Rather, see that netstat -rn contains the correct
default gateway and that your router's configured properly.

Tony

-- 
************* THE NEW DIMENSION IN DISTRIBUTION ***********
  Landis ICT Services
  Tony Earnshaw                 email: tearnshaw@landis.nl
  Randstad 21-57
  1314 BH  Almere-Stad          tel: +31 (0) 36 548 50 10
  The Netherlands               fax: +31 (0) 36 534 05 34
***************** http://www.ilion.nl *********************

Comments?

More Articles by Tony Lawrence - Find me on Google+

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.