[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #60569] lwip_gethostbyname(_r) does not handle IPv4/IP
[lwip-devel] [bug #60569] lwip_gethostbyname(_r) does not handle IPv4/IPv6 correctly
Wed, 26 May 2021 02:45:02 -0400 (EDT)
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 Edg/90.0.818.62
Follow-up Comment #5, bug #60569 (project lwip):
As there has not been any further response on this topic, I can only assume
there is some hesitation on applying the patch without the support for IPv6
(even though the previous version hardcoded the h_addrtype to AF_INET).
I have now updated the patch so that lwip_gethostbyname and
lwip_gethostbyname_r supports AF_INET *and* AF_INET6, and correctly sets
h_addrtype, h_length and the h_addr_list entry accordingly (i.e.
AF_INET/struct in_addr and AF_INET6/struct in6_addr respectively).
In addition I have also added two routines lwip_gethostbyname2 and
lwip_gethostbyname2_r corresponding to the glibc2 routines gethostbyname2 and
gethostbyname2_r. There routines permits to specify the address family. For a
caller that do not expect gethostbyname to support AF_INET6, the compatibility
layer can now choose to define gethostbyname as lwip_gethostbyname2 and
While updating the implementation, I made one common “helper” routine that
the four other routines are calling, and additionally corrected a somewhat
strange usage of the memory alignment that could cause lwip_gethostbyname_r to
return ERANGE even if the buffer was large enough.
New patch is attached.
Additional Item Attachment:
File name: 60569-gethostbyname2.patch Size:14 KB
Reply to this item at:
Message sent via Savannah