Network works one way only

Hi!

My network works just in one-way mode:
To write to the file server works, but to read from it is real hard.

For testing purposes I connected now my laptop directly with the server.
(Ethernet cable, no Switch, 100Mbs).
Server and Laptop run Debian sarge (testing), kernel 2.4.25.

Samba:
Write to server: 4,4 MB/s
Read from server: 16 KB/s !!

nfs V3 (via tcp):
Write to server: 187 KB/s
Read from Server: 4 KB/s !!

nfs V3 (via udp, wsize=rsize=8192)
Write to server: 290 KB/s
Read from server: 0 KB/s stalls!!
Log message: server not responding, still trying.

I am (obviously ;-) ) no network expert, but since reading from the server
with nfs/udp did not work at all, I asked Ethereal.
Result:
One of my computers swallows all fragmented nfs-Packets.
The server is convinced of having sent them, but the client never receives them.
Why?

And why are there these enormous differences between reading and writing even
with the TCP connection?
(No, I did not use a floppy as test media ;-) )

System description:
Server hardware:
Athlon 2200+ on ASROCK K7VT2 with VIA Rhine II Ethernet on board
Client hardware:
IPC-Laptop with SiS 900 Ethernet on board
(but other clients make no difference...)
NO firewall, iptables are empty, policies on ACCEPT.
If helpful I can post an output of ethereal or nfsstat.

Any help is appreciated!

Oliver

On 2004-04-29, Dr. Oliver Muth <Dr.O.Muth@gmx.de> wrote:
> Hi!
>
> My network works just in one-way mode:
> To write to the file server works, but to read from it is real hard.
>
> For testing purposes I connected now my laptop directly with the server.
> (Ethernet cable, no Switch, 100Mbs).
> Server and Laptop run Debian sarge (testing), kernel 2.4.25.
>
> Samba:
> Write to server: 4,4 MB/s
> Read from server: 16 KB/s !!
>
you are mixing your network duplexes. Please force all your duplex settings
to half-duplex!

This could of been worked out with 30 seconds of Google'ing.....

Cheers

Alex

Hi Alexander

Thanks for your help (and apologies for not rsponding earlier).
Mii-tool reported for both network cards:
eth0: negotiated 100baseTx-FD, link OK

I changed to half-duplex, and it actually solved the problem.
But why?
Why can't I run both cards in full-duplex mode?
Or does one of the cards wrongly report its capabilities?

Best regards

Oliver

On Thu, 29 Apr 2004 22:15:25 +0100, Alexander Clouter wrote:
> On 2004-04-29, Dr. Oliver Muth <Dr.O.Muth@gmx.de> wrote:
>> Write to server: 4,4 MB/s
>> Read from server: 16 KB/s !!
>>
> you are mixing your network duplexes. Please force all your duplex settings
> to half-duplex!
>
> This could of been worked out with 30 seconds of Google'ing.....
>
> Cheers
>
> Alex

Dr. Oliver Muth wrote:
> Hi Alexander
>
> Thanks for your help (and apologies for not rsponding earlier).
> Mii-tool reported for both network cards:
> eth0: negotiated 100baseTx-FD, link OK
>
> I changed to half-duplex, and it actually solved the problem.
> But why?
> Why can't I run both cards in full-duplex mode?
> Or does one of the cards wrongly report its capabilities?
>
> Best regards
>
> Oliver

To get *any* advantage of full duplex, the whole path
between the peers must be full duplex, a single hub
on the way spoils it. The full duplex is not of
any significant help if there is not simultaneous
payload traffic in both directions at the same time.

The full duplex setting only prevents the interface
card from listening for traffic on the line before
transmitting, half duplex postpones transmitting till
the line is idle. If there is a full/half mismatch
on any segment, the full duplex end will misbehave
sending on top of other traffic, which creates plenty
of back-offs and retransmits.

There are hubs/switches which mis-negotiate the setting.

IMHO, full duplex is not worth the sweat, unless
the link belongs to a very busy backbone.

Tauno Voipio
tauno voipio @ iki fi

On Wed, 12 May 2004 19:36:05 +0000, Tauno Voipio wrote:

Hi Tauno,

thanks for your good explanation (that even I understood ;-) ).
But there is still a few things that I don't get yet:

> To get *any* advantage of full duplex, the whole path
> between the peers must be full duplex, a single hub
> on the way spoils it.
There is only a cable between the boxes. (Actually two cables and a
plain connector, since my crossover cable is not long enough.)
So, there shouldn't be anything impeding full duplex negotiation.

> The full duplex setting only prevents the interface
> card from listening for traffic on the line before
> transmitting, half duplex postpones transmitting till
> the line is idle. If there is a full/half mismatch
> on any segment, the full duplex end will misbehave
> sending on top of other traffic, which creates plenty
> of back-offs and retransmits.
Why does this selectively filter out fragmented packets?
Ethereal shows that the first fragment goes through,
but all following fragments of the same packet get lost.

And even more confusing to me:
Why does it help to set the interface of the server to half
duplex (with mii-tool) while leaving the interface of the laptop
on full duplex? I can manually set the interface of the laptop to whatever
I want to - it does not matter! Only if I set the server interface to half
duplex, the fragments come through.

BTW: Since it obviously does not have anything at all to to with the
nfs-server, I changed the test now: I use ping -s [packetsize > mtu]
instead of writing to and reading from an nfs-drive.
Of course I checked that the results are the same.

> There are hubs/switches which mis-negotiate the setting.
>
> IMHO, full duplex is not worth the sweat, unless
> the link belongs to a very busy backbone.
OK, but that forces me to always put those interfaces manually
into half duplex mode, since they auto-negotiate full duplex each time.
Isn't there a more elegant fix?

Or is one of the network cards or its driver broken?
How to find out which?

Best regards

Oliver

Dr. Oliver Muth wrote:
> On Wed, 12 May 2004 19:36:05 +0000, Tauno Voipio wrote:
>

>>The full duplex setting only prevents the interface
>>card from listening for traffic on the line before
>>transmitting, half duplex postpones transmitting till
>>the line is idle. If there is a full/half mismatch
>>on any segment, the full duplex end will misbehave
>>sending on top of other traffic, which creates plenty
>>of back-offs and retransmits.
>
> Why does this selectively filter out fragmented packets?
> Ethereal shows that the first fragment goes through,
> but all following fragments of the same packet get lost.

The crucial thing is timing: if the next fragment is
enqueued for sending while the other end is talking,
the fragment will be broken, and all broken packets
are silently discarded (except maybe incrementing
some broken packet status counter).

> And even more confusing to me:
> Why does it help to set the interface of the server to half
> duplex (with mii-tool) while leaving the interface of the laptop
> on full duplex? I can manually set the interface of the laptop to whatever
> I want to - it does not matter! Only if I set the server interface to half
> duplex, the fragments come through.

As above: It seems that your server is faster than
the laptop, and it's trying to talk on top of the
laptpop sends.

It seems that the server is not obeying the laptop
negotiation requests. Please check the settings
at both ends with mii-tool after forcing the laptop
to half-duplex.

> BTW: Since it obviously does not have anything at all to to with the
> nfs-server, I changed the test now: I use ping -s [packetsize > mtu]
> instead of writing to and reading from an nfs-drive.
> Of course I checked that the results are the same.
>
>
> OK, but that forces me to always put those interfaces manually
> into half duplex mode, since they auto-negotiate full duplex each time.
> Isn't there a more elegant fix?
>
> Or is one of the network cards or its driver broken?
> How to find out which?
>

The fix depends on the driver: on many cards the driver accepts
options for the set-up. If the driver is a module, the file
/etc/conf.modules or /etc/modules.conf (depending on distro)
can contain options for the driver. Some distros use a special
tool to collect the module option file from other set-up
files - see the distro documentation.

It's possible that either network adapter is not completely
working up to the MII (Media Independent Interface) negotiation
spec. On all the chips I know, the negotiation is on the
interface chip (or chip set).

It's also possible that the 100BASE-TX FDX is perfectly
correct, but the buffer space on the receiving chip is
not enough for your jumbo packets (several Ethernet frames).

HTH

Tauno Voipio
tauno voipio @ iki fi