Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

websocket failed to queue work (IDFGH-12667) #13659

Closed
3 tasks done
florentbr opened this issue Apr 21, 2024 · 0 comments
Closed
3 tasks done

websocket failed to queue work (IDFGH-12667) #13659

florentbr opened this issue Apr 21, 2024 · 0 comments
Assignees
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Type: Bug bugs in IDF

Comments

@florentbr
Copy link

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

release 5.2.1

Espressif SoC revision.

ESP32 v3

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32-DevKit

Power Supply used.

USB

What is the expected behavior?

A proper error message.

What is the actual behavior?

I got this log while trying to send messages with httpd_ws_send_data:

I (173837) hal-http: Active client (fd=55) -> sending async message
W (173837) httpd: httpd_queue_work: failed to queue work

origin:

0x40100769: httpd_queue_work at /home/flo/esp/v5.2/esp-idf/components/esp_http_server/src/httpd_main.c:159
0x40102827: httpd_ws_send_data at /home/flo/esp/v5.2/esp-idf/components/esp_http_server/src/httpd_ws.c:564

failing function in ctrl_sock.c :

int cs_send_to_ctrl_sock(int send_fd, int port, void *data, unsigned int data_len)
{
    int ret;
    struct sockaddr_storage to_addr = {};
#if IPV4_ENABLED
    struct sockaddr_in *addr4 = (struct sockaddr_in *)&to_addr;
    addr4->sin_family = AF_INET;
    addr4->sin_port = htons(port);
    inet_aton("127.0.0.1", &addr4->sin_addr);
#else
    struct sockaddr_in6 *addr6 = (struct sockaddr_in6 *)&to_addr;
    addr6->sin6_family = AF_INET6;
    addr6->sin6_port = htons(port);
    inet6_aton("::1", &addr6->sin6_addr);
#endif
    ret = sendto(send_fd, data, data_len, 0, (struct sockaddr *)&to_addr, sizeof(to_addr));

    if (ret < 0) {
        return -1;
    }
    return ret;
}

It occurs when the lwip loopback is turned off with IPV4 (CONFIG_LWIP_NETIF_LOOPBACK=n).

Shouldn't it be logged as an error and not warning ?

According to the doc the loopback is not required, it's for testing only:

"title": "Loopback",
"id": "ESP_NETIF_LOOPBACK",
"depends_on": "<choice ESP_NETIF_USE_TCPIP_STACK_LIB>",
"help": "Dummy implementation of esp-netif functionality which connects driver transmit\nto receive function. This option is for testing purpose only",

A static assert would be welcome to avoid the issue.

Steps to reproduce.

disable the lwip loopback (CONFIG_LWIP_NETIF_LOOPBACK=n)
enable websocket (CONFIG_WS_TRANSPORT=y)
send websocket messages to an IPV4

Debug Logs.

No response

More Information.

No response

@florentbr florentbr added the Type: Bug bugs in IDF label Apr 21, 2024
@espressif-bot espressif-bot added the Status: Opened Issue is new label Apr 21, 2024
@github-actions github-actions bot changed the title websocket failed to queue work websocket failed to queue work (IDFGH-12667) Apr 21, 2024
@espressif-bot espressif-bot assigned gabsuren and mahavirj and unassigned gabsuren Apr 22, 2024
@espressif-bot espressif-bot added Status: In Progress Work is in progress Status: Done Issue is done internally Resolution: NA Issue resolution is unavailable and removed Status: Opened Issue is new Status: In Progress Work is in progress labels May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

4 participants