#422 Lost packets

closed
Todd Fujinaka
None
distro_driver
1
2015-03-11
2014-06-30
Dave Close
No

The following was originally sent to the e1000-devel list. Added here so the attachment gets through. I'm not sure this is actually a "bug".

I have a Fedora 20 machine which is receiving UDP broadcast packets at regular intervals on a high port. I have a program which is trying to receive these packets and failing to do so. As part of the bug investigation, I checked to see of Ncat would receive them. It also doesn't.

If I run, "tcpdump -i eth2 port 29531", I see each of the packets arriving just as I expect. But if I then run, "nc -lu 29531" or my program, I don't see anything!

On this machine, a Dell R510, eth0 and eth1 are motherboard ports with the bnx2 driver. eth2 through eth9 are provided by two 4-port Intel PCI cards with 82576 chips using the igb driver. The packets arrive on the Intel ports, eth2 through eth9. SELinux and the firewall are disabled on the machine.

If I move the cable to eth0, my application and Ncat see the packets. Of course, this solves nothing since I need it to work on the eight add-in ports. But comparing the output of "ethtool -k" on eth0 and eth2, I observe a few differences:

feature eth0 eth2
tx-checksum-sctp off [fixed] on
tx-tcp-ecn-segmentation on off [fixed]
rx-vlan-filter off [fixed] on [fixed]
rx-all off [fixed] on

I set rx-all on for eth2 because I also receive some packets with an invalid length field and need them to get through. The only other difference that seems like it might apply to a received packet is rx-vlan-filter but ethtool won't allow me to disable that feature. If this feature is relevant to the problem, how can I disable it?

Attached is a short pcap file containing a few of the packets which don't make it to an application program.

1 Attachments

Discussion

  • Todd Fujinaka
    Todd Fujinaka
    2014-07-02

    Looking at the datasheet, it looks like you need to set RCTL.SBP which requires a custom driver. I'm not sure if I'm misreading your question, though.

    The latest datasheet and spec update (which should also be consulted) are available publically on intel.com. Just type in "82576 datasheet" or "82576 spec update" into the search box.

     
  • Todd Fujinaka
    Todd Fujinaka
    2014-07-02

    • assigned_to: Todd Fujinaka
     
  • Dave Close
    Dave Close
    2014-07-09

    I have no reason to believe these packets are in any sense "bad". They are received correctly by the motherboard ports on the machine and by other units on the local network. What makes you think storing bad packets would make any difference in this case?

    If I do need a custom driver, where can I obtain or generate one? It does not seem reasonable to me that a vanilla packet like these should not be received normally by the standard driver. If that is true, then the value of the Intel ports drops significantly.

     
  • Todd Fujinaka
    Todd Fujinaka
    2014-07-24

    This question is also coming in through customer support.

    Closing.

     
  • Todd Fujinaka
    Todd Fujinaka
    2014-07-24

    • status: open --> closed
     
    • Dave Close
      Dave Close
      2014-07-25

      • status: open --> closed
      • Comment:

      This question is also coming in through customer support.
      Closing.

      As I was specifically requested to do...

      But they don't seem inclined to answer the question. Yesterday, I
      received a brush-off, telling me to ask on sourceforge. Surely,
      somebody at Intel can take the time to provide an answer.

      Dave Close
      
       
  • Todd Fujinaka
    Todd Fujinaka
    2014-07-25

    You asked the same question to support@intel.com, and the question was forwarded back to me. I don't need to track the same issue in two different areas.

    In those emails I added that you might consider setting RCTL.SBP in a custom driver. We don't help with custom drivers and you're on your own. I also provided the data sheet reference (section 7.1.2) that refers to why I think you need to try setting this bit.

    Later I was given some data on a netmask, but haven't looked at that yet.

    The questions on sourceforge are answered when we have time and there is no Terms of Service for questions filed here. If you need official support, you should contact your factory representative. If you purchased these cards through retail, then support@intel.com is your only official recourse.

    We have not seen the problems you're seeing, at least not with the details you've provided so far.

    So, please try modifying the driver on your own and see if that helps.

     
  • Todd Fujinaka
    Todd Fujinaka
    2014-07-29

    • status: closed --> pending
     
  • Todd Fujinaka
    Todd Fujinaka
    2015-03-11

    • status: pending --> closed