Network works one way only

Discussion in 'Linux Networking' started by Dr. Oliver Muth, Apr 29, 2004.

  1. 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
     
    Dr. Oliver Muth, Apr 29, 2004
    #1
    1. Advertisements

  2. 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
     
    Alexander Clouter, Apr 29, 2004
    #2
    1. Advertisements

  3. 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
     
    Dr. Oliver Muth, May 10, 2004
    #3
  4. Dr. Oliver Muth

    Tauno Voipio Guest

    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
     
    Tauno Voipio, May 12, 2004
    #4
  5. 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:
    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.
    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.
    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, May 13, 2004
    #5
  6. Dr. Oliver Muth

    Tauno Voipio Guest

    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).
    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.
    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
     
    Tauno Voipio, May 13, 2004
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.