[Swan-dev] libswan/ttoaddress.c: use getaddrinfo(3) instead of gethostbyname2(3)

Andrew Cagney andrew.cagney at gmail.com
Tue May 4 17:07:00 UTC 2021


Just found another gotya.  From the linux page:
  If service is NULL [which it is], then the port number of the returned
socket addresses will be left uninitialized.
so it might be prudent to have the sockaddr_to_address_port() function
accept and ignore the port when it is NULL.
(posix says a "network-level address" is returned, which might be secret
code for don't read the port)

On Tue, 4 May 2021 at 12:50, Andrew Cagney <andrew.cagney at gmail.com> wrote:

>
>
> On Tue, 4 May 2021 at 07:47, Andrew Cagney <andrew.cagney at gmail.com>
> wrote:
>
>> Looking at the results that came in overnight
>> https://testing.libreswan.org/
>> The core seems to be fixed.  However, the results are still taking a
>> sizable hit; how does that compare to your local results?
>>
>
>  It looks like there's more than one challenge here:
>
> -> +whack error: IPv4 address must be exactly 4 bytes "192.1.3.209"
>
> err = data_to_address(res->ai_addr, res->ai_addrlen,
> aftoinfo(res->ai_family), dst);
> In theory something like:
>   ip_sockaddr sa = { .sa,sa = *res->ai_addr, .len = res->ai_addrlen, };
>   sockaddr_to_address_port(&sa);
> except I've my doubts that res->ai_addr is pointing to the full
> ip_sockaddr (it could be shorter for instance). So I'd guess:
>   ip_sockaddr sa = { .len = res->sa_addrlen, };
>  passert(res->sa_addrlen < sizeof(sa.sa))
>   memcpy(&sa.sa, res->ai_addr, res->sa_addrlen);
>   ...
> or expose an alternative interface
>
> -> -000 "named": failed to convert 'right.libreswan.org' at load time: not a numeric IPv4 address and name lookup failed (no validation performed)
> -> +000 "named": failed to convert 'right.libreswan.org' at load time: Name or service not known
>
> I'm not sure if we want to expose linux's idea of errors; if nothing else
> it will churn output
>
> ->
> https://testing.libreswan.org/v4.4-79-g1dad494d64-main/ikev2-x509-07-san-ip-mismatch/OUTPUT/west.console.diff
> this has me stumped; I guess a bad ip fed in somewhere and the connection
> should have been dropped instead of loaded?!?!
>
>
> Any ideas on fixing that function's portability?
>>
>
> Here's one thought.
>
> Since POSIX doesn't specify the list's order, what about scanning the list
> looking for something we like.  At least for when the family wasn't
> specified?
>
>
>> On Tue, 4 May 2021 at 00:23, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
>>
>>> | From: Andrew Cagney <andrew.cagney at gmail.com>
>>>
>>> | FYI,
>>> |
>>> https://testing.libreswan.org/v4.4-73-g379929c054-main/ikev2-ddns-03/OUTPUT/west.console.diff
>>>
>>> Thanks.
>>>
>>> Could you see if my latest commit fixes the problem.
>>>
>>> _______________________________________________
>>> Swan-dev mailing list
>>> Swan-dev at lists.libreswan.org
>>> https://lists.libreswan.org/mailman/listinfo/swan-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20210504/938f6084/attachment.html>


More information about the Swan-dev mailing list