Bug 14623
| Summary: | Some Netgear FS509s have problems | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Jonathan Lemon <jlemon> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
Jonathan Lemon wrote... > Upon further investigation, this appears to be a bit-pattern problem. > Attached is a file which refuses to transfer via a "ftp get". (The > smallest part of a /kernel file that I can figure out which will > reproduce the problem). > > Are there any known issues with either the Netgear switch or Alteon card? I haven't had any problems with the Alteon boards. I would suspect the switch. If you want to be sure that the card isn't at fault, get two, put them back to back, and ftp the file from one machine to another. I tried ftping your 'badfile' between two machines with 512K ACEnic boards (connected by fiber, no switch in between) and had no trouble: ftp> bin 200 Type set to I. ftp> get badfile local: badfile remote: badfile 200 PORT command successful. 150 Opening BINARY mode data connection for 'badfile' (12288 bytes). 100% |**************************************************| 12288 00:00 ETA 226 Transfer complete. 12288 bytes received in 0.00 seconds (12.07 MB/s) ftp> I also haven't had any trouble with these boards and an Alteon ACEswitch 180. So I would suspect the switch. Taking it out of the loop, if possible, might confirm whether or not it is the problem. Ken -- Kenneth Merry ken@kdm.org State Changed From-To: open->closed Netgear tech support confirmed that some FS509 units have knwon problems; one thing mentioned was a batch of faulty SGRAM. The unit in question is being RMA'd to Netgear, I'll reopen this PR if the new unit still has problems. |
Performing bulk data transfer between client and server results in packets disappearing. Further retransmits of the lost packet still do not result in the other end receiving the packet. More specifically, tcpdumps taken on both machines show the following pattern: (note: no packets were dropped by bpf during these traces) Client transmits on the order of 100 packets in at full blast to server, which acks the packets correctly. Server does not receive a packet that the client transmits (never shows up on tcpdump on the server side) Client retransmits missing packet using exponential backoff (1, 2, 4, 8, 16, etc). tcpdump on the client shows the packet being sent. tcpdump on the server shows no packets being received. No further progress is made on the connection. This is symmetric; it doesn't matter whether the sender is the server or the client; it happens both ways. 1. this only happens after a large number of packets are sent. (roughly between 145K to 310K bytes) 2. this does not happen when using two fxp0 cards. 3. other TCP sessions between the machines (e.g.: telnet) are unaffected. tcpdump traces, full dmesg output, or other information also available. How-To-Repeat: ftp a large file (/kernel) from one machine to another in the given environment.