问题背景：

        在大屏上做DFX自动上报需求时，遇到上报失败问题。错误位置为调用curl失败，连接不通。

 

定位过程&根因分析：

        遇到此类问题，首先需要确认URL是否是正确的。可以将URL复制到Windows系统直接进行访问，看是否能够访问成功。或者在命令行直接去ping这个URL的ip或者域名。

        此需求的URL是http://10.11.246.201/application/usage/report(涉及ip地址与域名，此ip以及后面域名为作者虚构)。

        在命令行ping 10.11.246.201是能够ping通的，说明此URL的ip是没问题的，设备与服务器之间的网络层连通性是正常的。由于此需求是在系统启动后进行上报，怀疑是系统启动时有可能网络服务还没起来，随后验证，在调用curl接口之前，判断网络是否可用，验证无问题。

        我们又将URL替换为百度的ip进行验证，发现连接成功，现能确定就是URL的问题。由于此URL是连接的特定服务器，随后排查方向是向服务器进行排查，端口是否开放，连接是否有限制。后了解需从3470接口进行访问，随后将端口号加入到URL后验证成功。

 

        在URL使用ip能够连接后，根据需求，由于服务器ip是不固定的，需将URL中ip替换为域名进行连接，URL替换为域名需要假如DNS解析流程，将域名解析为ip后进行连接。

        调用foundation/communication/netmanager_base/services/netmanagernative/src/manager/dns_manager.cpp中的DnsManager::GetAddrInfo接口进行解析。

       

 

        接口调用后解析域名遇到了报错。

       

        根据错误码查询报错为NET_CONN_ERR_SERVICE_UPDATE_NET_LINK_INFO_FAIL

 

        出现此报错，可能是权限问题或者是DNS服务问题，在我们的服务代码中可能没有权限调用此接口。由于此接口最终也是调用到的是musl三方库中的getaddrinfo_ext接口，为了避免权限问题。

 

        替换调用getaddrinfo_ext接口，结果还是报错。

 

        接口调用解析结果为-2，Name does not resolve，排查了入参没有问题，那么可能是getaddrinfo_ext接口有问题。

        后续追踪到在get_resliv_conf_ext函数中每次都走到ret < 0 分支，调用func函数从系统中读取DNS解析配置信息失败了。

 

解决方案：

        在进入调用func函数从系统中读取DNS解析配置信息失败，进入ret < 0分支后，直接去读取/etc/resolv.con配置文件，在/etc/resolv.con中添加谷歌公共DNS服务器，这样去从公共服务器中去解析域名。经过验证，能够修复无法DNS解析问题。