Regression: VPN disconnects on receiving large packets

[Davíð Steinn Geirsson]

Hi all,

Recently a coworker had some problems connecting to the company VPN
using openconnect. The same VPN worked fine for me. The only seeming
difference was the version of openconnect, as his was a newer version
from fedora 23 instead of the older one from debian stable I was using.

On the faulty versions, the VPN connects fine and works for a bit, but
then when the server sends a lot of data in one go (such as the result
of a 'ls' in a large directory over ssh), the VPN disconnects. Forcing a
smaller MTU with --mtu=1280 --base-mtu=1280 made no difference.

The last messages from the failing connection are as follows:
Connected tun0 as 10.26.103.76, using SSL
Unexpected packet length. SSL_read returned 1414 but packet is
53 54 46 01 05 8c 00 00
Unknown packet b2 c4 ba fa 75 bb 20 6d
Send BYE packet: Unknown packet received
Unknown error; exiting.

I did a 'git bisect' and this regression seems to have been added in
commit f26b11e7616bf735e8e34482433b198db862302d. Specifically, this
check for the magic header is failing:
+               if (vpninfo->cstp_pkt->hdr[0] != 'S' ||
vpninfo->cstp_pkt->hdr[1] != 'T' ||
+                   vpninfo->cstp_pkt->hdr[2] != 'F' ||
vpninfo->cstp_pkt->hdr[3] != 1 ||
+                   vpninfo->cstp_pkt->hdr[7])
                        goto unknown_pkt;

The connection works fine with the commit directly preceding this one,
50b085039216e45e5d510d4519347eea7b7f7679. It has the same check
(perfomed on the large buf instead of vpninfo->cstp_pkt->hdr) which
succeeds, yet both get their data from similar calls to cstp_read().

I'm a bit stuck here, does anyone have any ideas why cstp_read() would
be returning wrong data here?

Best regards,
Davíð

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160622/b332d94b/attachment.sig>