Regression: VPN disconnects on receiving large packets

Nikos Mavrogiannopoulos n.mavrogiannopoulos at gmail.com
Fri Jun 24 00:57:53 PDT 2016


It could be that in CSTP mode the server doesn't respect the MTU. Does
the attached patch address the issue for you?

On Wed, Jun 22, 2016 at 5:59 PM, Davíð Steinn Geirsson <dsg at sensa.is> wrote:
> 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íð
>
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel
>
-------------- next part --------------
diff --git a/cstp.c b/cstp.c
index 892ba54..77a4400 100644
--- a/cstp.c
+++ b/cstp.c
@@ -826,7 +826,7 @@ int cstp_mainloop(struct openconnect_info *vpninfo, int *timeout)
 	   and add POLLOUT. As it is, though, it'll just chew CPU time in that
 	   fairly unlikely situation, until the write backlog clears. */
 	while (1) {
-		int len = vpninfo->deflate_pkt_size ? : vpninfo->ip_info.mtu;
+		int len = MAX(16384, vpninfo->deflate_pkt_size ? : vpninfo->ip_info.mtu);
 		int payload_len;
 
 		if (!vpninfo->cstp_pkt) {
diff --git a/openconnect-internal.h b/openconnect-internal.h
index fb2d558..f6d35b6 100644
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -116,6 +116,7 @@
 #define SHA1_SIZE 20
 #define MD5_SIZE 16
 
+#define MAX(x,y) ((x)>(y))?(x):(y)
 /****************************************************************************/
 
 struct pkt {


More information about the openconnect-devel mailing list