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
