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

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


On Fri, Sep 30, 2016 at 1:36 PM, Brian Armstrong <
brian.armstrong....@gmail.com> 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!
lwip-users mailing list

Reply via email to