Loading ...
Sorry, an error occurred while loading the content.

Re: Debian slug and TCP checksum errors

Expand Messages
  • Adam Baker
    ... Is this not the issue described in the wireshark FAQ (I m assuming you are running wireshark on the slug). If the TCP checksum calculation gets offloaded
    Message 1 of 14 , Sep 27, 2007
    • 0 Attachment
      Jon Smirl <jonsmirl@...> writes:

      >
      > I used apt-get to upgrade my kernel to NSLU2 2.6.18-5-ixp4xx on Debian.
      >
      > I then used wireshark to capture some packets. Wireshark is reporting
      > that every TCP packet being transmitted has a checksum error.
      >
      > Is this something to do with the Intel network driver, do I have to
      > manually build kernel upgrades because of the license silliness?
      >

      Is this not the issue described in the wireshark FAQ (I'm assuming you are
      running wireshark on the slug). If the TCP checksum calculation gets
      offloaded to the hardware then wireshark will not see the correct checksums
      on transmitted packets.

      http://www.wireshark.org/faq.html#q11.1

      I'd GUESS that Christian's driver has been updated to make better use of
      the NPE hardware which is why the problem now appears. If the packets are
      being received by other devices it seems highly unlikely that the checksums
      on the wire are wrong.
    • Jon Smirl
      ... I have Wireshark on my 64b x86 box. It is the standard one from Ubuntu. Packets from the NSLU2 to my box are reported as having checksum errors. The
      Message 2 of 14 , Sep 27, 2007
      • 0 Attachment
        On 9/27/07, Adam Baker <slug@...> wrote:
        > Jon Smirl <jonsmirl@...> writes:
        >
        > >
        > > I used apt-get to upgrade my kernel to NSLU2 2.6.18-5-ixp4xx on Debian.
        > >
        > > I then used wireshark to capture some packets. Wireshark is reporting
        > > that every TCP packet being transmitted has a checksum error.
        > >
        > > Is this something to do with the Intel network driver, do I have to
        > > manually build kernel upgrades because of the license silliness?
        > >
        >
        > Is this not the issue described in the wireshark FAQ (I'm assuming you are
        > running wireshark on the slug). If the TCP checksum calculation gets
        > offloaded to the hardware then wireshark will not see the correct checksums
        > on transmitted packets.
        >
        > http://www.wireshark.org/faq.html#q11.1
        >
        > I'd GUESS that Christian's driver has been updated to make better use of
        > the NPE hardware which is why the problem now appears. If the packets are
        > being received by other devices it seems highly unlikely that the checksums
        > on the wire are wrong.

        I have Wireshark on my 64b x86 box. It is the standard one from Ubuntu.
        Packets from the NSLU2 to my box are reported as having checksum errors.

        The pattern seem to be that the checksums are not getting inserted
        into the packets.

        Checksum: 0x8389 [incorrect, should be 0x9947 (maybe caused by
        checksum offloading?)]
        Checksum: 0x8389 [incorrect, should be 0x9a55 (maybe caused by
        checksum offloading?)]
        Checksum: 0x8389 [incorrect, should be 0x950c (maybe caused by
        checksum offloading?)]
        Checksum: 0x8389 [incorrect, should be 0x90cf (maybe caused by
        checksum offloading?)]


        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >


        --
        Jon Smirl
        jonsmirl@...
      • Jon Smirl
        ... This does not occur if I load the net with a copy command. It is appearing on TCP packets that aren t followed immediately by another one. These packets
        Message 3 of 14 , Sep 27, 2007
        • 0 Attachment
          On 9/27/07, Jon Smirl <jonsmirl@...> wrote:
          > On 9/27/07, Adam Baker <slug@...> wrote:
          > > Jon Smirl <jonsmirl@...> writes:
          > >
          > > >
          > > > I used apt-get to upgrade my kernel to NSLU2 2.6.18-5-ixp4xx on Debian.
          > > >
          > > > I then used wireshark to capture some packets. Wireshark is reporting
          > > > that every TCP packet being transmitted has a checksum error.
          > > >
          > > > Is this something to do with the Intel network driver, do I have to
          > > > manually build kernel upgrades because of the license silliness?
          > > >
          > >
          > > Is this not the issue described in the wireshark FAQ (I'm assuming you are
          > > running wireshark on the slug). If the TCP checksum calculation gets
          > > offloaded to the hardware then wireshark will not see the correct checksums
          > > on transmitted packets.
          > >
          > > http://www.wireshark.org/faq.html#q11.1
          > >
          > > I'd GUESS that Christian's driver has been updated to make better use of
          > > the NPE hardware which is why the problem now appears. If the packets are
          > > being received by other devices it seems highly unlikely that the checksums
          > > on the wire are wrong.
          >
          > I have Wireshark on my 64b x86 box. It is the standard one from Ubuntu.
          > Packets from the NSLU2 to my box are reported as having checksum errors.
          >
          > The pattern seem to be that the checksums are not getting inserted
          > into the packets.
          >
          > Checksum: 0x8389 [incorrect, should be 0x9947 (maybe caused by
          > checksum offloading?)]
          > Checksum: 0x8389 [incorrect, should be 0x9a55 (maybe caused by
          > checksum offloading?)]
          > Checksum: 0x8389 [incorrect, should be 0x950c (maybe caused by
          > checksum offloading?)]
          > Checksum: 0x8389 [incorrect, should be 0x90cf (maybe caused by
          > checksum offloading?)]

          This does not occur if I load the net with a copy command.

          It is appearing on TCP packets that aren't followed immediately by
          another one. These packets are followed by a PSH, ACK and ACK.

          My guess would be the code that flush out packets based on a time out
          is not inserting the checksum.

          This is obvious to me because GMPC is sending a TCP packet once per
          second to the NSLU. That pattern makes the checksum fail on every
          transaction.


          >
          >
          > >
          > >
          > >
          > >
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          >
          >
          > --
          > Jon Smirl
          > jonsmirl@...
          >


          --
          Jon Smirl
          jonsmirl@...
        • Gordon Farquharson
          Hi Jon ... It would be helpful to know what version of the kernel your system had been running. Is that version still installed? You could check by either
          Message 4 of 14 , Sep 27, 2007
          • 0 Attachment
            Hi Jon

            On 9/27/07, Jon Smirl <jonsmirl@...> wrote:

            > On 9/27/07, Gordon Farquharson <gordonfarquharson@...> wrote:

            > > Did every TCP packet have a checksum error before you upgraded to
            > > 2.6.18-5-ixp4xx?

            > No, I was able to use Wireshark earlier without problem. My slug
            > hadn't been upgraded in about 18 months so it was probably running a
            > much older kernel.

            It would be helpful to know what version of the kernel your system had
            been running. Is that version still installed? You could check by
            either doing "dpkg -l 'linux-image*'" or "ls /boot".

            > Maybe an endian problem in computing the checksum? Does anyone else see this?

            I did a quick check with my NSLU2 running 2.6.18-5-ixp4xx and all TCP
            packets from the NSLU2 had the correct checksum.

            > How is the NPE firmware handled during an upgrade? Maybe my firmware is too old.

            The firmware file should be in /lib/firmware:

            $ ls -l /lib/firmware/
            total 12
            lrwxrwxrwx 1 root root 14 Jun 27 08:37 NPE-B -> NPE-B.01000201
            -rw-r--r-- 1 root root 11964 Jun 27 08:37 NPE-B.01000201

            The firmware is placed there during installation of Debian with the
            non-DFSG version of the Debian Installer that is on
            www.slug-firmware.net. Do you remember what version of the installer
            you used?

            Gordon

            --
            Gordon Farquharson
            GnuPG Key ID: 32D6D676
          • Gordon Farquharson
            Hi Jon ... Can you give me a procedure to recreate this particular network traffic? Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676
            Message 5 of 14 , Sep 27, 2007
            • 0 Attachment
              Hi Jon

              On 9/27/07, Jon Smirl <jonsmirl@...> wrote:

              > It is appearing on TCP packets that aren't followed immediately by
              > another one. These packets are followed by a PSH, ACK and ACK.
              >
              > My guess would be the code that flush out packets based on a time out
              > is not inserting the checksum.
              >
              > This is obvious to me because GMPC is sending a TCP packet once per
              > second to the NSLU. That pattern makes the checksum fail on every
              > transaction.

              Can you give me a procedure to recreate this particular network traffic?

              Gordon

              --
              Gordon Farquharson
              GnuPG Key ID: 32D6D676
            • Jon Smirl
              ... I have gmpc connected to mpd running on the nslu2. gmpc keeps a socket open but only sends about one packet a second over it I attached a small Wireshark
              Message 6 of 14 , Sep 27, 2007
              • 0 Attachment
                On 9/27/07, Gordon Farquharson <gordonfarquharson@...> wrote:
                > Hi Jon
                >
                > On 9/27/07, Jon Smirl <jonsmirl@...> wrote:
                >
                > > It is appearing on TCP packets that aren't followed immediately by
                > > another one. These packets are followed by a PSH, ACK and ACK.
                > >
                > > My guess would be the code that flush out packets based on a time out
                > > is not inserting the checksum.
                > >
                > > This is obvious to me because GMPC is sending a TCP packet once per
                > > second to the NSLU. That pattern makes the checksum fail on every
                > > transaction.
                >
                > Can you give me a procedure to recreate this particular network traffic?

                I have gmpc connected to mpd running on the nslu2. gmpc keeps a socket
                open but only sends about one packet a second over it

                I attached a small Wireshark capture. It has four packets with errors.


                >
                > Gordon
                >
                > --
                > Gordon Farquharson
                > GnuPG Key ID: 32D6D676
                >
                >
                >
                > Yahoo! Groups Links
                >
                >
                >
                >


                --
                Jon Smirl
                jonsmirl@...
              • Jon Smirl
                ... Looks like I was on 2.6.18-4, but I don t know that the problem wasn t in that kernel too and I didn t notice it. It doesn t show with a copy command.
                Message 7 of 14 , Sep 27, 2007
                • 0 Attachment
                  On 9/27/07, Gordon Farquharson <gordonfarquharson@...> wrote:
                  > Hi Jon
                  >
                  > On 9/27/07, Jon Smirl <jonsmirl@...> wrote:
                  >
                  > > On 9/27/07, Gordon Farquharson <gordonfarquharson@...> wrote:
                  >
                  > > > Did every TCP packet have a checksum error before you upgraded to
                  > > > 2.6.18-5-ixp4xx?
                  >
                  > > No, I was able to use Wireshark earlier without problem. My slug
                  > > hadn't been upgraded in about 18 months so it was probably running a
                  > > much older kernel.
                  >
                  > It would be helpful to know what version of the kernel your system had
                  > been running. Is that version still installed? You could check by
                  > either doing "dpkg -l 'linux-image*'" or "ls /boot".

                  Looks like I was on 2.6.18-4, but I don't know that the problem wasn't
                  in that kernel too and I didn't notice it. It doesn't show with a copy
                  command.

                  Maybe mpd has a funcky socket option set
                  mpd 0.12.1-1.1

                  >
                  > > Maybe an endian problem in computing the checksum? Does anyone else see this?
                  >
                  > I did a quick check with my NSLU2 running 2.6.18-5-ixp4xx and all TCP
                  > packets from the NSLU2 had the correct checksum.

                  Almost all of my packets are ok. What about a write to the socket that
                  doesn't fill the packet up and then tcp has a time out and transmits
                  the small packet? those are the ones that are failing.




                  >
                  > > How is the NPE firmware handled during an upgrade? Maybe my firmware is too old.
                  >
                  > The firmware file should be in /lib/firmware:
                  >
                  > $ ls -l /lib/firmware/
                  > total 12
                  > lrwxrwxrwx 1 root root 14 Jun 27 08:37 NPE-B -> NPE-B.01000201
                  > -rw-r--r-- 1 root root 11964 Jun 27 08:37 NPE-B.01000201
                  >
                  > The firmware is placed there during installation of Debian with the
                  > non-DFSG version of the Debian Installer that is on
                  > www.slug-firmware.net. Do you remember what version of the installer
                  > you used?

                  jonsmirl@NSLU2:/lib/firmware$ ls -l
                  total 12
                  lrwxrwxrwx 1 root root 14 Aug 19 14:56 NPE-B -> NPE-B.01000201
                  -rw-r--r-- 1 root root 11964 Aug 19 14:56 NPE-B.01000201
                  jonsmirl@NSLU2:/lib/firmware$

                  Don't remember the installer I used. Something from nslu2-linux.org.



                  >
                  > Gordon
                  >
                  > --
                  > Gordon Farquharson
                  > GnuPG Key ID: 32D6D676
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >


                  --
                  Jon Smirl
                  jonsmirl@...
                • Gordon Farquharson
                  Hi Jon ... Hmm... looks like mpd won t run without a sound device. I don t have one so I m unable to test the setup on my NSLU2. Hopefully, somebody else will
                  Message 8 of 14 , Sep 27, 2007
                  • 0 Attachment
                    Hi Jon

                    On 9/27/07, Jon Smirl <jonsmirl@...> wrote:

                    > I have gmpc connected to mpd running on the nslu2. gmpc keeps a socket
                    > open but only sends about one packet a second over it

                    Hmm... looks like mpd won't run without a sound device. I don't have
                    one so I'm unable to test the setup on my NSLU2. Hopefully, somebody
                    else will report on whether they see the problem.

                    Gordon

                    --
                    Gordon Farquharson
                    GnuPG Key ID: 32D6D676
                  • Jon Smirl
                    ... I plugged a USB one in. The can be had for $5. ... -- Jon Smirl jonsmirl@gmail.com
                    Message 9 of 14 , Sep 27, 2007
                    • 0 Attachment
                      On 9/27/07, Gordon Farquharson <gordonfarquharson@...> wrote:
                      > Hi Jon
                      >
                      > On 9/27/07, Jon Smirl <jonsmirl@...> wrote:
                      >
                      > > I have gmpc connected to mpd running on the nslu2. gmpc keeps a socket
                      > > open but only sends about one packet a second over it
                      >
                      > Hmm... looks like mpd won't run without a sound device. I don't have
                      > one so I'm unable to test the setup on my NSLU2. Hopefully, somebody
                      > else will report on whether they see the problem.

                      I plugged a USB one in. The can be had for $5.

                      >
                      > Gordon
                      >
                      > --
                      > Gordon Farquharson
                      > GnuPG Key ID: 32D6D676
                      >
                      >
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >


                      --
                      Jon Smirl
                      jonsmirl@...
                    • Jon Smirl
                      ... My bad, look the Wireshark capture I sent you. It is my x86 box generating the checkum errors, not the nslu2. I am reading the columns backwards. I m
                      Message 10 of 14 , Sep 27, 2007
                      • 0 Attachment
                        On 9/27/07, Gordon Farquharson <gordonfarquharson@...> wrote:
                        > Hmm... looks like mpd won't run without a sound device. I don't have
                        > one so I'm unable to test the setup on my NSLU2. Hopefully, somebody
                        > else will report on whether they see the problem.

                        My bad, look the Wireshark capture I sent you. It is my x86 box
                        generating the checkum errors, not the nslu2. I am reading the columns
                        backwards.

                        I'm running 2.6.23-rc7, something must have just broken there.

                        --
                        Jon Smirl
                        jonsmirl@...
                      • Jon Smirl
                        ... I got more info over on netdev. Wireshark is the problem. It does not correctly understand TCP offload. It is a known problem but it hasn t been fixed yet.
                        Message 11 of 14 , Sep 27, 2007
                        • 0 Attachment
                          On 9/27/07, Jon Smirl <jonsmirl@...> wrote:
                          > On 9/27/07, Gordon Farquharson <gordonfarquharson@...> wrote:
                          > > Hmm... looks like mpd won't run without a sound device. I don't have
                          > > one so I'm unable to test the setup on my NSLU2. Hopefully, somebody
                          > > else will report on whether they see the problem.
                          >
                          > My bad, look the Wireshark capture I sent you. It is my x86 box
                          > generating the checkum errors, not the nslu2. I am reading the columns
                          > backwards.
                          >
                          > I'm running 2.6.23-rc7, something must have just broken there.

                          I got more info over on netdev. Wireshark is the problem. It does not
                          correctly understand TCP offload. It is a known problem but it hasn't
                          been fixed yet.

                          --
                          Jon Smirl
                          jonsmirl@...
                        Your message has been successfully submitted and would be delivered to recipients shortly.