[Bug nss/20690] New: getaddrinfo() for IPPROTO_UDPLITE

["roman at khimov dot ru" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20690

            Bug ID: 20690
           Summary: getaddrinfo() for IPPROTO_UDPLITE
           Product: glibc
           Version: 2.26
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nss
          Assignee: unassigned at sourceware dot org
          Reporter: roman at khimov dot ru
  Target Milestone: ---

Created attachment 9560
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9560&action=edit
Proposed fix

Using IPPROTO_UDPLITE in a hint (ai_protocol) for getaddrinfo() is broken, it
never returns meaningful result. That's because the code is searching for
'port/udplite' definitions in the /etc/services file and it has none of that.

RFC 3828 defining UDP-Lite protocol in the section 3.1 says:

       The fields Source Port and Destination Port are defined as in the UDP
       specification [RFC-768].  UDP-Lite uses the same set of port number
       values assigned by the IANA for use by UDP.

This statement is also reasserted by the RFC 6335 (in section 1):

       The Lightweight User Datagram Protocol (UDP-Lite) shares the port
       space with UDP.  The UDP-Lite specification [RFC3828] says: "UDP-Lite
       uses the same set of port number values assigned by the IANA for use
       by UDP".  An update of the UDP procedures therefore also results in a
       corresponding update of the UDP-Lite procedures.

So given that UDP-Lite and UDP explicitly share their port number values, I
think it should be fixed in the C library.

The patch attached changes the gaih_inet_typeproto structure to use "udp" name
for UDP-Lite lookups. At the moment this name is only used to search things so
it should be safe to do it this way, although, of course I might be wrong and
there is some other way to fix it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.