If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):
From - Sat Sep 22 06:20:56 2001
Newsgroups: comp.unix.sco.misc
Path: typhoon.ne.mediaone.net!chnws06.ne.mediaone.net!24.147.2.43!chnws02.mediaone.net!newsfeed2.skycache.com!newsfeed1.cidera.com!Cidera!sjcppf01.usenetserver.com!usenetserver.com!cyclone.bc.net!nntp.cs.ubc.ca!enigma.xenitec.on.ca!news.xenitec.on.ca!news
From: Bela Lubkin <belal@caldera.com>
Subject: Re: TCP-IP problems on OS505
Resent-From: mmdf@xenitec.on.ca
Submit-To: scomsc@xenitec.on.ca
Content-Type: text/plain; charset=us-ascii
Cc: Karel Adams <k_adams@glo.be>
Organization: [resent by] The SCOMSC gateway and Propagation Society
Content-Disposition: inline
Date: Sat, 22 Sep 2001 08:59:37 GMT
Message-ID: <20010922015936.F5148@mammoth.ca.caldera.com>
User-Agent: Mutt/1.2.5i
To: scomsc@xenitec.on.ca
Mime-Version: 1.0
In-Reply-To: <bmWq7.5987$35.610950@iguano.antw.online.be>; from k_adams@glo.be on Sat, Sep 22, 2001 at 06:39:00AM -0000
References: <bmWq7.5987$35.610950@iguano.antw.online.be>
Sender: belal@caldera.com
Precedence: list
Lines: 68
Xref: chnws06.ne.mediaone.net comp.unix.sco.misc:103673
Karel Adams wrote:
> I am re-installing OS505.
> Basis install was no problem, also I applied RS505A
> Next I setup tcp-ip config, no problem,
> I can ping across the network in all directions.
> Next I downloaded patches to some other machine
> in the network and wanted to ftp them, trouble starts here.
> I can open an ftp session, and in it I can mkdir,
> cd and whatever. But when I try to 'put' a file, the
> directory entry is created but nothing gets written,
> and after a while the ftp client will time out.
> I then setup up trust relations and tried to rcp the files:
> exactly the same story. Everything is possible, except
> to write a file (reading one is without problem!)
> All these are identical with the client on os504,linux,
> or win98. It is a local 192.168.0 network with no
> additional routing.
> One thing I have observed: my telnet sessions are
> 'jerky', i.e. characters typed at the console sometimes
> take a few seconds before appearing.
>
> Any clues? Re-install TCP-IP?
These are all symptoms of your NIC driver failing to see incoming
packets in a timely manner. It is missing interrupts. `netstat -i` may
be informative (better `netstat -in` to avoid name lookups, which may
not work well under these circumstances). Next, look at `ndstat -l` for
more details.
Here are some likely causes:
- The NIC driver and NIC disagree about the cable (media) type; e.g. one
thinks it's 10Mbit while the other thinks it's 100Mbit; or one is trying
to operate half-duplex and the other full. Go into `netconfig`, look
for cable settings under the "Advanced" setup for the NIC. If anything
is set to "auto", change it to explicitly the right cable type you're
actually attached to. "auto" is a technical term meaning "take a wild
guess and go completely haywire if you're wrong". (Of course it is not
really a "cable" type but the agreed-upon protocol being spoken by
everyone else on that cable -- probably a router or hub.)
- The NIC and its driver disagree about what IRQ is being used to
service interrupts. Compare BIOS setup information, `hwconfig -h`, `hw
-vr pci`, etc. Or the NIC is sharing an IRQ with some other driver, and
something is going wrong. IRQs are supposed to be sharable, but it's
complex and many drivers do the wrong thing in ways which make them bad
neighbors, unable to share IRQs properly. Use BIOS setup, physical
movement of cards from one slot to another, etc., to browbeat the system
into not trying to share interrupts between those particular boards.
- You have a NIC which is similar enough to one of the ones supported by
the base 5.0.5 / rs505a operating system to be recognized, and
more-or-less operated, but not in a useful manner. You say you're
"reinstalling" so presumably it used to work. Maybe you previously had
a driver update which makes the same driver aware of the quirks of your
particular hardware model.
I vote for the first possibility -- cable type mismatch. You can
further probe for this by pinging the machine and observing `netstat -i`
stats. I predict you'll see incoming packets just fine. Then ping the
machine with large packets, just below the size of a full ethernet
frame: `ping -s 1400 badmachine`. Now I suspect you will not see
incoming packets. I don't understand why NICs are able to receive at
all when they're listening at the wrong speed, but they are; it just
doesn't work well.
>Bela<
Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)
| Views for this page | ||||
|---|---|---|---|---|
| Today | This Week | This Month | This Year | Overall |
| 3 | 23 | 76 | 1,093 | 4,383 |
/Bofcusm/645.html copyright 1997-2004 Bela Lubkin All Rights Reserved
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Add your comments