Re: [lwip-users] Failed lwip_getpeername() call appears to prevent future socket calls

[Brian Armstrong]

Just to chime in again here, what I ended up doing was defining a new error ERR_CONN_WARN which takes a new spot at -10. ERR_IS_FATAL now checks to see if an error is less than -10, and the location in api_msg.c that set this value for UDP now just sets it to ERR_CONN_WARN. Gross, but it does seem to have done the trick. I'll spare you the patch submission on this one ;)

I'll have to keep an eye on #13922, it sounds like there's more like this one.

Thanks again for this library guys, it's quite nice!

Brian

On Fri, Sep 30, 2016 at 1:36 PM, Brian Armstrong <address@hidden> wrote:

Hi,

I'm noticing some possibly unintuitive behavior where calling lwip_getpeername() on a socket that's not connected (silly, for sure, but perhaps still valid) appears to prevent any future socket calls from succeeding. For example, it seems to prevent calls to lwip_bind() or lwip_send().

Is this intentional behavior? I suspect this relates to the check by netconn_bind against last_err and netconn_getaddr calling NETCONN_SET_SAFE_ERR. Alternately, it may be that the error here should not be considered fatal.

Just for comparison, when I run this sequence of calls on my local host against its stack, it seems to work fine -- I am allowed to send after a failed call to getpeername().

Thanks!