[lkml]   [2001]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Client receives TCP packets but does not ACK

    The bad network behavior was due to shared irqs somehow screwing
    things up. This explained most but not all of the problems.


    Many people emailed me that they were experiencing similar problems.
    Even though the cause of my problem is not kernel related, I'm hoping
    my narrative and eventual solution will helps some folks. I also
    still think this behavior is really weird so those of you with an
    abundance of brains and curiosity might want to take a guess at
    explaining the behavior that I'm seeing.

    When I last posted I had a reproducible test case which spewed a bunch
    of packets from a server to a client. The behavior is that the client
    eventually stops ACKing and so the the connection stalls indefinitely.
    I spent some time studying the kernel networking code and traced the
    code path taken by a tcp packet:

    linux/net/core/dev.c:netif_rx() // packet received by eth card
    linux/net/ipv4/tcp_input.c:tcp_rcv_established() // packet placed in user queue

    Each routine had 2 to 6 conditions that would result in a dropped
    packet. I added printk statements for each of these conditions in
    hopes of detecting why the final packet is not acked. I recompiled
    the kernel, and reran the test. The result was that the packet was
    being droped in tcp_rcv_established() due to an invalid checksum. I
    then ran tcpdump to verify that the packets sent from the server were
    the same packets that were received by the client. It turned out that
    one byte was being corrupted and it was always the same byte in the
    stream that was corrupted.

    This was very confusing because my previous logs show _no_ corruption
    of the final packet.

    Anyway, now it appeared to be a hardware related problem so I started
    swapping ethernet cards to no effect. I then look at the irqs (cat
    /proc/interrupts) and noticed that the ethernet card in the client was
    sharing an irq with the aic7xxx scsi adapter. The following url made
    me think that this could be causing a problem:

    The motherboard on the client is an old Intel PR440FX (dual 200mhz
    PPro, onboard LAN, SCSI) and doesn't allow any kind of configuring of
    the irqs so I ended up throwing another pci net card in the box just
    to juggle the irqs enough so that one of the net cards was not sharing
    an irq with the scsi card. The bug no longer repros! Neither the
    reduced test case nor the original shows any problems.

    My only remaining questions are:

    1) Does this make sense? Would a scsi card sharing an irq with a net
    card cause rare but highly reproducable corruption? I was able to
    run http, telnet, ftp, mail, and games though this card with no
    problems. It only failed on a specific set of data. This is what
    initially led me to believe that the problem was not hardware

    2) Now that two net cards are sharing an irq, have I just trading one
    subtle corruption bug for another? Will some different data set
    cause the same type of corruption? Is it safe to share irqs?

    3) My old tcpdump logs (from several weeks ago) show _no_ corruption.
    I would have believed that I must have screwed up except that I
    still have the logs and the packets sent from the server compare
    exactly with those received by the client. I can't seem to
    reproduce this behavior.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:17    [W:0.025 / U:0.888 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site