# Invalid ssh2 packet type: 224

## mansonquasch

Hi,

since a few weeks I get this error when trying to rsync from my home server to the laptop:

```
Received disconnect from 192.168.178.29: 2: Invalid ssh2 packet type: 224

rsync: [sender] write error: Broken pipe (32)

rsync error: unexplained error (code 255) at io.c(837) [sender=3.1.0]
```

Sometimes it starts working again if I reload the sshd server on the laptop. The reverse way (laptopt > server) works like a charme. sshd versions are the same. Useflags are the same. The server is an arm machine, though. Googling didn't result much, only on thread with a supposed patch from 2008.

Any idea?

Thanks,

m.

----------

## mansonquasch

Well, I tried it again the reverse way: invoking the same rsync command from the laptop to shovel the data from the server to the laptop:

```
Hm, kex protocol error: type 39 seq 85

dispatch_protocol_error: type 78 seq 86

Disconnecting: Invalid ssh2 packet type: 201

rsync: connection unexpectedly closed (1503468 bytes received so far) [receiver]

rsync error: error in rsync protocol data stream (code 12) at io.c(226) [receiver=3.1.0]

rsync: connection unexpectedly closed (290007 bytes received so far) [generator]

rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.0]
```

The directory I copy to on the laptop is a bind mount of another directory on a different hard disk. Maybe this is the problem?

----------

## mansonquasch

Ok, it is not the bind mount, because the error also occurs when I rsync directly to the source directory of the bind mount.

However, the error is completely random:

 *Quote:*   

> XXXX@localhost ~ $ rsync -av 192.168.178.20:/mnt/sda/Music/ /media/sdb/Musik/
> 
> receiving incremental file list
> 
> Metal/Sevendust/Next/
> ...

 

Quite frustrating...

----------

## mansonquasch

Just to let you know what I did:

Used this patch:

```
--- packet.c       2014-04-21 12:28:17.617685752 +0200

+++ packet.c    2014-04-21 12:29:14.607532001 +0200

@@ -1431,8 +1431,10 @@

         * return length of payload (without type field)

         */

        type = buffer_get_char(&active_state->incoming_packet);

-       if (type < SSH2_MSG_MIN || type >= SSH2_MSG_LOCAL_MIN)

+        if (type < SSH2_MSG_MIN)

                packet_disconnect("Invalid ssh2 packet type: %d", type);

+        else if (type >= SSH2_MSG_LOCAL_MIN && type <= SSH2_MSG_LOCAL_MAX)

+                type = SSH2_MSG_IGNORE;

        if (type == SSH2_MSG_NEWKEYS)

                set_newkeys(MODE_IN);

        else if (type == SSH2_MSG_USERAUTH_SUCCESS &&
```

and put it into /etc/portage/patches/net-misc/openssh

Luckily, the openssh ebuild has the epatch_user command enabled by default.

I've got the patch from here: https://lists.mindrot.org/pipermail/openssh-unix-dev/2008-February/026180.html

However, I am not very confident in this patch.

----------

## Hu

 *mansonquasch wrote:*   

> However, I am not very confident in this patch.

 What are you worried about?  If you want to paper over the problem by ignoring unhandled messages, that patch should do so perfectly.

Based on the output provided, it looks like you are experiencing random bad data in the TCP stream carrying the ssh connection.

----------

