libwebsockets icon indicating copy to clipboard operation
libwebsockets copied to clipboard

WebSocket connections fail in libwebsockets 4.4.0, libwebsockets-3.2 is ok.

Open 506124204 opened this issue 1 month ago • 9 comments

// client: 1006 CLOSE_ABNORMAL // test on windows // wireshark no found: HTTP/1.1 101 Switching Protocols

/////////////////////////////////////////// // server #include <libwebsockets.h> #include <string.h> #include <stdio.h>

static int callback_lws_protocol(struct lws* wsi, enum lws_callback_reasons reason, void* user, void* in, size_t len) { switch (reason) { case LWS_CALLBACK_ESTABLISHED: { lwsl_notice("Connection established.\n"); const char* protocol_name = lws_get_protocol(wsi)->name; if (protocol_name && protocol_name[0] != '\0') { lwsl_notice("Client used protocol: %s\n", protocol_name); } else { lwsl_notice("Client did NOT specify a subprotocol (Using default handler).\n"); } } break;

case LWS_CALLBACK_RECEIVE:
{
    if (lws_write(wsi, (unsigned char*)in, len, LWS_WRITE_TEXT) < 0) {
        lwsl_err("Error writing to socket\n");
    }
    lwsl_notice("Received data and echoed back: %.*s\n", (int)len, (char*)in);

}
break;

case LWS_CALLBACK_CLOSED:
    lwsl_notice("Connection closed.\n");
    break;

default:
    break;
}
return 0;

}

static const struct lws_protocols protocols[] = { { "",
callback_lws_protocol, 0, 4096, }, { "example-protocol",
callback_lws_protocol, 0,
4096,
}, { NULL, NULL, 0, 0 } }; // //static const struct lws_protocol_vhost_options pvo_ops = { // NULL, // NULL, // "default", /* pvo name / // "" / ignored / //}; // //static const struct lws_protocol_vhost_options pvo = { // NULL, / "next" pvo linked-list / // &pvo_ops, / "child" pvo linked-list / // "example-protocol", / protocol name we belong to on this vhost / // "" / ignored */ //};

int main(void) { int port = 7681; int opts = 0;// LWS_SERVER_OPTION_HTTP_HEADERS_SECURITY_BEST_PRACTICES_ENFORCE; // LWS_SERVER_OPTION_VLHOSTS

struct lws_context_creation_info info;
memset(&info, 0, sizeof(info));

info.port = port;
info.protocols = protocols;
info.gid = -1;
info.uid = -1;
info.options = opts;
//info.pvo = &pvo; 

lws_set_log_level(LLL_NOTICE | LLL_WARN | LLL_ERR, NULL);

struct lws_context* context = lws_create_context(&info);
if (!context) {
    lwsl_err("lws_create_context failed.\n");
    return 1;
}

lwsl_notice("LWS server started on port %d. Press Ctrl+C to exit.\n", port);

while (1) {
    lws_service(context, 50); 
}

lws_context_destroy(context);
return 0;

}

506124204 avatar Nov 19 '25 02:11 506124204

What happens with main / v4.4-stable?

lws-team avatar Nov 19 '25 04:11 lws-team

What happens with main / v4.4-stable? yes

506124204 avatar Nov 19 '25 06:11 506124204

yes... everything is OK? yes... it's broken the same?

Have you tried any minimal examples directly rather than your own user code?

lws-team avatar Nov 19 '25 06:11 lws-team

libwebsocket: main / v4.4-stable web client: https://livepersoninc.github.io/ws-test-page/

  1. html: let websocket = new WebSocket('ws://localhost:7681', ["example-protocol"]); // This way is okay. Connected and data sending.
  2. html: let websocket = new WebSocket('ws://localhost:7681'); // connect failed!!!!??????? I don't know where the problem lies in the server-side code ?

129 4.607894 127.0.0.1 127.0.0.1 TCP 52 51445 → 7681 [PSH, ACK] Seq=1 Ack=1 Win=10233 Len=8 130 4.607944 127.0.0.1 127.0.0.1 TCP 44 7681 → 51445 [ACK] Seq=1 Ack=9 Win=10233 Len=0 131 4.608039 127.0.0.1 127.0.0.1 TCP 44 51445 → 7681 [FIN, ACK] Seq=9 Ack=1 Win=10233 Len=0 132 4.608060 127.0.0.1 127.0.0.1 TCP 44 7681 → 51445 [ACK] Seq=1 Ack=10 Win=10233 Len=0 133 4.608202 127.0.0.1 127.0.0.1 TCP 48 7681 → 51445 [PSH, ACK] Seq=1 Ack=10 Win=10233 Len=4 134 4.608236 127.0.0.1 127.0.0.1 TCP 44 51445 → 7681 [RST, ACK] Seq=10 Ack=5 Win=0 Len=0 135 4.610508 127.0.0.1 127.0.0.1 TCP 56 51734 → 7681 [SYN] Seq=0 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM 136 4.610576 127.0.0.1 127.0.0.1 TCP 56 7681 → 51734 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=65495 WS=256 SACK_PERM 137 4.610612 127.0.0.1 127.0.0.1 TCP 44 51734 → 7681 [ACK] Seq=1 Ack=1 Win=2619648 Len=0 139 4.624620 127.0.0.1 127.0.0.1 HTTP 197 GET / HTTP/1.1 140 4.624666 127.0.0.1 127.0.0.1 TCP 44 7681 → 51734 [ACK] Seq=1 Ack=154 Win=2619648 Len=0 141 4.624720 127.0.0.1 127.0.0.1 TCP 171 7681 → 51734 [PSH, ACK] Seq=1 Ack=154 Win=2619648 Len=127 142 4.624742 127.0.0.1 127.0.0.1 TCP 44 51734 → 7681 [ACK] Seq=154 Ack=128 Win=2619648 Len=0

506124204 avatar Nov 19 '25 06:11 506124204

.... hm it might feel I should magically know what broke, but in fact this is your code + the library.

I am pretty sure the library works well for serving, since I use it myself.

Have you tried any minimal examples directly rather than your own user code?

This isn't an idle question. Does the problem exist in your code or the library? If you use a minimal example directly that serves, does that work? If not, I will be interested.

If it does work, you broke it when you cut the example down to your current code, I don't really care what you broke. You should start over from the literal minimal example that works (they are licensed CC0 for this purpose) and keep testing it as you chop it down to make sure it still works when you finished chopping it down.

lws-team avatar Nov 19 '25 06:11 lws-team

1.minimal examples ok。 2. One of my brothers had a similar problem in question No. #3487. 3. protocols: let websocket = new WebSocket('ws://localhost:7681');

static const struct lws_protocols protocols[] = { { "", // It worked well in versions 3.2 and 4.3, but the client connection failed in version 4.4. callback_lws_protocol, 0, 4096, },

506124204 avatar Nov 19 '25 07:11 506124204

If that's your problem, the example code I gave there to bind your protocol to be the "default" one selected when no specfific one is given should also solve it.

lws-team avatar Nov 19 '25 08:11 lws-team

Thank you, lws-team!

Why was this functional behavior changed in version 4.4? The upper-level caller has to re-adapt. Is there a fix plan for the new version?

506124204 avatar Nov 19 '25 08:11 506124204

No. As I explained in 3487, the protocol should always have a name. If it happened that the protocol was #0 then this only worked by accident. The pvo arrangements were also added a long time ago and have been the official way to do it. (And in fact, the client not giving the protocol name is a dumb way anyway).

lws-team avatar Nov 19 '25 08:11 lws-team