[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [task #14247] socket API: implement recvmsg msg_control sup

From: Joel Cunningham
Subject: [lwip-devel] [task #14247] socket API: implement recvmsg msg_control support
Date: Wed, 19 Apr 2017 15:01:00 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30

Follow-up Comment #13, task #14247 (project lwip):

 >  thing that looks strange is accessing the netconn's pcb without locking.
Even if it's only a read access, chances are that the pcb already got
deallocated. If not now, this might happen in the future. Isn't it enough to
check the flag in the netbuf in this case? 

Thanks for reminding me that PCB could be deallocated.  I think I can remove
the check because your suggestion of relying on buf->flags having

I was thinking down the road when we add the IPv6 version,
NETBUF_FLAG_DESTADDR would be set regardless of which version of PKTINFO
socket option was set, but maybe checking the IP type via IP_IS_V4 or _IS_V6
is enough to determine which cmsg to output.  Maybe I can also check the
domain in setsockopt and error if IP_PKTINFO is mixed with AF_INET6 (and vice
versa for AF_NET with IPv6 option)

 > Shouldn't the new feature work with LWIP_NETBUF_RECVINFO==1, too?

I could make it work with this configuration as well, but was limiting the
scope of the change.  The netbuf flags field would need to be enabled this
configuration (currently it's not).  Also in relation to the above point about
not accessing the PCB and checking NETBUF_FLAG_DESTADDR, with NETBUF_RECVINFO
== 1, the flag would always bet set regardless of the IP_PKTINFO option, which
would mean if a cmsg was provided during recvmsg, but IP_PKTINFO was off, the
stack would still output PKTINFO in the cmsg.  Maybe this isn't a big deal
since LWIP_NETBUF_RECVINFO == 1 always outputs the address


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]