wifi 概率性自动断线（IpReachabilityMonitor）

描述：该文主要介绍基于Android 7.0 的IpReachabilityMonitor机制，有时候会遇到用户反馈wifi 会概率性自动断线，最后发现是系统有开启IpReachabilityMonitor 机制，可能是在干扰严重环境下或相对弱信号下让系统误判导致下断线。

如下只要针对IpReachabilityMonitor机制描述说明

• IpReachabilityMonitor功能描述及作用

    a. IpReachabilityMonitor的代码实现逻辑不关心为什么一个neighbour网络变为不可达。相反，他主要反映在内核层面中每一个neighbour网络的IP可达性概念或状态。我们知道这个IP可达性状态对于正常网络连接来说是关键重要的。因此IpReachabilityMonitor通常仅是“信使”：它警告neighbours网络已经被内核kernel视为不可达。

   b.IpReachabilityMonitor 机制是在Android 7.0中新增,主要是要确认gateway or DNS server是否可以为unreachable,此机制会  定期(大约18s~22s timer到就会做一次)trigger 上层发送arp req,若发送三笔arp req未收到对应arp rsp IpReachabilityMonitor  会fail,trigger上层下断线

 

    c. 下断线条件:arp req三笔都发出去后,第三笔隔一秒后还是没有收到arp rsp就trigger断线, driver log可以看到明确的1s发送    一个arp req,   但送到air时间未必会是一秒就tx 1笔(可以看sniffer log）

    d.Android是透过 Linux netlink socket机制去获得 kernel neighbor 信息,(NETLINK_ROUTE 的 neighbor , 利用 kernel ARP    cache) :https://blog.youkuaiyun.com/qy532846454/article/details/6806197, 所以当ARP table 没有该信息时, 应该会用 broadcast 方式.在干扰较大的环境下, 可以调整参数来增加发 ARP 的次数：http://man7.org/linux/man-pages/man7/arp.7.html

• 如何规避因IpReachabilityMonitor导致系统下断线

       1.在系统frameworks\base\core\res\res\values\config.xml中关闭“IpReachabilityMonitor”,

参考如下：
        

也可参考链接：https://github.com/ngoquang2708/android_device_samsung_vivalto3gvn/commit/773986dabc49a8cb550be657f9f78f61994109f8

    2. 可以通过下指令调整参数来增加 ARP  req发送次数, cmd如下(关于mcast_solicit和ucast_solicit)               

           #echo 10 > /proc/sys/net/ipv4/neigh/wlan0/mcast_solicit 

           #echo 10 > /proc/sys/net/ipv4/neigh/wlan0/ucast_solicit

     可参考：http://man7.org/linux/man-pages/man7/arp.7.html

 

 

 

• 介绍基于Android 7.0 的IpReachabilityMonitor机制

     1. IpReachabilityMonitor简介

* Monitors on-link IP reachability and notifies callers whenever any on-link addresses of interest appear to have become unresponsive.
//监视链路IP的可达性；无论任何时候，一旦所关注的链路地址变的不响应时，就会通知调用者。

*This code does not concern itself with "why" a neighbour might have become unreachable. Instead, it primarily reacts to the kernel's notion of IP reachability for each of the neighbours we know to be critically important to normal network connectivity. As such, it is often "just the messenger":the neighbours about which it warns are already deemed by the kernel to have become unreachable.

//IpReachabilityMonitor的代码实现逻辑不关心为什么一个neighbour网络变为不可达。相反，他主要反映在内核层面中每一个neighbour网络的IP可达性概念或状态。我们知道这个IP可达性状态对于正常网络连接来说是关键重要的。因此，IpReachabilityMonitor通常仅是“信使”：它警告neighbours网络已经被内核kernel视为不可达。

 2. IpReachabilityMonitor工作方式

  

1). The "on-link neighbours of interest" found in a given LinkProperties instance are added to a "watch list" via #updateLinkProperties().This usually means all default gateways and any on-link DNS servers.

//在给定的LinkProperties实例中找到关注的链路neighbours网络，这些neighbours网络被通过updateLinkProperties()方法添加到一个"watch list"中。这通常意味着所有默认网关和链路DNS服务器。

 

2). We listen continuously for netlink neighbour messages (RTM_NEWNEIGH,RTM_DELNEIGH), watching only for neighbours in the watch list.

//我们连续不断地监听netlink消息（RTM_NEWNEIGH,RTM_DELNEIGH），仅仅关注在watch list中的neighbours网络。

   - A neighbour going into NUD_REACHABLE, NUD_STALE, NUD_DELAY, and even NUD_PROBE is perfectly normal; we merely record the new state.
   //一个neighbour网络进入NUD_REACHABLE, NUD_STALE, NUD_DELAY和NUD_PROBE状态，均是完全正常现象，我们只是记录最新的状态。

  - A neighbour's entry may be deleted (RTM_DELNEIGH), for example due to garbage collection.  This is not necessarily of immediate concern; we record the neighbour as moving to NUD_NONE.
  //一个neighbour条目可能被删除（RTM_DELNEIGH），例如由于垃圾回收。这个没有必要进行立即关联。我们记录被搬移到NUD_NONE状态的neighbour网络。

  - A neighbour transitioning to NUD_FAILED (for any reason) is  critically important and is handled as described below in #4.
  //一个neighbour网络被转移到NUD_FAILED（任何原因）是极其重要的，这个相应的操作将会在下面#4描述。

3). All on-link neighbours in the watch list can be forcibly "probed" by calling #probeAll(). This should be called whenever it is important to ve