Open Bug 1769293 Opened 1 month ago Updated 10 days ago

Add API PR_GetPrefLoopbackAddrInfo

Categories

(NSPR :: NSPR, enhancement)

enhancement

Tracking

(Not tracked)

REOPENED

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

Attachments

(3 files)

We need a function PR_GetPrefLoopbackAddrInfo that helps with servers, that only want to listen on a single IP address of a single family. An example is the NSS test tool selfserv.

The function will make a stable decision which family should be used. This allows separate server and client application to make the same decision for listening and connecting.

See the discussion in bug 636504 from May 2022. The bug was actually offtopic for this need.

Blocks: 1769295
Assignee: nobody → kaie
Status: NEW → ASSIGNED
Blocks: 1769299
Target Milestone: --- → 4.34
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
See Also: → 636509

OK, so I'm now processing the rebase for RHEL and ran into the following issues:

  1. There are a number of 'coverity'* issues with the nspr patch. These issues are probably theoretical, but the code is structured such that it expects them to be potentially real. If the addr entry is NULL, then aNetAddr never gets set, so the later test code could be doing tests on uninitialized data (or the previous time through the loop).
  2. while fixing this, I noticed that the code is clearing result based on the length of the the addr, not aNetAddr. This means the resulting code will clear out any previously set results if the later entries in the loop are smaller than the previous ones (which does, in fact, happen).
  3. If I fix the previous error, NSS test cases start to fail where they weren't before. This is because PR_GetAddrPrefLoopbackAddrInfo is returning the wild card address rather then the single address. The NSS test cases all use -4 to force tstclnt to use the IPV4 interface. For the server, we in fact want the wild card (::0) to be returned rather than the loopback address (::1) so that both IPV4 and IPV6 can both connect.

Downstream, I've fixed the coverity issues and used AI_PASSIVE for PR_GetAddrPrefLoopbackAddrInfo(). That's not a complete solution, but it preserves what the code is effectively doing now. What we want is a parameter to PR_GetAddrPrefLoopbackAddrInfo, in which we pass AI_PASSIVE for the selfserv, and not for tstclnt. The question is do we want just a bool (server/client), or do we want to pass the hints.flags in wholesale (server would pass AI_PASSIVE, clients would pass '0', other could pass other flags as desired).

I'll attach the downstream patches to this bug for reference.

bob

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Coverity bug fixes.

'coverity'* from comment 3

  • we use multple scanners, including clang in our 'coverity' scans. I think these issues were found with clang.
You need to log in before you can comment on or make changes to this bug.