From owner-freebsd-stable Tue Jan 9 11:47:37 2001 Delivered-To: freebsd-stable@freebsd.org Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by hub.freebsd.org (Postfix) with ESMTP id DC50437B400 for ; Tue, 9 Jan 2001 11:47:16 -0800 (PST) Received: from grolsch.ai (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id DF57249; Tue, 9 Jan 2001 15:47:15 -0400 (AST) Date: Tue, 09 Jan 2001 15:47:15 -0400 From: "Jeroen C. van Gelderen" To: David Kelly Cc: Jonathan Lemon , stable@FreeBSD.ORG Subject: Re: Intel PRO/100+ driver or hardware? (Update) Message-ID: <179010000.979069635@grolsch.ai> In-Reply-To: <20010109130439.A48418@grumpy.dyndns.org> X-Mailer: Mulberry/2.0.6b2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --On Tuesday, January 09, 2001 13:04:39 -0600 David Kelly wrote: > On Tue, Jan 09, 2001 at 02:06:42PM -0400, Jeroen C. van Gelderen wrote: >> --On Monday, January 08, 2001 09:21:13 -0600 Jonathan Lemon >> wrote: >> [...] >> > It looks like 'hayek' is refusing to accept one of the segments that >> > 'keynes' is transmitting. The segment arrives at the machine, but >> > 'hayek' never sends an ACK. >> > >> > I'd look at 'netstat -s' and see whether any of the 'bad checksum' >> > counters are set, if so, then something is corrupting the packets. >> >> Just the flag I needed :-) As soon as the connection stalls, the >> bad-checksum counter goes trough the roof. And *every* re-transmitted >> packet seems to have a bad checksum as well. >> >> The hub is not busy at the moment I tried and none of the other TCP >> connections to and from this box are affected when this occurs. It seems >> that packets with certain content get mangled so that retransmits will >> never solve the problem. > > OK, that seems to be part of the key. You have hit on a data pattern > which will not make it thru some part of the link. Not an unheard of > situation. Often an impedance mismatch where the pattern resonates > and "rings" an extra bit out of place. Ah, so it may not just be my vivid imagination ;-) > Hard to say if the problem is the hub or the Intel card. But seemingly > the combination. Changing either to a different model and/or brand > solves the problem? I tried 2 hubs, one claims to be a cheap 8816TPC, the other NetGear DS108. Both give problems. Replacing the Intel card with a 3Com or SMC solves the problem. Of course I've tried multiple cables as well. Maybe this is relevant. The DS108 actually is a dual speed hub. IIRC it has a 10 Mbit bus and a 100 Mbit bus, connected with a little switch. The machine I'm testing against has a 10Mbit card. I tried forcing to Intel to 10Mbit and tried to transfer the file. It stalls after a couple of megabytes. I then forced the Intel card to 100Mbit mode and tried the transfer again (so it would have to go trough the switching device in the hub); That got me a little further (22 MB) but this transfer too stalled eventually. > Any chance you can capture and/or share the problem data? More than willing to, but I'm not sure how to do it most effectively. You just want the tcpdump data? Do I need to give any special arguments to tcpdump? Thanks + Cheers, Jeroen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message