[Libwebsockets] Settings Frame size above max / Flow control exceeded max

Andreas Lobbes Andreas.Lobbes at thinprint.com
Sun Jul 7 18:20:16 CEST 2019


Hello Andy,

wouldn't it be better, to handle those strange, but legal parameter per option?
OpenSSL for example offers such a feature, to work around dozens of mickysoft implementation bugs:
https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_clear_options.html
see macro SSL_OP_ALL and all defs above.
If OpenSSL did not offer such workarounds, a lot developer were not able to use it.
This in turn would neither have helped the developers nor the OpenSSL project to become widely accepted..

Kind regards,
Andreas

________________________________________
From: Andy Green [andy at warmcat.com]
Sent: Sunday, July 07, 2019 1:42 PM
To: Andreas Lobbes; libwebsockets at ml.libwebsockets.org
Subject: Re: [Libwebsockets] Settings Frame size above max / Flow control exceeded max

On 7/7/19 11:42 AM, Andreas Lobbes wrote:
> Hi,
>
> I try to make a https-request. In contrast to other sites, for this
> specific site the request does not succeed.
> The only hint I found in the log (see below) is "INF lws_h2_goaway:
> 0x55ebbce7ca20: ERR 0x1, 'Settings Frame size above max'". I suppose
> this is the root cause. Any I idea what that does mean?

Well, props for sending usable logs from the get-go.

> 2019-07-07 11:34:56 INF http2 settings 3 <- 0x80
> 2019-07-07 11:34:56 INF http2 settings 4 <- 0x10000
> 2019-07-07 11:34:56 DBG _realloc: size 56: pps
> 2019-07-07 11:34:56 INF lws_h2_goaway: 0x55ebbce7ca20: ERR 0x1,
> 'Settings Frame size above max'

The peer is sending a huge max frame size... above 16M-1 we're supposed
to reject it with PROTOCOL_ERROR like this.  But actually, we reject it
at 8M-1 as it is... it's a bug... I pushed a patch on v3.1-stable and
master that fixes it.

Although it's a bug to reject it... actually huge frame sizes 16M or 8M
generally don't make any sense... not just for latency (they would block
muxing until all 8M or 16M was sent) but for scalability, 1000 peers
taking it up on these monster frames and sending the on different
connections could allocate up to 16GB heap then.  So the peer should not
really be advertising this even though it's legal.

> 2019-07-07 11:34:56 INF LWS_H2_FRAME_TYPE_WINDOW_UPDATE
> 2019-07-07 11:34:56 INF WINDOW_UPDATE: sid 0 2147418112 (0x7fff0000)
> 2019-07-07 11:34:56 DBG _realloc: size 56: pps
> 2019-07-07 11:34:56 INF lws_h2_goaway: 0x55ebbce7ca20: ERR 0x3, 'Flow
> control exceeded max'

The tx credit window is not allowed to exceed 0x7fffffff.  The peer also
took a maximalist approach and told us we should bump our tx credit by
0x7fff0000.  Unfortunately it told us its tx credit was 0x10000 and we
adjusted our side to that already, so it comes to 0x80000000 IIUI.

Again tx credit window is a scheme to dynamically stop streams
monopolizing the multiplexed wire protocol... the combination of huge
frames and a license for any stream to spam 128 of those in succession
won't give good results for other streams or latency if the peer takes
them up on it.

-Andy


More information about the Libwebsockets mailing list