odd error code on getsockopt()

[mzimmers]

Code: Select all

    linger *lin;
    socklen_t lin_sz = sizeof(linger);
    lin = new linger;
  
    rc = getsockopt(sock, SOL_SOCKET, SO_LINGER, lin, &lin_sz);

returns with rc = -1 and errno = 109 (#define ETOOMANYREFS 109 /* Too many references: cannot splice */)

Any ideas what I'm doing wrong? And, what does too many references even mean?

Oh: sock is a successfully created/bound UDP socket. Communications on it works fine, as do several setsockopt() calls.

Thanks...

[kolban]

I suspect the puzzle is that we are mis-interpreting error code 109. If we look here:

https://github.com/espressif/esp-idf/bl ... rno.h#L138

We find that errno 109 is ENOPROTOOPT and if we use that as a google search keyword, we find that there are a wealth of hits on what it means to get that error code back from a call to getsockopt().

[ESP_Angus]

Hi mzimmers,

Kolban is correct. We use the libc "global" errno values not the ones in LWIP's headers (due to building LWIP without LWIP_PROVIDE_ERRNO set).

The reason for the ENOPROTOOPT result is that in ESP-IDF we don't build LWIP with LWIP_SO_LINGER enabled, so the feature isn't available. I'm not certain SO_LINGER does anything for UDP sockets in LWIP even with this option enabled, at least not in the version we have.

[mzimmers]

OK, that makes more sense. Thanks for the explanation. As it turns out, there is some value to SO_LINGER on UDP sockets:

https://stackoverflow.com/questions/329 ... udp-socket

But I don't need it. I was just making the call in an attempt to get a little insight on a weird problem I have starting/stopping Wifi.

Thanks guys...

[ESP_Angus]

As it turns out, there is some value to SO_LINGER on UDP sockets:

Sorry, I should have explained my reasoning a bit. I totally agree in the general case of a "big" TCP/IP stack. In the specific case of LWIP, the TCP/IP stack does as little queueing as possible to minimize the resource footprint - so in the case of UDP, the TCP/IP task will send UDP packets as quickly as it receives them.

This means that any send() calls which are made before the close() call will already have been sent (or dropped, if the network layer's internal buffers are full), before the close() call is processed.