Re: scp dropping connections

[christos%astron.com@localhost (Christos Zoulas)]

In article <20160408090513.d1d9cd1ea02ea764e0a1b7b1%googlemail.com@localhost>,
Sad Clouds  <cryintothebluesky%googlemail.com@localhost> wrote:
>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.

Please file a PR.

christos