On Mon, Jun 12, 2017 at 11:02 AM, Daniel Lenski <dlenski at gmail.com> wrote:
> This fixes the "Unexpected response of size 3 after hostname packet" error which I get intermittently when connecting to an old Juniper NC server:
>
> $ openconnect --prot=nc -vvvv
> ...
> NCP-Version: 2
> ...
> > 0000: 18 00 00 04 00 00 00 0c 00 64 65 61 64 62 65 65
> > 0010: 66 2d 31 32 33 bb 01 00 00 00 00
> Read 3 bytes of SSL record
> < 0000: d2 01 00
> Read 467 bytes of SSL record
>
> Here's what I think is going on: I believe this server is concatenating the
> 3-byte response packet together with the longer IP-configuration packet that
> follows (0x1d2 == 466, which suggests that it's encoding the size of the
> following packet).
>
> As far as I can tell, openconnect can simply ignore the first two bytes of
> the hostname response packet, and everything else proceeds normally.
This patch was an incomplete solution. I still don't understand why
this happens *intermittently*, but now that I've been able to
reproduce it a few more times, I've been able to fix it. Will send a
[PATCH v2] shortly.
Now for a better explanation of the change in the packet structure.
1. This is what openconnect v7.08 expects after sending the "hostname packet":
First SSL record: 01 00 ee
First two bytes indicate number of following bytes (LE), third
indicates success/error code
Second SSL record:: xx yy ... ...
First two bytes indicate number of following bytes (LE),
remainder are "KMP 301"
2. This is what this particular server is sometimes sending:
Single SSL record: xx yy ee ... ...
First two bytes indicate number of following bytes (LE)
Third bytes indicates success/error code
Remainder are "KMP 301" with no additional length prefix
Thanks,
Dan
