Re: scp dropping connections

[Sad Clouds <cryintothebluesky%googlemail.com@localhost>]

On Thu, 7 Apr 2016 10:48:28 -0600 (MDT)
Swift Griggs <swiftgriggs%gmail.com@localhost> 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.