On Fri, 8 Apr 2016 12:03:43 +0000 (UTC) chris...@astron.com (Christos Zoulas) wrote:
> In article <20160408090513.d1d9cd1ea02ea764e0a1b...@googlemail.com>, > Sad Clouds <cryintotheblue...@googlemail.com> wrote: > >On Thu, 7 Apr 2016 10:48:28 -0600 (MDT) > >Swift Griggs <swiftgri...@gmail.com> wrote: > > > >> On Thu, 7 Apr 2016, Christos Zoulas wrote: > >> > >I attached gdb on sparc64 to sshd process and after 30 seconds > >> > >got the following > >> > Do you have a NAT/firewall and you don't have keep state in your > >> > pass rules? > >> > >> I've also seen misconfigured NIDS system that are setup for TCP > >> "shootdown" (ie.. sending RSTs to both sides with valid SEQ > >> numbers causing an instant disconnect). Occasionally they will see > >> something in the encrypted data stream (or just the fact that it's > >> encrypted) and shoot down the connection because it violates some > >> network policy (usually just misconfigured to think that). > >> > >> If that's the cause, it's very easy to see it in a packet trace > >> because all the sudden out of nowhere you just see an RST hit you > >> and kill the connection. Then on the opposite (client) side, if > >> you take a trace at the same time, you won't see it actually > >> _sending_ the RST. Thus, you know a NIDS spoofed it. > >> > >> -Swift > >> > > > >Hello, I don't explicitly enable any NAT/Firewall rules on any of my > >local machine. All machines are on the same LAN, connected to a > >single 100Mbps switch. I run scp from NetBSD-7 on amd64 to NetBSD-7 > >on sparc64, sooner or later sshd on sparc64 exits with error. > > > >The way I manage to reproduce it: > > > >1. Enable tcp4csum and udp4csum for hme0 on sparc64 > > > >2. Simulate heavy I/O on sparc64 by unpacking src.tgz which contains > >pkgsrc, src and xsrc > > > >3. Start scp for a 3GB file from amd64 to sparc64 > > > >Sooner or later sshd on sparc64 exists with error > > > >Disabling tcp4csum and udp4csu for hme0 and repeating the above steps > >always succeeds to scp the entire 3GB file without any errors. > > > >So I'm inclined to think it's either hme0 hardware issue, or NetBSD > >kernel bug. > > Please file a PR. > > christos > kern/51057: hme(4) device driver bug when tcp4csum and udp4csum are enabled
