Handling Socket Errors

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Handling Socket Errors

Brandon Noel

Hi,

 

We are using lwIP’s (STABLE-2.1.2) non-blocking  BSD socket interface in an application. Our current setup is two threads which each have their own socket and are communicating with different peers. Currently if lwip_send() returns -1 we call getsockopt(SOL_SOCKET, SO_ERROR) to get the error for that socket. We are unsure about what types of errors lwIP supports with getsockopt() and how to appropriately handle those errors.

 

What is the appropriate way to handle getsockopt(SOL_SOCKET, SO_ERROR) returning a fatal error? Should we call lwip_close()? Is it improper to call lwip_close() (in other words we should do nothing because of possible double freeing)? Does it depend on the error type? We also cannot rely on errno because of race conditions between the two threads.

 

(the following paragraph is what the code we are executing does based on my investigation)

The code returns the errno version of socket.netconn.pending_err. This pending_err member is only set in err_tcp (besides initialization) which is the fatal error callback for all TCP pcbs (pcb.tcp.errf). This fatal error callback is only called in a few places. If the peer reset the connection the error callback will be called with ERR_RST. If the connection has been closed but the application has only shut down the transmit side the error callback will be called with ERR_CLSD. If the slow timer sees that the TCP pcb should be removed the error callback will be called with ERR_ABRT. If tcp_abandon() is called and the pcb.tcp.state is not TIME_WAIT then the error callback will be called with ERR_ABRT.

 

Any direction or advice is appreciated.

 

Best,

 

Brandon Noel

Junior Firmware Engineer

Phone: 763.201.2000

Fax: 763.201.5333

Open Access Technology International, Inc.

3660 Technology Drive NE, Minneapolis, MN 55418

 


 

CONFIDENTIAL INFORMATION: This email and any attachment(s) contain confidential and/or proprietary information of Open Access Technology International, Inc. Do not copy or distribute without the prior written consent of OATI. If you are not a named recipient to the message, please notify the sender immediately and do not retain the message in any form, printed or electronic.

 


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Handling Socket Errors

goldsimon@gmx.de


On 01.05.19 21:47, Brandon Noel wrote:

> Hi,
>
> We are using lwIP’s (STABLE-2.1.2) non-blocking  BSD socket interface in
> an application. Our current setup is two threads which each have their
> own socket and are communicating with different peers. Currently if
> lwip_send() returns -1 we call getsockopt(SOL_SOCKET, SO_ERROR) to get
> the error for that socket. We are unsure about what types of errors lwIP
> supports with getsockopt() and how to appropriately handle those errors.
>
> What is the appropriate way to handle getsockopt(SOL_SOCKET, SO_ERROR)
> returning a fatal error? Should we call lwip_close()? Is it improper to
> call lwip_close() (in other words we should do nothing because of
> possible double freeing)? Does it depend on the error type? We also
> cannot rely on errno because of race conditions between the two threads.

Calling close is required if you're sure that the socket was valid as
it's not closed internally otherwise. The lwIP pcb *is* freed by the
stack, but not the socket.

In contrast, there's no check that the socket is yours, so if you just
call close() with any integer in the socket range, you could close some
connection. There's no risk of double-free though.

About 'errno': it's more or less mandatory for this to be a per-thread
value, so you might want to implement thread-local storage. Implementing
nonblocking socket programs without errno is rather pointless I guess...

Regards,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users