Mirrors/libwebsockets
1
0
Fork 0
mirror of https://github.com/warmcat/libwebsockets.git synced 2025-03-16 00:00:07 +01:00
Code Issues Releases Wiki Activity
libwebsockets/lib/secure-streams/secure-streams-serialize.c

1430 lines
33 KiB
C
Raw Normal View History

client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* libwebsockets - small server side websockets and web server implementation
*
* Copyright (C) 2019 - 2020 Andy Green <andy@warmcat.com>
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
* deal in the Software without restriction, including without limitation the
* rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*
*
* In the case Secure Streams protocol needs to pass through a buffer,
* or a streamed connection, the protocol metadata must be serialized. This
* file provides internal apis to perform the serialization and deserialization
* in and out of an lws_dsh fifo-type buffer.
*/
#include <private-lib-core.h>
typedef enum {
RPAR_TYPE,
RPAR_LEN_MSB,
RPAR_LEN_LSB,
RPAR_FLAG_B3,
RPAR_FLAG_B2,
RPAR_FLAG_B1,
RPAR_FLAG_B0,
RPAR_LATA3,
RPAR_LATA2,
RPAR_LATA1,
RPAR_LATA0,
RPAR_LATB7,
RPAR_LATB6,
RPAR_LATB5,
RPAR_LATB4,
RPAR_LATB3,
RPAR_LATB2,
RPAR_LATB1,
RPAR_LATB0,
RPAR_RIDESHARE_LEN,
RPAR_RIDESHARE,
sspc: ssv1: return policy about client dsh allocation Let's allow the proxy to pass back what the policy says about the size of dsh buffer the client side of this streamtype should have. Defer clientsize dsh generation until we got the info back from the proxy in the response to the initial packet. If it's zero / unset in the policy, just go with 32KB.
2020-12-31 15:08:48 +00:00
RPAR_RESULT_CREATION_DSH,
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
RPAR_RESULT_CREATION_RIDESHARE,
RPAR_METADATA_NAMELEN,
RPAR_METADATA_NAME,
RPAR_METADATA_VALUE,
RPAR_PAYLOAD,
RPAR_RX_TXCR_UPDATE,
RPAR_STREAMTYPE,
sspc: ssv1: add serialization protocol versioning Let's add a byte on the first message that sspc clients send, indicating the version of the serialization protocol that the client was built with. Start the version at 1, we will add some more changes in other patches and call v1 (now it has the versioning baked in) the first real supported serialization version, this patch must be applied with the next patches to actually represent v1 protocol changes. This doesn't require user setting, the client is told what version it supports in LWS_SSS_CLIENT_PROTOCOL_VERSION. The proxy knows what version(s) it can support and loudly hangs up on the client if it doesn't understand its protocol version.
2020-12-31 14:07:13 +00:00
RPAR_INIT_PROVERS,
sspc: ssv1: pass client PID into proxy for tagging Let's have the client processes pass in their pid, and tag the related proxy SS with that pid, so we can see on whose behalf the proxy is acting.
2020-12-31 14:56:43 +00:00
RPAR_INIT_PID,
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
RPAR_INITTXC0,
RPAR_TXCR0,
ss: add timeout
2020-06-30 16:42:37 +01:00
RPAR_TIMEOUT0,
sspc: add request_tx length variant Add in the missing request_tx length variant, serialization and proxy handling for it
2020-08-03 15:33:09 +01:00
RPAR_PAYLEN0,
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
RPAR_RESULT_CREATION,
RPAR_STATEINDEX,
RPAR_ORD3,
RPAR_ORD2,
RPAR_ORD1,
RPAR_ORD0,
} rx_parser_t;
#if defined(_DEBUG)
static const char *sn[] = {
"unset",
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
"LPCSPROX_WAIT_INITIAL_TX",
"LPCSPROX_REPORTING_FAIL",
"LPCSPROX_REPORTING_OK",
"LPCSPROX_OPERATIONAL",
"LPCSPROX_DESTROYED",
"LPCSCLI_SENDING_INITIAL_TX",
"LPCSCLI_WAITING_CREATE_RESULT",
"LPCSCLI_LOCAL_CONNECTED",
"LPCSCLI_ONWARD_CONNECT",
"LPCSCLI_OPERATIONAL",
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
};
#endif
void
lws_ss_serialize_state_transition(lws_ss_conn_states_t *state, int new_state)
{
#if defined(_DEBUG)
lwsl_info("%s: %s -> %s\n", __func__, sn[*state], sn[new_state]);
#endif
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
*state = (lws_ss_conn_states_t)new_state;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
/*
* event loop received something and is queueing it for the foreign side of
* the dsh to consume later as serialized rx
*/
int
lws_ss_serialize_rx_payload(struct lws_dsh *dsh, const uint8_t *buf,
size_t len, int flags, const char *rsp)
{
lws_usec_t us = lws_now_usecs();
uint8_t pre[128];
int est = 19, l = 0;
if (flags & LWSSS_FLAG_RIDESHARE) {
/*
* We should have the rideshare name if we have been told it's
* on a non-default rideshare
*/
assert(rsp);
coverity: 62570: back up assert with unconditional NULL check
2020-08-18 13:10:30 +01:00
if (!rsp)
return 1;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
l = (int)strlen(rsp);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
est += 1 + l;
} else
assert(!rsp);
// lwsl_user("%s: len %d, flags: %d\n", __func__, (int)len, flags);
// lwsl_hexdump_info(buf, len);
pre[0] = LWSSS_SER_RXPRE_RX_PAYLOAD;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
lws_ser_wu16be(&pre[1], (uint16_t)(len + (size_t)est - 3));
lws_ser_wu32be(&pre[3], (uint32_t)flags);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lws_ser_wu32be(&pre[7], 0); /* write will compute latency here... */
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
lws_ser_wu64be(&pre[11], (uint64_t)us); /* ... and set this to the write time */
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* If we are on a non-default rideshare, append the non-default name to
* the headers of the payload part, 1-byte length first
*/
if (flags & LWSSS_FLAG_RIDESHARE) {
pre[19] = (uint8_t)l;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
memcpy(&pre[20], rsp, (unsigned int)l);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
if (lws_dsh_alloc_tail(dsh, KIND_SS_TO_P, pre, (unsigned int)est, buf, len)) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lwsl_err("%s: unable to alloc in dsh 1\n", __func__);
return 1;
}
return 0;
}
/*
* event loop is consuming dsh-buffered, already-serialized tx from the
* foreign side
*/
int
lws_ss_deserialize_tx_payload(struct lws_dsh *dsh, struct lws *wsi,
lws_ss_tx_ordinal_t ord, uint8_t *buf,
size_t *len, int *flags)
{
uint8_t *p;
size_t si;
if (lws_dsh_get_head(dsh, KIND_C_TO_P, (void **)&p, &si)) {
*len = 0;
return 0;
}
/*
* The packet in the dsh has a proxying serialization header, process
* and strip it so we just forward the payload
*/
if (*len <= si - 23 || si < 23) {
/*
sspc: fix intree build for sspc examples and increase post example body Correct a comment about payload layout and add detailed comments about dsh handling at proxy. Increase the post size so it shows up fragmentation issues at the proxy.
2020-08-13 12:31:35 +01:00
* What comes out of the dsh needs to fit in the tx buffer...
* we have arrangements at the proxy rx of the client UDS to
* chop chunks larger than 1380 into seuqential lumps of 1380
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
*/
lwsl_err("%s: *len = %d, si = %d\n", __func__, (int)*len, (int)si);
assert(0);
return 1;
}
if (p[0] != LWSSS_SER_TXPRE_TX_PAYLOAD) {
assert(0);
return 1;
}
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
*len = (size_t)(lws_ser_ru16be(&p[1]) - (23 - 3));
sspc: extend assert length check to explicit code
2020-08-21 17:39:59 +01:00
if (*len != si - 23) {
/*
* We cannot accept any length that doesn't reflect the actual
* length of what came in from the dsh, either something nasty
* happened with truncation or we are being attacked
*/
assert(0);
return 1;
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
memcpy(buf, p + 23, si - 23);
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
*flags = (int)lws_ser_ru32be(&p[3]);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
#if defined(LWS_WITH_DETAILED_LATENCY)
fakewsi: replace with smaller substructure Currently we always reserve a fakewsi per pt so events that don't have a related actual wsi, like vhost-protocol-init or vhost cert init via protocol callback can make callbacks that look reasonable to user protocol handler code expecting a valid wsi every time. This patch splits out stuff that user callbacks often unconditionally expect to be in a wsi, like context pointer, vhost pointer etc into a substructure, which is composed into struct lws at the top of it. Internal references (struct lws is opaque, so there are only internal references) are all updated to go via the substructre, the compiler should make that a NOP. Helpers are added when fakewsi is used and referenced. If not PLAT_FREERTOS, we continue to provide a full fakewsi in the pt as before, although the helpers improve consistency by zeroing down the substructure. There is a huge amount of user code out there over the last 10 years that did not always have the minimal examples to follow, some of it does some unexpected things. If it is PLAT_FREERTOS, that is a newer thing in lws and users have the benefit of being able to follow the minimal examples' approach. For PLAT_FREERTOS we don't reserve the fakewsi in the pt any more, saving around 800 bytes. The helpers then create a struct lws_a (the substructure) on the stack, zero it down (but it is only like 4 pointers) and prepare it with whatever we know like the context. Then we cast it to a struct lws * and use it in the user protocol handler call. In this case, the remainder of the struct lws is undefined. However the amount of old protocol handlers that might touch things outside of the substructure in PLAT_FREERTOS is very limited compared to legacy lws user code and the saving is significant on constrained devices. User handlers should not be touching everything in a wsi every time anyway, there are several cases where there is no valid wsi to do the call with. Dereference of things outside the substructure should only happen when the callback reason shows there is a valid wsi bound to the activity (as in all the minimal examples).
2020-07-19 08:33:46 +01:00
if (wsi && wsi->a.context->detailed_latency_cb) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* use the proxied latency information to compute the client
* and our delays, and apply to wsi.
*
* + 7 u32 us held at client before written
* +11 u32 us taken for transit to proxy
* +15 u64 ustime when proxy got packet from client
*/
lws_usec_t us = lws_now_usecs();
wsi->detlat.acc_size = wsi->detlat.req_size = si - 23;
wsi->detlat.latencies[LAT_DUR_PROXY_CLIENT_REQ_TO_WRITE] =
lws_ser_ru32be(&p[7]);
wsi->detlat.latencies[LAT_DUR_PROXY_CLIENT_WRITE_TO_PROXY_RX] =
lws_ser_ru32be(&p[11]);
wsi->detlat.latencies[LAT_DUR_PROXY_RX_TO_ONWARD_TX] =
us - lws_ser_ru64be(&p[15]);
wsi->detlat.latencies[LAT_DUR_USERCB] = 0;
}
#endif
// lwsl_user("%s: len %d, flags: %d\n", __func__, (int)*len, *flags);
// lwsl_hexdump_info(buf, *len);
lws_dsh_free((void **)&p);
return 0;
}
/*
* event loop side is issuing state, serialize and put it in the dbuf for
* the foreign side to consume later
*/
int
lws_ss_serialize_state(struct lws_dsh *dsh, lws_ss_constate_t state,
lws_ss_tx_ordinal_t ack)
{
sspc: http map proxying fixes
2020-09-22 07:39:24 +01:00
uint8_t pre[12];
sspc: extend RXPRE_CONNSTATE to handle 8 or 32-bit states Currently only the low 8 bits of an SS state are proxied in a total packet length of 8 octets. Keep that format and behaviour since all the defined states fit in 8 bits, but also allow for 32-bit states using a packet length of 11 octets with the same command. This lets us proxy user states (from http mapping) which start at a user base of 1000.
2020-09-20 07:03:23 +01:00
int n = 4;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
lwsl_info("%s: %s, ord 0x%x\n", __func__, lws_ss_state_name((int)state),
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
(unsigned int)ack);
pre[0] = LWSSS_SER_RXPRE_CONNSTATE;
pre[1] = 0;
sspc: extend RXPRE_CONNSTATE to handle 8 or 32-bit states Currently only the low 8 bits of an SS state are proxied in a total packet length of 8 octets. Keep that format and behaviour since all the defined states fit in 8 bits, but also allow for 32-bit states using a packet length of 11 octets with the same command. This lets us proxy user states (from http mapping) which start at a user base of 1000.
2020-09-20 07:03:23 +01:00
if (state > 255) {
pre[2] = 8;
sspc: http map proxying fixes
2020-09-22 07:39:24 +01:00
lws_ser_wu32be(&pre[3], state);
sspc: extend RXPRE_CONNSTATE to handle 8 or 32-bit states Currently only the low 8 bits of an SS state are proxied in a total packet length of 8 octets. Keep that format and behaviour since all the defined states fit in 8 bits, but also allow for 32-bit states using a packet length of 11 octets with the same command. This lets us proxy user states (from http mapping) which start at a user base of 1000.
2020-09-20 07:03:23 +01:00
n = 7;
} else {
pre[2] = 5;
pre[3] = (uint8_t)state;
}
lws_ser_wu32be(&pre[n], ack);
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
if (lws_dsh_alloc_tail(dsh, KIND_SS_TO_P, pre, (unsigned int)n + 4, NULL, 0)) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lwsl_err("%s: unable to alloc in dsh 2\n", __func__);
return 1;
}
return 0;
}
/*
* event loop side was told about remote peer tx credit window update, serialize
* and put it in the dbuf for the foreign side to consume later
*/
int
lws_ss_serialize_txcr(struct lws_dsh *dsh, int txcr)
{
uint8_t pre[7];
lwsl_info("%s: %d\n", __func__, txcr);
pre[0] = LWSSS_SER_RXPRE_TXCR_UPDATE;
pre[1] = 0;
pre[2] = 4;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
lws_ser_wu32be(&pre[3], (uint32_t)txcr);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (lws_dsh_alloc_tail(dsh, KIND_SS_TO_P, pre, 7, NULL, 0)) {
lwsl_err("%s: unable to alloc in dsh 2\n", __func__);
return 1;
}
return 0;
}
/*
* event loop side is consuming serialized data from the client via dsh, parse
* it using a bytewise parser for the serialization header(s)...
* it's possibly coalesced
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
*
* client: pss is pointing to the start of userdata. We can use
* pss_to_sspc_h(_pss, _ssi) to convert that to a pointer to the sspc
* handle
*
* proxy: pss is pointing to &conn->ss, a pointer to the ss handle
sspc: proxy: extend DESTROY_ME
2020-08-16 05:27:40 +01:00
*
* Returns one of
*
* LWSSSSRET_OK
* LWSSSSRET_DISCONNECT_ME
* LWSSSSRET_DESTROY_ME
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
*/
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
/* convert userdata ptr _pss to handle pointer, allowing for any layout in
* userdata */
#define client_pss_to_sspc_h(_pss, _ssi) (*((lws_sspc_handle_t **) \
((uint8_t *)_pss) + _ssi->handle_offset))
/* client pss to sspc userdata */
#define client_pss_to_userdata(_pss) ((void *)_pss)
/* proxy convert pss to ss handle */
#define proxy_pss_to_ss_h(_pss) (*_pss)
/* convert userdata ptr _pss to handle pointer, allowing for any layout in
* userdata */
#define client_pss_to_sspc_h(_pss, _ssi) (*((lws_sspc_handle_t **) \
((uint8_t *)_pss) + _ssi->handle_offset))
/* client pss to sspc userdata */
#define client_pss_to_userdata(_pss) ((void *)_pss)
/* proxy convert pss to ss handle */
#define proxy_pss_to_ss_h(_pss) (*_pss)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
int
lws_ss_deserialize_parse(struct lws_ss_serialization_parser *par,
struct lws_context *context,
struct lws_dsh *dsh, const uint8_t *cp, size_t len,
lws_ss_conn_states_t *state, void *parconn,
lws_ss_handle_t **pss, lws_ss_info_t *ssi, char client)
{
lws_ss_metadata_t *pm;
lws_sspc_handle_t *h;
uint8_t pre[23];
uint32_t flags;
ss: proxy_buflen in policy sets proxy max dsh alloc per streamtype
2020-12-28 10:06:16 +00:00
lws_usec_t us;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
uint8_t *p;
int n;
while (len--) {
switch (par->ps) {
case RPAR_TYPE:
par->type = *cp++;
par->ps++;
break;
case RPAR_LEN_MSB: /* this is remaining frame length */
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->rem = (uint16_t)((*cp++) << 8);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps++;
break;
case RPAR_LEN_LSB:
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->rem |= (uint16_t)*cp++;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
switch (par->type) {
/* event loop side */
case LWSSS_SER_TXPRE_TX_PAYLOAD:
if (client)
goto hangup;
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
if (*state != LPCSPROX_OPERATIONAL)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps = RPAR_FLAG_B3;
break;
case LWSSS_SER_TXPRE_DESTROYING:
if (client)
goto hangup;
par->ps = RPAR_TYPE;
lwsl_notice("%s: DESTROYING\n", __func__);
goto hangup;
case LWSSS_SER_TXPRE_ONWARD_CONNECT:
if (client)
goto hangup;
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
if (*state != LPCSPROX_OPERATIONAL)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps = RPAR_TYPE;
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
lwsl_notice("%s: LWSSS_SER_TXPRE_ONWARD_CONNECT\n", __func__);
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
if (proxy_pss_to_ss_h(pss) &&
!proxy_pss_to_ss_h(pss)->wsi)
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
/*
* We're going to try to do the onward
* connect, but that could end in any
* of the ways like DESTROY_ME etc
*/
switch (_lws_ss_client_connect(
sspc: cleanup bridged wsi
2020-12-27 19:34:30 +00:00
proxy_pss_to_ss_h(pss), 0, parconn)) {
ss: client_connect and request_tx also return dispositions Since client_connect and request_tx can be called from code that expects the ss handle to be in scope, these calls can't deal with destroying the ss handle and must pass the lws_ss_state_return_t disposition back to the caller to handle.
2020-12-22 15:56:41 +00:00
case LWSSSSRET_OK:
/* well, connect is ongoing */
break;
case LWSSSSRET_TX_DONT_SEND:
/* it has failed already... */
break;
case LWSSSSRET_DISCONNECT_ME:
// if (lws_ss_backoff(h))
// /* has been destroyed */
// return 1;
break;
case LWSSSSRET_DESTROY_ME:
goto hangup;
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
case LWSSS_SER_TXPRE_STREAMTYPE:
if (client)
goto hangup;
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
if (*state != LPCSPROX_WAIT_INITIAL_TX)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
sspc: ssv1: add serialization protocol versioning Let's add a byte on the first message that sspc clients send, indicating the version of the serialization protocol that the client was built with. Start the version at 1, we will add some more changes in other patches and call v1 (now it has the versioning baked in) the first real supported serialization version, this patch must be applied with the next patches to actually represent v1 protocol changes. This doesn't require user setting, the client is told what version it supports in LWS_SSS_CLIENT_PROTOCOL_VERSION. The proxy knows what version(s) it can support and loudly hangs up on the client if it doesn't understand its protocol version.
2020-12-31 14:07:13 +00:00
if (par->rem < 1 + 4 + 1)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
sspc: ssv1: add serialization protocol versioning Let's add a byte on the first message that sspc clients send, indicating the version of the serialization protocol that the client was built with. Start the version at 1, we will add some more changes in other patches and call v1 (now it has the versioning baked in) the first real supported serialization version, this patch must be applied with the next patches to actually represent v1 protocol changes. This doesn't require user setting, the client is told what version it supports in LWS_SSS_CLIENT_PROTOCOL_VERSION. The proxy knows what version(s) it can support and loudly hangs up on the client if it doesn't understand its protocol version.
2020-12-31 14:07:13 +00:00
par->ps = RPAR_INIT_PROVERS;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
case LWSSS_SER_TXPRE_METADATA:
if (client)
goto hangup;
if (par->rem < 3)
goto hangup;
par->ctr = 0;
par->ps = RPAR_METADATA_NAMELEN;
break;
case LWSSS_SER_TXPRE_TXCR_UPDATE:
par->ps = RPAR_TXCR0;
par->ctr = 0;
break;
ss: add timeout
2020-06-30 16:42:37 +01:00
case LWSSS_SER_TXPRE_TIMEOUT_UPDATE:
if (client)
goto hangup;
if (par->rem != 4)
goto hangup;
par->ps = RPAR_TIMEOUT0;
par->ctr = 0;
break;
sspc: add request_tx length variant Add in the missing request_tx length variant, serialization and proxy handling for it
2020-08-03 15:33:09 +01:00
case LWSSS_SER_TXPRE_PAYLOAD_LENGTH_HINT:
if (client)
goto hangup;
if (par->rem != 4)
goto hangup;
par->ps = RPAR_PAYLEN0;
par->ctr = 0;
break;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/* client side */
case LWSSS_SER_RXPRE_RX_PAYLOAD:
if (!client)
goto hangup;
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
if (*state != LPCSCLI_OPERATIONAL &&
*state != LPCSCLI_LOCAL_CONNECTED)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
ss: add timeout
2020-06-30 16:42:37 +01:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->rideshare[0] = '\0';
par->ps = RPAR_FLAG_B3;
break;
case LWSSS_SER_RXPRE_CREATE_RESULT:
if (!client)
goto hangup;
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
if (*state != LPCSCLI_WAITING_CREATE_RESULT)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
ss: add timeout
2020-06-30 16:42:37 +01:00
if (par->rem < 1)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
ss: add timeout
2020-06-30 16:42:37 +01:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps = RPAR_RESULT_CREATION;
break;
case LWSSS_SER_RXPRE_CONNSTATE:
if (!client)
goto hangup;
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
if (*state != LPCSCLI_LOCAL_CONNECTED &&
*state != LPCSCLI_OPERATIONAL)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
ss: add timeout
2020-06-30 16:42:37 +01:00
sspc: extend RXPRE_CONNSTATE to handle 8 or 32-bit states Currently only the low 8 bits of an SS state are proxied in a total packet length of 8 octets. Keep that format and behaviour since all the defined states fit in 8 bits, but also allow for 32-bit states using a packet length of 11 octets with the same command. This lets us proxy user states (from http mapping) which start at a user base of 1000.
2020-09-20 07:03:23 +01:00
if (par->rem < 5 || par->rem > 8)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
ss: add timeout
2020-06-30 16:42:37 +01:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps = RPAR_STATEINDEX;
sspc: extend RXPRE_CONNSTATE to handle 8 or 32-bit states Currently only the low 8 bits of an SS state are proxied in a total packet length of 8 octets. Keep that format and behaviour since all the defined states fit in 8 bits, but also allow for 32-bit states using a packet length of 11 octets with the same command. This lets us proxy user states (from http mapping) which start at a user base of 1000.
2020-09-20 07:03:23 +01:00
par->ctr = 0;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
case LWSSS_SER_RXPRE_METADATA:
if (!client)
goto hangup;
if (par->rem < 3)
goto hangup;
par->ctr = 0;
par->ps = RPAR_METADATA_NAMELEN;
break;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
case LWSSS_SER_RXPRE_TXCR_UPDATE:
par->ctr = 0;
par->ps = RPAR_RX_TXCR_UPDATE;
break;
default:
lwsl_notice("%s: bad type 0x%x\n", __func__,
par->type);
goto hangup;
}
break;
case RPAR_FLAG_B3:
case RPAR_FLAG_B2:
case RPAR_FLAG_B1:
case RPAR_FLAG_B0:
par->flags <<= 8;
par->flags |= *cp++;
par->ps++;
if (!par->rem--)
goto hangup;
break;
case RPAR_LATA3:
case RPAR_LATA2:
case RPAR_LATA1:
case RPAR_LATA0:
par->usd_phandling <<= 8;
par->usd_phandling |= *cp++;
par->ps++;
if (!par->rem--)
goto hangup;
break;
case RPAR_LATB7:
case RPAR_LATB6:
case RPAR_LATB5:
case RPAR_LATB4:
case RPAR_LATB3:
case RPAR_LATB2:
case RPAR_LATB1:
case RPAR_LATB0:
par->ust_pwait <<= 8;
par->ust_pwait |= *cp++;
par->ps++;
par->frag1 = 1;
if (!par->rem--)
goto hangup;
if (par->ps == RPAR_RIDESHARE_LEN &&
!(par->flags & LWSSS_FLAG_RIDESHARE))
par->ps = RPAR_PAYLOAD;
if (par->rem)
break;
/* fallthru - handle 0-length payload */
if (!(par->flags & LWSSS_FLAG_RIDESHARE))
goto payload_ff;
goto hangup;
/*
* Inbound rideshare info is provided on the RX packet
* itself
*/
case RPAR_RIDESHARE_LEN:
par->slen = *cp++;
par->ctr = 0;
par->ps++;
if (par->rem-- < par->slen)
goto hangup;
break;
case RPAR_RIDESHARE:
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->rideshare[par->ctr++] = (char)*cp++;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (!par->rem--)
goto hangup;
if (par->ctr != par->slen)
break;
par->ps = RPAR_PAYLOAD;
if (par->rem)
break;
/* fallthru - handle 0-length payload */
case RPAR_PAYLOAD:
payload_ff:
n = (int)len + 1;
if (n > par->rem)
n = par->rem;
sspc: fix intree build for sspc examples and increase post example body Correct a comment about payload layout and add detailed comments about dsh handling at proxy. Increase the post size so it shows up fragmentation issues at the proxy.
2020-08-13 12:31:35 +01:00
/*
* We get called with a serialized buffer of a size
* chosen by the client. We can only create dsh entries
* with up to 1380 payload, to guarantee we can emit
* them on the onward connection atomically.
*
* If 1380 isn't enough to cover what was handed to us,
* we'll stop at 1380 and go around again and create
* more dsh entries for the rest, with their own
* headers.
*/
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (n > 1380)
n = 1380;
sspc: fix intree build for sspc examples and increase post example body Correct a comment about payload layout and add detailed comments about dsh handling at proxy. Increase the post size so it shows up fragmentation issues at the proxy.
2020-08-13 12:31:35 +01:00
/*
* Since we're in the business of fragmenting client
* serialized payloads at 1380, we have to deal with
* refragmenting the SOM / EOM flags that covered the
* whole client serialized packet, so they apply to
* each dsh entry we split it into correctly
*/
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
flags = par->flags & LWSSS_FLAG_RELATED_START;
if (par->frag1)
sspc: fix intree build for sspc examples and increase post example body Correct a comment about payload layout and add detailed comments about dsh handling at proxy. Increase the post size so it shows up fragmentation issues at the proxy.
2020-08-13 12:31:35 +01:00
/*
* Only set the first time we came to this
* state after deserialization of the header
*/
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
flags |= par->flags &
(LWSSS_FLAG_SOM | LWSSS_FLAG_POLL);
if (par->rem == n)
sspc: fix intree build for sspc examples and increase post example body Correct a comment about payload layout and add detailed comments about dsh handling at proxy. Increase the post size so it shows up fragmentation issues at the proxy.
2020-08-13 12:31:35 +01:00
/*
* We are going to complete the advertised
* payload length from the client on this dsh,
* so give him the EOM type flags if any
*/
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
flags |= par->flags & (LWSSS_FLAG_EOM |
LWSSS_FLAG_RELATED_END);
par->frag1 = 0;
us = lws_now_usecs();
if (!client) {
/*
* Proxy - we received some serialized tx from
* the client.
*
* The header for buffering private to the
sspc: fix intree build for sspc examples and increase post example body Correct a comment about payload layout and add detailed comments about dsh handling at proxy. Increase the post size so it shows up fragmentation issues at the proxy.
2020-08-13 12:31:35 +01:00
* proxy is 23 bytes vs 19, so we can hold the
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
* current time when it was buffered
sspc: fix intree build for sspc examples and increase post example body Correct a comment about payload layout and add detailed comments about dsh handling at proxy. Increase the post size so it shows up fragmentation issues at the proxy.
2020-08-13 12:31:35 +01:00
* additionally
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
*/
sspc: client: audit all deserialize *pss references and confirmed checked for NULL
2020-08-17 06:57:30 +01:00
lwsl_info("%s: C2P RX: len %d\n", __func__,
(int)n);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
p = pre;
pre[0] = LWSSS_SER_TXPRE_TX_PAYLOAD;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
lws_ser_wu16be(&p[1], (uint16_t)((unsigned int)n + 23 - 3));
sspc-proxy-fragmented-dsh-must-use-fragmented-flags We compute the refragmented flags when cutting up large client serialized payload blocks. But we had a bug where we didn't actually apply it and applied the original client flags on the fragments. That causes a crisis because EOM is used to mark end of post body and complete the transaction, that is then happening on the first fragment. This one-liner corrects it to use the computed, refragmented flags on the dsh fragments and eliminate the problem.
2020-08-13 15:55:00 +01:00
lws_ser_wu32be(&p[3], flags);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/* us held at client before written */
lws_ser_wu32be(&p[7], par->usd_phandling);
/* us taken for transit to proxy */
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
lws_ser_wu32be(&p[11], (uint32_t)(us - (lws_usec_t)par->ust_pwait));
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/* time used later to find proxy hold time */
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
lws_ser_wu64be(&p[15], (uint64_t)us);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (lws_dsh_alloc_tail(dsh, KIND_C_TO_P, pre,
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
23, cp, (unsigned int)n)) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lwsl_err("%s: unable to alloc in dsh 3\n",
__func__);
sspc: proxy: extend DESTROY_ME
2020-08-16 05:27:40 +01:00
return LWSSSSRET_DISCONNECT_ME;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
if (proxy_pss_to_ss_h(pss))
lws_ss_request_tx(
proxy_pss_to_ss_h(pss));
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
} else {
/*
* Client receives some RX from proxy
*
* Pass whatever payload we have to ss user
*/
sspc: client: audit all deserialize *pss references and confirmed checked for NULL
2020-08-17 06:57:30 +01:00
lwsl_info("%s: P2C RX: len %d\n", __func__,
(int)n);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
sspc: client: audit all deserialize *pss references and confirmed checked for NULL
2020-08-17 06:57:30 +01:00
h = lws_container_of(par, lws_sspc_handle_t,
parser);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->txc.peer_tx_cr_est -= n;
sspc: double free + rx ret not checked Change-Id: I81b67cbb28591a20842fc7d6e09b78375845aae4
2020-11-25 18:25:58 +08:00
if (client_pss_to_sspc_h(pss, ssi)) {
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
/* we still have an sspc handle */
sspc: double free + rx ret not checked Change-Id: I81b67cbb28591a20842fc7d6e09b78375845aae4
2020-11-25 18:25:58 +08:00
int ret = ssi->rx(client_pss_to_userdata(pss),
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
(uint8_t *)cp, (unsigned int)n, (int)flags);
sspc: double free + rx ret not checked Change-Id: I81b67cbb28591a20842fc7d6e09b78375845aae4
2020-11-25 18:25:58 +08:00
switch (ret) {
case LWSSSSRET_OK:
break;
case LWSSSSRET_DISCONNECT_ME:
goto hangup;
case LWSSSSRET_DESTROY_ME:
return LWSSSSRET_DESTROY_ME;
}
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
#if defined(LWS_WITH_DETAILED_LATENCY)
if (lws_det_lat_active(context)) {
lws_detlat_t d;
d.type = LDLT_READ;
d.acc_size = d.req_size = n;
d.latencies[LAT_DUR_USERCB] =
lws_now_usecs() - us;
d.latencies[LAT_DUR_PROXY_CLIENT_REQ_TO_WRITE] =
par->usd_phandling;
d.latencies[LAT_DUR_PROXY_CLIENT_WRITE_TO_PROXY_RX] =
us - par->ust_pwait;
lws_det_lat_cb(context, &d);
}
#endif
}
if (n) {
cp += n;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->rem = (uint16_t)(par->rem - (uint16_t)(unsigned int)n);
len = (len + 1) - (unsigned int)n;
sspc: fix intree build for sspc examples and increase post example body Correct a comment about payload layout and add detailed comments about dsh handling at proxy. Increase the post size so it shows up fragmentation issues at the proxy.
2020-08-13 12:31:35 +01:00
/*
* if we didn't consume it all, we'll come
* around again and produce more dsh entries up
* to 1380 each until it is gone
*/
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
if (!par->rem)
par->ps = RPAR_TYPE;
break;
case RPAR_RX_TXCR_UPDATE:
if (!--par->rem && par->ctr != 3)
goto hangup;
par->temp32 = (par->temp32 << 8) | *cp++;
if (++par->ctr < 4)
break;
/*
* Proxy is telling us remote endpoint is allowing us
* par->temp32 more bytes tx credit to write to it
*/
h = lws_container_of(par, lws_sspc_handle_t, parser);
h->txc.tx_cr += par->temp32;
lwsl_info("%s: RX_PEER_TXCR: %d\n", __func__, par->temp32);
lws_sspc_request_tx(h); /* in case something waiting */
par->ctr = 0;
par->ps = RPAR_TYPE;
break;
sspc: ssv1: add serialization protocol versioning Let's add a byte on the first message that sspc clients send, indicating the version of the serialization protocol that the client was built with. Start the version at 1, we will add some more changes in other patches and call v1 (now it has the versioning baked in) the first real supported serialization version, this patch must be applied with the next patches to actually represent v1 protocol changes. This doesn't require user setting, the client is told what version it supports in LWS_SSS_CLIENT_PROTOCOL_VERSION. The proxy knows what version(s) it can support and loudly hangs up on the client if it doesn't understand its protocol version.
2020-12-31 14:07:13 +00:00
case RPAR_INIT_PROVERS:
/* Protocol version byte for this connection */
par->protocol_version = *cp++;
/*
* So we have to know what versions of the serialization
* protocol we can support at the proxy side, and
* reject anythng we don't know how to deal with
* noisily in the logs.
*/
if (par->protocol_version != 1) {
lwsl_err("%s: Rejecting client with "
"unsupported SSv%d protocol\n",
__func__, par->protocol_version);
goto hangup;
}
if (!--par->rem)
goto hangup;
par->ctr = 0;
sspc: ssv1: pass client PID into proxy for tagging Let's have the client processes pass in their pid, and tag the related proxy SS with that pid, so we can see on whose behalf the proxy is acting.
2020-12-31 14:56:43 +00:00
par->ps = RPAR_INIT_PID;
break;
case RPAR_INIT_PID:
if (!--par->rem)
goto hangup;
par->temp32 = (par->temp32 << 8) | *cp++;
if (++par->ctr < 4)
break;
par->client_pid = (uint32_t)par->temp32;
par->ctr = 0;
sspc: ssv1: add serialization protocol versioning Let's add a byte on the first message that sspc clients send, indicating the version of the serialization protocol that the client was built with. Start the version at 1, we will add some more changes in other patches and call v1 (now it has the versioning baked in) the first real supported serialization version, this patch must be applied with the next patches to actually represent v1 protocol changes. This doesn't require user setting, the client is told what version it supports in LWS_SSS_CLIENT_PROTOCOL_VERSION. The proxy knows what version(s) it can support and loudly hangs up on the client if it doesn't understand its protocol version.
2020-12-31 14:07:13 +00:00
par->ps = RPAR_INITTXC0;
break;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
case RPAR_INITTXC0:
if (!--par->rem)
goto hangup;
par->temp32 = (par->temp32 << 8) | *cp++;
if (++par->ctr < 4)
break;
par->txcr_out = par->temp32;
par->ctr = 0;
par->ps = RPAR_STREAMTYPE;
break;
/*
* These are the client adjusting our / the remote peer ability
* to send back to him. He's sending a signed u32 BE
*/
case RPAR_TXCR0:
par->temp32 = (par->temp32 << 8) | *cp++;
if (++par->ctr < 4) {
if (!--par->rem)
goto hangup;
break;
}
if (--par->rem)
goto hangup;
if (!client) {
/*
* We're the proxy, being told by the client
* that it wants to allow more tx from the peer
* on the onward connection towards it.
*/
#if defined(LWS_ROLE_H2) || defined(LWS_ROLE_MQTT)
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
if (proxy_pss_to_ss_h(pss) &&
proxy_pss_to_ss_h(pss)->wsi) {
lws_wsi_tx_credit(
proxy_pss_to_ss_h(pss)->wsi,
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
LWSTXCR_PEER_TO_US,
par->temp32);
lwsl_notice("%s: proxy RX_PEER_TXCR: +%d (est %d)\n",
__func__, par->temp32,
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
proxy_pss_to_ss_h(pss)->wsi->
txc.peer_tx_cr_est);
lws_ss_request_tx(proxy_pss_to_ss_h(pss));
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
} else
#endif
lwsl_info("%s: dropping TXCR\n", __func__);
} else {
/*
* We're the client, being told by the proxy
* about tx credit being given to us from the
* remote peer, allowing the client to write to
* it.
*/
sspc: client: audit all deserialize *pss references and confirmed checked for NULL
2020-08-17 06:57:30 +01:00
h = lws_container_of(par, lws_sspc_handle_t,
parser);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h->txc.tx_cr += par->temp32;
lwsl_info("%s: client RX_PEER_TXCR: %d\n",
__func__, par->temp32);
lws_sspc_request_tx(h); /* in case something waiting */
}
par->ps = RPAR_TYPE;
break;
ss: add timeout
2020-06-30 16:42:37 +01:00
case RPAR_TIMEOUT0:
par->temp32 = (par->temp32 << 8) | *cp++;
if (++par->ctr < 4) {
if (!--par->rem)
goto hangup;
break;
}
if (--par->rem)
goto hangup;
sspc: ss timeout check is onward still alive before setting
2020-08-12 19:25:34 +01:00
/*
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
* Proxy...
*
sspc: ss timeout check is onward still alive before setting
2020-08-12 19:25:34 +01:00
* *pss may have gone away asynchronously inbetweentimes
*/
ss: add timeout
2020-06-30 16:42:37 +01:00
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
if (proxy_pss_to_ss_h(pss)) {
ss: add timeout
2020-06-30 16:42:37 +01:00
sspc: ss timeout check is onward still alive before setting
2020-08-12 19:25:34 +01:00
if ((unsigned int)par->temp32 == 0xffffffff) {
lwsl_notice("%s: cancel ss timeout\n",
__func__);
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
lws_ss_cancel_timeout(
proxy_pss_to_ss_h(pss));
sspc: ss timeout check is onward still alive before setting
2020-08-12 19:25:34 +01:00
} else {
if (!par->temp32)
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->temp32 = (int)
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
proxy_pss_to_ss_h(pss)->
policy->timeout_ms;
sspc: ss timeout check is onward still alive before setting
2020-08-12 19:25:34 +01:00
lwsl_notice("%s: set ss timeout for +%ums\n",
ss: add timeout
2020-06-30 16:42:37 +01:00
__func__, par->temp32);
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
lws_ss_start_timeout(
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
proxy_pss_to_ss_h(pss), (unsigned int)
sspc: ss timeout check is onward still alive before setting
2020-08-12 19:25:34 +01:00
par->temp32);
}
ss: add timeout
2020-06-30 16:42:37 +01:00
}
par->ps = RPAR_TYPE;
break;
sspc: add request_tx length variant Add in the missing request_tx length variant, serialization and proxy handling for it
2020-08-03 15:33:09 +01:00
case RPAR_PAYLEN0:
/*
* It's the length from lws_ss_request_tx_len() being
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
* passed up to the proxy
sspc: add request_tx length variant Add in the missing request_tx length variant, serialization and proxy handling for it
2020-08-03 15:33:09 +01:00
*/
par->temp32 = (par->temp32 << 8) | *cp++;
if (++par->ctr < 4) {
if (!--par->rem)
goto hangup;
break;
}
if (--par->rem)
goto hangup;
lwsl_notice("%s: set payload len %u\n", __func__,
par->temp32);
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
if (proxy_pss_to_ss_h(pss))
lws_ss_request_tx_len(proxy_pss_to_ss_h(pss),
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
(unsigned long)par->temp32);
sspc: add request_tx length variant Add in the missing request_tx length variant, serialization and proxy handling for it
2020-08-03 15:33:09 +01:00
par->ps = RPAR_TYPE;
break;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
case RPAR_METADATA_NAMELEN:
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/* both client and proxy */
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (!--par->rem)
goto hangup;
par->slen = *cp++;
if (par->slen >= sizeof(par->metadata_name) - 1)
goto hangup;
par->ctr = 0;
par->ps++;
break;
case RPAR_METADATA_NAME:
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/* both client and proxy */
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (!--par->rem)
goto hangup;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->metadata_name[par->ctr++] = (char)*cp++;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (par->ctr != par->slen)
break;
sspc: make sure NUL on metadata name
2020-08-05 06:15:18 +01:00
par->metadata_name[par->ctr] = '\0';
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps = RPAR_METADATA_VALUE;
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
if (client) {
lws_sspc_metadata_t *md;
lws_sspc_handle_t *h =
client_pss_to_sspc_h(pss, ssi);
/*
* client side does not have access to policy
* and any metadata are new to it each time,
* we allocate them, removing any existing with
* the same name first
*/
lws_start_foreach_dll_safe(struct lws_dll2 *, d, d1,
lws_dll2_get_head(
&h->metadata_owner_rx)) {
md = lws_container_of(d,
lws_sspc_metadata_t, list);
if (!strcmp(md->name,
par->metadata_name)) {
lws_dll2_remove(&md->list);
lws_free(md);
}
} lws_end_foreach_dll_safe(d, d1);
/*
* Create the client's rx metadata entry
*/
md = lws_malloc(sizeof(lws_sspc_metadata_t) +
par->rem + 1, "rxmeta");
if (!md) {
lwsl_err("%s: OOM\n", __func__);
goto hangup;
}
memset(md, 0, sizeof(lws_sspc_metadata_t));
lws_strncpy(md->name, par->metadata_name,
sizeof(md->name));
md->len = par->rem;
par->rxmetaval = (uint8_t *)&md[1];
/*
* Overallocate by 1 and put a NUL just beyond
* the official md->len, so value can be easily
* dereferenced safely for NUL-terminated string
* apis that's the most common usage
*/
par->rxmetaval[md->len] = '\0';
lws_dll2_add_tail(&md->list,
&h->metadata_owner_rx);
par->ctr = 0;
break;
}
/* proxy side is receiving it */
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
if (!proxy_pss_to_ss_h(pss))
sspc: client: audit all deserialize *pss references and confirmed checked for NULL
2020-08-17 06:57:30 +01:00
goto hangup;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* This is the policy's metadata list for the given
* name
*/
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
pm = lws_ss_policy_metadata(
proxy_pss_to_ss_h(pss)->policy,
par->metadata_name);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (!pm) {
lwsl_err("%s: metadata %s not in proxy policy\n",
__func__, par->metadata_name);
goto hangup;
}
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
par->ssmd = lws_ss_get_handle_metadata(
proxy_pss_to_ss_h(pss),
par->metadata_name);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (par->ssmd->value_on_lws_heap)
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
lws_free_set_NULL(par->ssmd->value__may_own_heap);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ssmd->value_on_lws_heap = 0;
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->ssmd->value__may_own_heap = lws_malloc((unsigned int)par->rem + 1, "metadata");
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
if (!par->ssmd->value__may_own_heap) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lwsl_err("%s: OOM mdv\n", __func__);
goto hangup;
}
par->ssmd->length = par->rem;
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
((uint8_t *)par->ssmd->value__may_own_heap)[par->rem] = '\0';
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/* mark it as needing cleanup */
par->ssmd->value_on_lws_heap = 1;
par->ctr = 0;
break;
case RPAR_METADATA_VALUE:
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
/* both client and proxy */
if (client) {
*par->rxmetaval++ = *cp++;
} else
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
((uint8_t *)(par->ssmd->value__may_own_heap))[par->ctr++] = *cp++;
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (--par->rem)
break;
/* we think we got all the value */
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
if (client)
lwsl_notice("%s: RX METADATA %s\n", __func__,
par->metadata_name);
else {
lwsl_info("%s: RPAR_METADATA_VALUE for %s (len %d)\n",
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
__func__, par->ssmd->name,
(int)par->ssmd->length);
ss: metadata: rename value to add reminder about heap
2020-10-11 07:29:47 +01:00
lwsl_hexdump_info(par->ssmd->value__may_own_heap, par->ssmd->length);
ss: rx metadata At the moment you can define and set per-stream metadata at the client, which will be string-substituted and if configured in the policy, set in related outgoing protocol specific content like h1 headers. This patch extends the metadata concept to also check incoming protocol- specific content like h1 headers and where it matches the binding in the streamtype's metadata entry, make it available to the client by name, via a new lws_ss_get_metadata() api. Currently warmcat.com has additional headers for server: lwsws (well-known header name) test-custom-header: hello (custom header name) minimal-secure-streams test is updated to try to recover these both in direct and -client (via proxy) versions. The corresponding metadata part of the "mintest" stream policy from warmcat.com is { "srv": "server:" }, { "test": "test-custom-header:" }, If built direct, or at the proxy, the stream has access to the static policy metadata definitions and can store the rx metadata in the stream metadata allocation, with heap-allocated a value. For client side that talks to a proxy, only the proxy knows the policy, and it returns rx metadata inside the serialized link to the client, which stores it on the heap attached to the stream. In addition an optimization for mapping static policy metadata definitions to individual stream handle metadata is changed to match by name.
2020-09-10 06:43:43 +01:00
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps = RPAR_TYPE;
break;
case RPAR_STREAMTYPE:
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
/* only the proxy can get these */
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (client)
goto hangup;
if (par->ctr == sizeof(par->streamtype) - 1)
goto hangup;
sspc: make it clear we can only get RPAR_STREAMTYPE in WAIT_INITIAL_TX state Otherwise Coverity will complain we only set up ssi in WAIT_INITIAL_TX
2020-08-13 06:40:39 +01:00
/*
* We can only expect to get this if we ourselves are
* in the state that we're waiting for it. If it comes
* later it's a protocol error.
*/
if (*state != LPCSPROX_WAIT_INITIAL_TX)
goto hangup;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* We're the proxy, creating an SS on behalf of a
* client
*/
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->streamtype[par->ctr++] = (char)*cp++;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (--par->rem)
break;
par->ps = RPAR_TYPE;
par->streamtype[par->ctr] = '\0';
sspc: ssv1: add serialization protocol versioning Let's add a byte on the first message that sspc clients send, indicating the version of the serialization protocol that the client was built with. Start the version at 1, we will add some more changes in other patches and call v1 (now it has the versioning baked in) the first real supported serialization version, this patch must be applied with the next patches to actually represent v1 protocol changes. This doesn't require user setting, the client is told what version it supports in LWS_SSS_CLIENT_PROTOCOL_VERSION. The proxy knows what version(s) it can support and loudly hangs up on the client if it doesn't understand its protocol version.
2020-12-31 14:07:13 +00:00
lwsl_info("%s: proxy ss '%s', sssv%d, txcr %d\n",
__func__, par->streamtype,
par->protocol_version, par->txcr_out);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
ssi->streamtype = par->streamtype;
lws_smd: system message distribution - Add low level system message distibution framework - Add support for local Secure Streams to participate using _lws_smd streamtype - Add apit test and minimal example - Add SS proxy support for _lws_smd See minimal-secure-streams-smd README.md
2020-06-24 20:15:46 +01:00
if (par->txcr_out) // !!!
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
ssi->manual_initial_tx_credit = par->txcr_out;
lws_smd: system message distribution - Add low level system message distibution framework - Add support for local Secure Streams to participate using _lws_smd streamtype - Add apit test and minimal example - Add SS proxy support for _lws_smd See minimal-secure-streams-smd README.md
2020-06-24 20:15:46 +01:00
/*
* Even for a synthetic SS proxing action like _lws_smd,
* we create an actual SS in the proxy representing the
* connection
*/
ssi->flags |= LWSSSINFLAGS_PROXIED;
sspc: ssv1: add serialization protocol versioning Let's add a byte on the first message that sspc clients send, indicating the version of the serialization protocol that the client was built with. Start the version at 1, we will add some more changes in other patches and call v1 (now it has the versioning baked in) the first real supported serialization version, this patch must be applied with the next patches to actually represent v1 protocol changes. This doesn't require user setting, the client is told what version it supports in LWS_SSS_CLIENT_PROTOCOL_VERSION. The proxy knows what version(s) it can support and loudly hangs up on the client if it doesn't understand its protocol version.
2020-12-31 14:07:13 +00:00
ssi->sss_protocol_version = par->protocol_version;
sspc: ssv1: pass client PID into proxy for tagging Let's have the client processes pass in their pid, and tag the related proxy SS with that pid, so we can see on whose behalf the proxy is acting.
2020-12-31 14:56:43 +00:00
ssi->client_pid = par->client_pid;
lws_smd: system message distribution - Add low level system message distibution framework - Add support for local Secure Streams to participate using _lws_smd streamtype - Add apit test and minimal example - Add SS proxy support for _lws_smd See minimal-secure-streams-smd README.md
2020-06-24 20:15:46 +01:00
if (lws_ss_create(context, 0, ssi, parconn, pss,
NULL, NULL)) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* We're unable to create the onward secure
* stream he asked for... schedule a chance to
* inform him
*/
lwsl_err("%s: create '%s' fail\n",
__func__, par->streamtype);
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
*state = LPCSPROX_REPORTING_FAIL;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
} else {
lwsl_debug("%s: create '%s' OK\n",
__func__, par->streamtype);
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
*state = LPCSPROX_REPORTING_OK;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
if (*pss) {
(*pss)->being_serialized = 1;
lws_smd: system message distribution - Add low level system message distibution framework - Add support for local Secure Streams to participate using _lws_smd streamtype - Add apit test and minimal example - Add SS proxy support for _lws_smd See minimal-secure-streams-smd README.md
2020-06-24 20:15:46 +01:00
#if defined(LWS_WITH_SYS_SMD)
if ((*pss)->policy != &pol_smd)
/*
* In SMD case we overloaded the
* initial credit to be the class mask
*/
#endif
{
lwsl_info("%s: Created SS initial credit %d\n",
__func__, par->txcr_out);
(*pss)->info.manual_initial_tx_credit = par->txcr_out;
}
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
/* parent needs to schedule write on client conn */
break;
/* clientside states */
case RPAR_RESULT_CREATION:
if (*cp++) {
lwsl_err("%s: stream creation failed\n",
__func__);
goto hangup;
}
sspc: ssv1: return policy about client dsh allocation Let's allow the proxy to pass back what the policy says about the size of dsh buffer the client side of this streamtype should have. Defer clientsize dsh generation until we got the info back from the proxy in the response to the initial packet. If it's zero / unset in the policy, just go with 32KB.
2020-12-31 15:08:48 +00:00
if (--par->rem < 4)
goto hangup;
par->ps = RPAR_RESULT_CREATION_DSH;
par->ctr = 0;
break;
case RPAR_RESULT_CREATION_DSH:
par->temp32 = (par->temp32 << 8) | (*cp++);
if (!par->rem--)
goto hangup;
if (++par->ctr < 4)
break;
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
/*
sspc: ssv1: return policy about client dsh allocation Let's allow the proxy to pass back what the policy says about the size of dsh buffer the client side of this streamtype should have. Defer clientsize dsh generation until we got the info back from the proxy in the response to the initial packet. If it's zero / unset in the policy, just go with 32KB.
2020-12-31 15:08:48 +00:00
* Client (par->temp32 == dsh alloc)
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
*/
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lws_ss_serialize_state_transition(state,
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
LPCSCLI_LOCAL_CONNECTED);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
h = lws_container_of(par, lws_sspc_handle_t, parser);
sspc: clear proxy conn timeout on ack Remember to clear the 3s timeout set at sspc -> client connection, covering the case that the SS serialization initial handshake doesn't take place
2021-01-03 07:44:33 +00:00
lws_set_timeout(h->cwsi, NO_PENDING_TIMEOUT, 0);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
sspc: ssv1: return policy about client dsh allocation Let's allow the proxy to pass back what the policy says about the size of dsh buffer the client side of this streamtype should have. Defer clientsize dsh generation until we got the info back from the proxy in the response to the initial packet. If it's zero / unset in the policy, just go with 32KB.
2020-12-31 15:08:48 +00:00
if (h->dsh)
goto hangup;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
/*
* This is telling us that the streamtype could be (and
* was) created at the proxy. It's not telling us that
* the onward peer connection could be connected.
*
* We'll get a proxied state() coming later that informs
* us about the situation with that.
sspc: client: call CREATING on linkup to proxy Before this we simply proxy the CREATING state from the proxy version of the stream to the client version of the stream. However this can result in disordering of onward connection attempt request happening before the client has called back its CREATING (*state()), meaning that any metadata set in the state handler is missed for the onward connection. This patch suppresses the CREATING forwarded from the proxy and instead does its own local CREATING state callback at the time the proxy indicates that the remote stream creation (ie, with the requested policy streamtype) succeeded. This then guarantees that the client has seen CREATING, and had a chance to set metadata there, before the onward connection request goes out. Since metadata has higher priority at the writeable than the onward connection request it also means any metadata set in client CREATING gets sync'd to the proxy before the onward connection.
2020-09-04 12:59:34 +01:00
*
* However at this point, we should choose to inform
* the client that his stream was created... we will
* later get a proxied CREATING state from the peer
* but we should do it now and suppress the later one.
*
* The reason is he may set metadata in CREATING, and
* we will try to do writeables to sync the stream to
docs: switch to use main
2020-10-11 07:43:46 +01:00
* proxy and ultimately bring up the onward connection
sspc: client: call CREATING on linkup to proxy Before this we simply proxy the CREATING state from the proxy version of the stream to the client version of the stream. However this can result in disordering of onward connection attempt request happening before the client has called back its CREATING (*state()), meaning that any metadata set in the state handler is missed for the onward connection. This patch suppresses the CREATING forwarded from the proxy and instead does its own local CREATING state callback at the time the proxy indicates that the remote stream creation (ie, with the requested policy streamtype) succeeded. This then guarantees that the client has seen CREATING, and had a chance to set metadata there, before the onward connection request goes out. Since metadata has higher priority at the writeable than the onward connection request it also means any metadata set in client CREATING gets sync'd to the proxy before the onward connection.
2020-09-04 12:59:34 +01:00
* now we are in LOCAL_CONNECTED. We need to do the
* CREATING now so we'll know the metadata to sync.
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
*/
sspc: client: call CREATING on linkup to proxy Before this we simply proxy the CREATING state from the proxy version of the stream to the client version of the stream. However this can result in disordering of onward connection attempt request happening before the client has called back its CREATING (*state()), meaning that any metadata set in the state handler is missed for the onward connection. This patch suppresses the CREATING forwarded from the proxy and instead does its own local CREATING state callback at the time the proxy indicates that the remote stream creation (ie, with the requested policy streamtype) succeeded. This then guarantees that the client has seen CREATING, and had a chance to set metadata there, before the onward connection request goes out. Since metadata has higher priority at the writeable than the onward connection request it also means any metadata set in client CREATING gets sync'd to the proxy before the onward connection.
2020-09-04 12:59:34 +01:00
h->creating_cb_done = 1;
ss: enforce only valid state transitions The various stream transitions for direct ss, SSPC, smd, and different protocols are all handled in different code, let's stop hoping for the best and add a state transition validation function that is used everywhere we pass a state change to a user callback, and knows what is valid for the user state() callback to see next, given the last state it was shown. Let's assert if lws manages to violate that so we can find where the problem is and provide a stricter guarantee about what user state handler will see, no matter if ss or sspc or other cases. To facilitate that, move the states to start from 1, where 0 indicates the state unset.
2021-01-02 10:49:43 +00:00
if (lws_ss_check_next_state(&h->prev_ss_state, LWSSSCS_CREATING))
return LWSSSSRET_DESTROY_ME;
h->prev_ss_state = (uint8_t)LWSSSCS_CREATING;
sspc: allow NULL rx and state in ssi Sometimes there's no need for .tx or even .state... make sure we are OK with that in the ssi by checking before sspc callthrus
2021-01-01 14:57:07 +00:00
if (ssi->state) {
n = ssi->state(client_pss_to_userdata(pss),
NULL, LWSSSCS_CREATING, 0);
switch (n) {
case LWSSSSRET_OK:
break;
case LWSSSSRET_DISCONNECT_ME:
goto hangup;
case LWSSSSRET_DESTROY_ME:
return LWSSSSRET_DESTROY_ME;
}
sspc: client: call CREATING on linkup to proxy Before this we simply proxy the CREATING state from the proxy version of the stream to the client version of the stream. However this can result in disordering of onward connection attempt request happening before the client has called back its CREATING (*state()), meaning that any metadata set in the state handler is missed for the onward connection. This patch suppresses the CREATING forwarded from the proxy and instead does its own local CREATING state callback at the time the proxy indicates that the remote stream creation (ie, with the requested policy streamtype) succeeded. This then guarantees that the client has seen CREATING, and had a chance to set metadata there, before the onward connection request goes out. Since metadata has higher priority at the writeable than the onward connection request it also means any metadata set in client CREATING gets sync'd to the proxy before the onward connection.
2020-09-04 12:59:34 +01:00
}
sspc: ssv1: return policy about client dsh allocation Let's allow the proxy to pass back what the policy says about the size of dsh buffer the client side of this streamtype should have. Defer clientsize dsh generation until we got the info back from the proxy in the response to the initial packet. If it's zero / unset in the policy, just go with 32KB.
2020-12-31 15:08:48 +00:00
h->dsh = lws_dsh_create(NULL, (size_t)(par->temp32 ?
par->temp32 : 32768), 1);
if (!h->dsh)
goto hangup;
sspc: client: call CREATING on linkup to proxy Before this we simply proxy the CREATING state from the proxy version of the stream to the client version of the stream. However this can result in disordering of onward connection attempt request happening before the client has called back its CREATING (*state()), meaning that any metadata set in the state handler is missed for the onward connection. This patch suppresses the CREATING forwarded from the proxy and instead does its own local CREATING state callback at the time the proxy indicates that the remote stream creation (ie, with the requested policy streamtype) succeeded. This then guarantees that the client has seen CREATING, and had a chance to set metadata there, before the onward connection request goes out. Since metadata has higher priority at the writeable than the onward connection request it also means any metadata set in client CREATING gets sync'd to the proxy before the onward connection.
2020-09-04 12:59:34 +01:00
if (h->cwsi)
lws_callback_on_writable(h->cwsi);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->rsl_pos = 0;
par->rsl_idx = 0;
sspc: client: call CREATING on linkup to proxy Before this we simply proxy the CREATING state from the proxy version of the stream to the client version of the stream. However this can result in disordering of onward connection attempt request happening before the client has called back its CREATING (*state()), meaning that any metadata set in the state handler is missed for the onward connection. This patch suppresses the CREATING forwarded from the proxy and instead does its own local CREATING state callback at the time the proxy indicates that the remote stream creation (ie, with the requested policy streamtype) succeeded. This then guarantees that the client has seen CREATING, and had a chance to set metadata there, before the onward connection request goes out. Since metadata has higher priority at the writeable than the onward connection request it also means any metadata set in client CREATING gets sync'd to the proxy before the onward connection.
2020-09-04 12:59:34 +01:00
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
memset(&h->rideshare_ofs[0], 0, sizeof(h->rideshare_ofs[0]));
h->rideshare_list[0] = '\0';
h->rsidx = 0;
sspc: ssv1: return policy about client dsh allocation Let's allow the proxy to pass back what the policy says about the size of dsh buffer the client side of this streamtype should have. Defer clientsize dsh generation until we got the info back from the proxy in the response to the initial packet. If it's zero / unset in the policy, just go with 32KB.
2020-12-31 15:08:48 +00:00
/* no rideshare data is OK */
par->ps = RPAR_TYPE;
if (par->rem) {
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps = RPAR_RESULT_CREATION_RIDESHARE;
if (par->rem >= sizeof(h->rideshare_list))
goto hangup;
}
break;
case RPAR_RESULT_CREATION_RIDESHARE:
h = lws_container_of(par, lws_sspc_handle_t, parser);
if (*cp == ',') {
cp++;
h->rideshare_list[par->rsl_pos++] = '\0';
if (par->rsl_idx == LWS_ARRAY_SIZE(h->rideshare_ofs))
goto hangup;
h->rideshare_ofs[++par->rsl_idx] = par->rsl_pos;
} else
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
h->rideshare_list[par->rsl_pos++] = (char)*cp++;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
if (!--par->rem)
par->ps = RPAR_TYPE;
break;
case RPAR_STATEINDEX:
sspc: extend RXPRE_CONNSTATE to handle 8 or 32-bit states Currently only the low 8 bits of an SS state are proxied in a total packet length of 8 octets. Keep that format and behaviour since all the defined states fit in 8 bits, but also allow for 32-bit states using a packet length of 11 octets with the same command. This lets us proxy user states (from http mapping) which start at a user base of 1000.
2020-09-20 07:03:23 +01:00
par->ctr = (par->ctr << 8) | (*cp++);
if (--par->rem == 4)
par->ps = RPAR_ORD3;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
case RPAR_ORD3:
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->flags = (uint32_t)((*cp++) << 24);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps++;
break;
case RPAR_ORD2:
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->flags |= (uint32_t)((*cp++) << 16);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps++;
break;
case RPAR_ORD1:
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->flags |= (uint32_t)((*cp++) << 8);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps++;
break;
case RPAR_ORD0:
type comparisons: fixes This is a huge patch that should be a global NOP. For unix type platforms it enables -Wconversion to issue warnings (-> error) for all automatic casts that seem less than ideal but are normally concealed by the toolchain. This is things like passing an int to a size_t argument. Once enabled, I went through all args on my default build (which build most things) and tried to make the removed default cast explicit. With that approach it neither change nor bloat the code, since it compiles to whatever it was doing before, just with the casts made explicit... in a few cases I changed some length args from int to size_t but largely left the causes alone. From now on, new code that is relying on less than ideal casting will complain and nudge me to improve it by warnings.
2020-12-12 06:21:40 +00:00
par->flags |= (uint32_t)(*cp++);
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
par->ps++;
par->ps = RPAR_TYPE;
/*
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
* Client received a proxied state change
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
*/
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
if (!client_pss_to_sspc_h(pss, ssi))
sspc: client: audit all deserialize *pss references and confirmed checked for NULL
2020-08-17 06:57:30 +01:00
/*
* Since we're being informed we need to have
* a stream to inform. Assume whatever set this
* to NULL has started to close it.
*/
break;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
switch (par->ctr) {
case LWSSSCS_DISCONNECTED:
case LWSSSCS_UNREACHABLE:
case LWSSSCS_AUTH_FAILED:
lws_ss_serialize_state_transition(state,
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
LPCSCLI_LOCAL_CONNECTED);
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
client_pss_to_sspc_h(pss, ssi)->conn_req_state =
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
LWSSSPC_ONW_NONE;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
case LWSSSCS_CONNECTED:
lwsl_info("%s: CONNECTED %s\n", __func__,
ssi->streamtype);
sspc: http POST: synthesize CONNECTED to provoke client body write
2020-07-31 10:44:09 +01:00
if (*state == LPCSCLI_OPERATIONAL)
/*
* Don't allow to see connected more
* than once for one connection
*/
goto swallow;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
lws_ss_serialize_state_transition(state,
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
LPCSCLI_OPERATIONAL);
sspc: client: audit all deserialize *pss references and confirmed checked for NULL
2020-08-17 06:57:30 +01:00
sspc: add translation helpers and comments about pss usage between client and proxy Helpers remove casts and derefs. Add additional pointer arithmetic in client_pss_to_sspc_h() helper to remove dependency on handle_offset being the first thing in the userdata Make the helper names explicit for different proxy and client pss handling, so it should be clearer that client helpers belong in a client section and vice versa.
2020-08-17 14:32:23 +01:00
client_pss_to_sspc_h(pss, ssi)->conn_req_state =
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
LWSSSPC_ONW_CONN;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
ss: add timeout
2020-06-30 16:42:37 +01:00
case LWSSSCS_TIMEOUT:
break;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
default:
break;
}
sspc: extend RXPRE_CONNSTATE to handle 8 or 32-bit states Currently only the low 8 bits of an SS state are proxied in a total packet length of 8 octets. Keep that format and behaviour since all the defined states fit in 8 bits, but also allow for 32-bit states using a packet length of 11 octets with the same command. This lets us proxy user states (from http mapping) which start at a user base of 1000.
2020-09-20 07:03:23 +01:00
if (par->ctr < 0)
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
goto hangup;
#if defined(_DEBUG)
lwsl_info("%s: forwarding proxied state %s\n",
sspc: segregate client and proxy states properly
2020-08-03 15:50:37 +01:00
__func__, lws_ss_state_name(par->ctr));
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
#endif
sspc: proxy: extend DESTROY_ME
2020-08-16 05:27:40 +01:00
sspc: client: call CREATING on linkup to proxy Before this we simply proxy the CREATING state from the proxy version of the stream to the client version of the stream. However this can result in disordering of onward connection attempt request happening before the client has called back its CREATING (*state()), meaning that any metadata set in the state handler is missed for the onward connection. This patch suppresses the CREATING forwarded from the proxy and instead does its own local CREATING state callback at the time the proxy indicates that the remote stream creation (ie, with the requested policy streamtype) succeeded. This then guarantees that the client has seen CREATING, and had a chance to set metadata there, before the onward connection request goes out. Since metadata has higher priority at the writeable than the onward connection request it also means any metadata set in client CREATING gets sync'd to the proxy before the onward connection.
2020-09-04 12:59:34 +01:00
if (par->ctr == LWSSSCS_CREATING) {
sspc: handle not inherited
2020-12-21 23:22:12 +00:00
h = lws_container_of(par, lws_sspc_handle_t, parser);
sspc: client: call CREATING on linkup to proxy Before this we simply proxy the CREATING state from the proxy version of the stream to the client version of the stream. However this can result in disordering of onward connection attempt request happening before the client has called back its CREATING (*state()), meaning that any metadata set in the state handler is missed for the onward connection. This patch suppresses the CREATING forwarded from the proxy and instead does its own local CREATING state callback at the time the proxy indicates that the remote stream creation (ie, with the requested policy streamtype) succeeded. This then guarantees that the client has seen CREATING, and had a chance to set metadata there, before the onward connection request goes out. Since metadata has higher priority at the writeable than the onward connection request it also means any metadata set in client CREATING gets sync'd to the proxy before the onward connection.
2020-09-04 12:59:34 +01:00
if (h->creating_cb_done)
/*
* We have told him he's CREATING when
* we heard we had linked up to the
* proxy, so suppress the remote
* CREATING so that he only sees it once
*/
break;
h->creating_cb_done = 1;
}
ss: enforce balanced CONNECT vs DISCONNECT
2020-12-27 16:05:48 +00:00
if (ssi->state) {
h = lws_container_of(par, lws_sspc_handle_t, parser);
lws_ss_constate_t cs = (lws_ss_constate_t)par->ctr;
if (cs == LWSSSCS_CONNECTED)
h->ss_dangling_connected = 1;
if (cs == LWSSSCS_DISCONNECTED)
h->ss_dangling_connected = 0;
ss: enforce only valid state transitions The various stream transitions for direct ss, SSPC, smd, and different protocols are all handled in different code, let's stop hoping for the best and add a state transition validation function that is used everywhere we pass a state change to a user callback, and knows what is valid for the user state() callback to see next, given the last state it was shown. Let's assert if lws manages to violate that so we can find where the problem is and provide a stricter guarantee about what user state handler will see, no matter if ss or sspc or other cases. To facilitate that, move the states to start from 1, where 0 indicates the state unset.
2021-01-02 10:49:43 +00:00
if (lws_ss_check_next_state(&h->prev_ss_state, cs))
return LWSSSSRET_DESTROY_ME;
if (cs < LWSSSCS_USER_BASE)
h->prev_ss_state = (uint8_t)cs;
ss: enforce balanced CONNECT vs DISCONNECT
2020-12-27 16:05:48 +00:00
n = ssi->state(client_pss_to_userdata(pss),
ss: enforce only valid state transitions The various stream transitions for direct ss, SSPC, smd, and different protocols are all handled in different code, let's stop hoping for the best and add a state transition validation function that is used everywhere we pass a state change to a user callback, and knows what is valid for the user state() callback to see next, given the last state it was shown. Let's assert if lws manages to violate that so we can find where the problem is and provide a stricter guarantee about what user state handler will see, no matter if ss or sspc or other cases. To facilitate that, move the states to start from 1, where 0 indicates the state unset.
2021-01-02 10:49:43 +00:00
NULL, cs, par->flags);
ss: enforce balanced CONNECT vs DISCONNECT
2020-12-27 16:05:48 +00:00
switch (n) {
case LWSSSSRET_OK:
break;
case LWSSSSRET_DISCONNECT_ME:
goto hangup;
case LWSSSSRET_DESTROY_ME:
return LWSSSSRET_DESTROY_ME;
}
sspc: proxy: extend DESTROY_ME
2020-08-16 05:27:40 +01:00
}
sspc: http POST: synthesize CONNECTED to provoke client body write
2020-07-31 10:44:09 +01:00
swallow:
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
break;
default:
goto hangup;
}
}
sspc: proxy: extend DESTROY_ME
2020-08-16 05:27:40 +01:00
return LWSSSSRET_OK;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
hangup:
sspc: proxy: extend DESTROY_ME
2020-08-16 05:27:40 +01:00
return LWSSSSRET_DISCONNECT_ME;
client: secure streams Secure Streams is an optional layer on top of lws that separates policy like endpoint selection and tls cert validation into a device JSON policy document. Code that wants to open a client connection just specifies a streamtype name, and no longer deals with details like the endpoint, the protocol (!) or anything else other than payloads and optionally generic metadata; the JSON policy contains all the details for each streamtype. h1, h2, ws and mqtt client connections are supported. Logical secure streams outlive any particular connection and supports "nailed-up" connectivity regardless of underlying connection stability.
2020-02-29 12:37:24 +00:00
}
Reference in a new issue Copy permalink