Weird KCP packets received by the client

We were notified by @hazae41 of some suspicious looking kcp traffic traffic arriving at the client. This traffic looks like it belongs to KCP sessions that do not correspond to the client's own KCP sessions.

I'm in the process of trying to reproduce this. Here is the patch they used to see the contents of the KCP packets:

kcp library logging patch

diff --git a/readloop.go b/readloop.go
index 697395a..1d8e17b 100644
--- a/readloop.go
+++ b/readloop.go
@@ -1,6 +1,7 @@
 package kcp
 
 import (
+       "log"
        "sync/atomic"
 
        "github.com/pkg/errors"
@@ -11,6 +12,7 @@ func (s *UDPSession) defaultReadLoop() {
        var src string
        for {
                if n, addr, err := s.conn.ReadFrom(buf); err == nil {
+                       log.Println("kcp <- ", buf)
                        // make sure the packet is from the same source
                        if src == "" { // set source address
                                src = addr.String()

and the following smux patch:

smux library logging patch

diff --git a/session.go b/session.go
index bc56066..1fe1122 100644
--- a/session.go
+++ b/session.go
@@ -96,7 +96,7 @@ func newSession(config *Config, conn io.ReadWriteCloser, client bool) *Session {
        s.chProtoError = make(chan struct{})
 
        if client {
-               s.nextStreamID = 1
+               s.nextStreamID = 5
        } else {
                s.nextStreamID = 0
        }

They report seeing smux headers that have a streamid of 3 regardless of the above change that starts stream ids at 5, and seeing kcp headers that do not contain recognizable kcp conv ids followed by a stream id of 3 and a TLS application packet (despite the fact that new KCP sessions should always contain a TLS handshake first since they represent a new OR conn).