I've seen behavior like this before.  If the assymetric nature of the 
connections only exists between your sparc and other machines on the net
and not between any other two machines on the net, I'd say you have a
failing thin net tranceiver.  We had a problem about six months ago where a
tranceiver failed in just this way.  That is, incoming packets toward the
tranceiver worked fine, but outgoing packets would somehow causse the
tranceiver to toggle the carrier pin on the AUI port.  If you can get a
hold of another thin net tranceiver, I'd try changing that first.
-Brian

On Nov 21,  7:42pm, Greg Earle wrote:
} Subject: Asymmetric Ethernet problems and rash of "le0: lost carrier" mess
} Anyone ever seen a problem like this?  NetBSD/SPARC 1.2 (stock), SS2+Weitek.
} 
} Starting about 2 weeks ago, I constantly get a rash of "le0: lost carrier"
} messages all the time.  I've checked and re-checked the cabling and it
} seems fine, yet they still persist.  This isn't the "Oops, I pulled the
} Ethernet cable out of the back" type of lost carrier, either.  I can
} still get things done, but I'm really getting impacted by this.
} 
} It's most noticable on FTP transfers.  Receiving seems to be just fine,
} but *sending* stuff OUT from the SPARCstation is slower than molasses.
} 
} Two examples:
} 
} (1) FTP'ing from a Mac IIci (with a lame old Mac Ethernet card) to the Sun:
} 
} ftp> get cu-sudo.v1.5.3.tar.Z
} local: cu-sudo.v1.5.3.tar.Z remote: cu-sudo.v1.5.3.tar.Z
} 200 PORT command successful.
} 150 Opening BINARY mode data connection for 'cu-sudo.v1.5.3.tar.Z' (290655 bytes).
} 226 Transfer complete.
} 290655 bytes received in 58.2 seconds (4994 bytes/s)
} 
} ftp> cd /tmp
} 250 CWD command successful.
} ftp> put cu-sudo.v1.5.3.tar.Z
} local: cu-sudo.v1.5.3.tar.Z remote: cu-sudo.v1.5.3.tar.Z
} 200 PORT command successful.
} 150 Opening BINARY mode data connection for 'cu-sudo.v1.5.3.tar.Z'.
} 226 Transfer complete.
} 290655 bytes sent in 1.5 seconds (193776 bytes/s)
} 
} ftp> get cu-sudo.v1.5.3.tar.Z
} local: cu-sudo.v1.5.3.tar.Z remote: cu-sudo.v1.5.3.tar.Z
} 200 PORT command successful.
} 150 Opening BINARY mode data connection for 'cu-sudo.v1.5.3.tar.Z' (290655 bytes).
} 226 Transfer complete.
} 290655 bytes received in 67.5 seconds (4307 bytes/s)
} 
} When pulling *from* the SPARCstation, I get only 4.3 - 4.9 Kb/sec!
} When uploading *to* the Sun, it's almost 200 Kb/sec.
} 
} (2) Going from the SPARCstation to a SPARCserver 1000
} 
} ftp> put cu-sudo.v1.5.3.tar.Z
} local: cu-sudo.v1.5.3.tar.Z remote: cu-sudo.v1.5.3.tar.Z
} 200 PORT command successful.
} 150 Binary data connection for cu-sudo.v1.5.3.tar.Z (128.149.24.252,4792).
} 226 Transfer complete.
} 290655 bytes sent in 31 seconds (9387 bytes/s)
} 
} ftp> get cu-sudo.v1.5.3.tar.Z
} local: cu-sudo.v1.5.3.tar.Z remote: cu-sudo.v1.5.3.tar.Z
} 200 PORT command successful.
} 150 Binary data connection for cu-sudo.v1.5.3.tar.Z (128.149.24.252,4793) (290655 bytes).
} 226 Binary Transfer complete.
} 290655 bytes received in 0.395 seconds (736288 bytes/s)
} 
} Again, sending out from the SPARCstation gets me an extremely low transfer
} rate (9.3 Kb/sec) and a veritable rash of "le0: lost carrier" messages,
} yet pulling stuff from the SPARCserver *to* the SPARCstation zips right
} along at 735 Kb/sec with nary a complaint from the driver.
} 
} "netstat" isn't telling me anything obvious:
} 
} netbsd4me:1:36 [/tmp] % netstat -i
} Name  Mtu   Network     Address              Ipkts Ierrs    Opkts Oerrs  Coll
} le0   1500  128.149.24  netbsd4me.jpl.nas 10629175   827   797105  6287    52
} 
} Output errors are still under 1%.
} 
} I'm really puzzled as this asymmetric behavior.  The system is on a Thick
} Ethernet, and I'd think that if the cable was loose at the other end (i.e.,
} the transceiver box), I'd see poor performance both ways.  But I don't.
} 
} Does this ring any bells with anyone?
} 
} 	- Greg
} 
>-- End of excerpt from Greg Earle