关于网络&wifi基础内容
前言
记录一些网络以及wifi的基础内容，会持续补充，以便后续有需要的时候查漏补缺
网络分层
- 分层的原因？如果不分层的话是否可行？
- 有了IP地址为何还需要mac地址？仅从地址作用上看用ipv6来取代mac地址是否可以？
为何分层？
Q1_个人理解
这种问题网上一大堆,其实我们没有必要纠结这种问题，这种成熟的架构时至今日是这个样子的，必定有其道理，搜索了下网上对此的解释，有不少是拿比喻来解释。
通过比喻向初学者解释一个知识点其实是不合适的，但是我们往往在深刻理解了一个东西后会想到用一个比喻，试图用它向不懂的人解释。比喻的意义往往是一群懂的人之间心领神会的交流方式罢了，所以就我个人而言，学习一个知识点的时候最好不用试图通过比喻来理解。
我们从软件设计模式的角度来看，其实分层是不是有点像Andorid的架构设计模式，不论是MVC,MVP,MVVM等，其本质都是为了解耦, 为了更方便职责明确, 也便于后续的维护调试,后续修改的话只要修改一层即可而不会牵一发而动全身。
既然你说是因为职责明确，那么每一层都有什么职责呢？
比如传输层解决的是进程定位的问题，网络层解决数据包寻路的问题，数据链路层解决局域网传输的问题等。
归纳起来就是一句话：
当一个系统足够复杂时，通过聚合分为不同层次或不同模块， 每层或模块都是内聚的，对外屏蔽复杂性。
那么宏观上看去，管理和问题定位很容易到具体层次和模块。 然后层层递进，很容易定位问题。
为何需要mac层？
Q2_个人理解
这个问题在网上试图查找资料时，很多说的很多都是因为ip地址会变，mac不变的缘故。
但是包在到达目的地之前是不知道目标mac地址的，mac层包装ip层的时候，对方的mac层地址还不一定是目标（最终的）mac地址，有可能是相连的一台路由器的mac地址，解码之后看ip，发现ip不在这个局域网内，然后再次包装一层mac地址，发给相连（也有可能不是相连，反正就是根据某种规则规定的下一个路由器）路由器，所以ip地址会变，mac不变的这样的解释是不合理的吗？最起码我觉得这种说法没有解释清楚这个问题。
网卡出厂就设置了mac地址是唯一的，我们也知道ip地址是可变的，就算机器没有移动，一直处在一个局域网内，重启网络也可能会导致ip地址改变。
数据包上ip 地址的作用是在外网上投递用的，内网就不行了，必须要用mac，使用mac地址的其中一个原因就是为了在局域网内确认到那台正确的计算机。
在知乎上找到一个比较好的解释为何需要mac层，和上面的解释是一样的
信息传递时候，需要知道的其实就是两个地址：
• 终点地址（Final destination address）
• 下一跳的地址（Next hop address）
IP地址本质上是终点地址，它在跳过路由器（hop）的时候不会改变，而MAC地址则是下一跳的地址，每跳过一次路由器都会改变。
归纳下来就是一句话：mac地址局域网寻址，ip地网络寻址
这就是为什么还要用MAC地址的原因之一，它起到了记录下一跳的信息的作用
用ipv6来取代mac地址是否可以？
既然ipv6号称可以给世界上每一个沙子都分配一个ip地址，那为何不直接取消mac地址，给每一个网卡出场时分配一个ip地址。
这是一个看起来比较天马行空的问题。
前面提到mac地址起到“下一跳IP地址”的作用，那么我们用ipv6反正不用担心ip不够用的问题对吧，假设交换机也支持IP地址转发（现在的二层交换机不支持这样做），mac地址好像看上去也并不是必要的对吧？
当然了mac地址不仅仅是标记网卡这一个作用，先假设它只有这么一个作用，想想这样可行吗？
很快便想到一个问题就是这个ip地址得广播出去，假设地球上有几百亿的设备，转发匹配这几百亿的记录便不可能实现，需要的存储太大太大。
这个问题搜索了网上貌似相关的解答比较少，知乎上有一个回答我觉得比较好，照抄过来:
IPv6定义了多种地址，其中一种地址叫Link-local地址，看上去可以取代mac地址，可是二层三层的封装已经通行于全世界，ipv6何德何能可以打破所有网络设备，主机，都在使用的规范？打破规范带来的网络中断，迁移成本这些也是难以实现的
tcpip协议栈设计出来那天就没有自己定义二层协议，也没有取代二层协议，而是去兼容二层协议，仅此而已，让自己能跑在各种二层协议之上
DHCP
本地抓取的正常流程的bugreport，分别包含logcat&driver日志片段，后续可以作为参考分析
静态分配和dhcp分配导致的ip冲突报文
Q: DHCP Offer 和 DHCP ACK是广播包吗？由什么因素决定的？
A：这个其实是取决于client端的ip协议栈的能力，可以抓个报文看下就知道了。
如果协议栈在初始化过程中，不接收单播IP报文，请在DHCP Discovery / Request报文的Flags里明确告知服务器，通过设置“BROADCAST flag = 1”，服务器就使用广播来和客户端通信。
如果协议栈在初始化过程中，可以接收单播IP报文，请在DHCP Discovery / Request报文的Flags里明确告知服务器，通过设置“BROADCAST flag = 0”，服务器就使用单播来和客户端通信。
既然广播方式通信适合所有的协议栈，统统使用广播不就ok了，为何要有这个Flags，岂不是多此一举？
单播最大的优点：通信是点对点方式，不会影响到广播域的其它主机。
广播的特点：通信是点对所有点的方式，会影响到广播域里其它所有主机
链路层放置目标机器的mac地址即可将信息送达客户端机，非该mac地址的机器收到后会丢弃这个包，此时的ip层目标网络地址填的就是要分配给该客户端机的ip地址;
官方文档说明
Q: 是否存在静态ip和DHCP Server分配给Client的ip冲突的情况？ 有冲突后会怎么样？会导致网络访问异常？
A：网上找到一篇文章，解释的不错，地址：DHCP以及客户端是如何避免IP冲突
在最后的确认阶段，当Client收到DHCP Server发送的DHCPACK报文之后，并不会马上使用Server分配的这个地址，而是会发送目的地址为Server分配地址的ARP请求报文作最后的确认（即免费ARP）。
如果没有检测到冲突，则将此地址与自己绑定。如果检测到冲突，就向DHCP Server发送DHCPDECLINE报文，在Request IP Address（option 50）字段填入Server提供的发生冲突的IP地址.发送完成后，等待一段时间再开始重新申请IP地址，直至申请到一个可用的IP地址。
Q：DHCP server的地址池是有限的吧？同时有大量的client发起请求会不会存在不够用的情况？
A: 服务器收到了Discover 包之后，就会从地址池中选择一个IP准备分配给请求者，当然正常情况下客户端收到服务器发送的Offer会回复Request进行确认，但是在泛洪攻击的场景下服务器会收到大量的Discover报文当然也会在地址池为这些请求者执行分配IP的操作并等待客户端的应答。
在没有得到客户端确认的情况下，服务器将会为客户端保留要分配的IP，当在大量泛洪攻击的场景下服务器的地址池很快就会满掉。从而影响正常客户端的使用。
那我们这个时候就有疑问了，能不能尽可能的扩大这个地址池呢？想象一个极端的情况，地址池中的ip数无穷无尽，这不就不存在这个问题了吗？
其实只要简单修改掩码，就可以实现更多的客户端接入，别说254，一万个254都装的下。
掩码是用来决定网段大小的，也就是说，一个网段能容纳多少个终端（电脑，手机，摄像头），是由掩码来决定的。
最常用的掩码是255.255.255.0，和题主说的一样，最大的可用ip数量只有254
但如果把掩码换成255.255.0.0，那么最大可用ip数量，就有256乘256减2，好几万了
但是为什么不推荐一个网段主机数太多呢？
在实际项目上，虽然通过掩码可以让网段变大，让网络的配置和调试变的简单，但往往还是不用大网段。原因就在于“广播域”
什么是广播域，顾名思义，就是1个主机发出的广播包，可以到达的范围。
如果一个网段大，那么广播域就大，就像我们再嘈杂的环境里，会收到大量和自己无关的数据，这些数据将占用我们的带宽，以及消耗我们各个终端的计算资源。毕竟广播包，目标地址是所有人，所有人收到都不能视而不见，都要处理。
所以，当终端数比较多的时候，一般会采用多个网段，多个vlan（虚拟局域网）的方法，而不是一下搞个大网段。
网关
这里穿插下网关的概念，什么是网关呢？
如果你去网上搜索，能搜索到的关于网关的解释大多是这样的:
网关往往是一个路由器，是一个三层转发的设备。那么啥叫三层设备？就是把 MAC 头和 IP 头都取下来，然后根据里面的内容，看看接下来把包往哪里转发的设备。
个人理解：
说来惭愧，之前对于网关的认识以为就是路由器，其实这种认识是不准确的。
首先‘网关’一个大概念，不具体特指一类产品，只要连接两个不同的网络的设备都可以叫网关；而‘路由器’一般特指能够实现路由寻找和转发的特定类产品，路由器很显然能够实现网关的功能。
当然电信行业说的‘路由器’又和家用的‘路由器’两个概念。网关并不总是被视为路由器，路由器是最常见的网关，用于将家庭或企业网络连接到Internet。
PC本身不具备路由寻址能力，所以PC要把所有的IP包发送到一个默认的中转地址上面进行转发，也就是默认网关。这个网关可以在路由器上，可以在三层交换机上，可以在防火墙上，可以在服务器上，所以和物理的设备无关。
网关只针对某个局域网，是某个局域网的出口地址，而一个路由器由多个网关组成
任何一个想发往其他局域网的包，都会到达其中一只手，被拿进来，拿下 MAC 头和 IP 头，看一下，根据自己的路由算法，选择另一只手，加上 IP 头和 MAC 头，然后扔出去。
如果离开本局域网，就需要经过网关，网关是路由器的一个网口；路由器是一个三层设备，里面有如何寻找下一跳的规则；
WIFI漫游
下面这个图摘自高通文档上，主要是漫游的一个流程
代码中关于漫游的原因，更加细致
本地抓取的9434附录屏的漫游日志，类型：Dense roaming
上面fw中打印的roam reason对应的代码地址(qcom)
vendor/qcom/opensource/wlan/fw-api/fw/wmi_unified.h
顺便解释下本地抓取的这份漫游reason 7对应的是DENSE roaming的解释，摘自高通文档
Dense roaming
Dense-roaming mechanism is a new feature of location retrieval function (LRF) 3.0. This feature retains high throughput when many roamable APs are present nearby and the data traffic is high then.
The original Wi-Fi roaming mechanism is designed to enable roaming when the current RSSI value reaches the defined RSSI threshold value, for example, -76 dBm.
However, in a high dense environment where there are many roamable APs, it is better to start roaming earlier when the traffic is high because high throughput is maintained for heavy traffic with minimal power consumption impact. Dense roaming functions in such a manner to retain high throughput during periods of heavy traffic.
To provide this value-added enhancement, the dense roaming mechanism is designed with the following two principles.
■ Relying on other triggered scans, sniffing is performed on the management packets to determine the number of roamable APs that are present then in the environment.
■ If a dense roaming environment is found (that is, the number of the found roamable APs is bigger than the configured dense roamable AP threshold value), and if there is significant traffic at that moment, then switch to use the dense RSSI threshold value so that the roaming is triggered earlier.
MTK online上关于MTK的漫游策略如下图，其实和qcom大同小异，大的流程都是一样的
如下是平时分析漫游可能会用到的关键字
//Logcat:
CTRL-EVENT-DISCONNECTED|CTRL-EVENT-CONNECTED|fetchRssiLinkSpeedAndFrequencyNative|NL80211_CMD_ROAM|(set AP RSN IE)|LOST_PROVISIONING|wpa_supplicant: wlan0: State
//fw log
VDEV_MGR_MY_BEACON_RECEIVED|ROAM_LOW_RSSI_INTERRUPT|PEER_ASSOC|ROAM_BETTER_CANDIDATE_FOUND|ROAM_SCAN_REQUESTED|VDEV_MGR_FIRST_BMISS_DETECTED|ROAM_FINAL_BMISS_RECVD|roaming attempt to bssid|RSSI_MONITOR_GET_BEACON_RSSI_AVG
- 触发漫游的原因有哪些？
- 漫游到哪个候选AP(假设存在)? 有哪些评判条件？
- 漫游会断线吗？会重新走四次握手吗？
ARP&NDP
上面是ARP的一个简单流程，这里涉及到一个缓存的过程，大体解释如下:
为了避免机器每次都使用ARP协议发送ARP请求，在每台机器的本地会进行ARP缓存。
–>只要涉及到缓存，那就是空间换时间的设计思想
- 一般机器都是先查本地ARP缓存
- 本地ARP缓存查不到，再去发送ARP请求在局域网中去找目标IP地址对应的MAC地址
当然机器会不断地上线下线，IP 也可能会变，所以 ARP 的 MAC 地址缓存过一段时间就会过期
ipv6 ND
地址解析过程中使用了两种ICMPv6报文：邻居请求报文NS（Neighbor Solicitation）和邻居通告报文NA（Neighbor Advertisement）。
• NS报文：Type字段值为135，Code字段值为0，在地址解析中的作用类似于IPv4中的ARP请求报文。
• NA报文：Type字段值为136，Code字段值为0，在地址解析中的作用类似于IPv4中的ARP应答报文。
NS报文
arp request
Q：什么是ARP风暴？
A：ARP广播时，交换机会将一个端口收到的包转发到其它所有的端口上。
比如数据包经过交换机A到达交换机B，交换机B又将包复制为多份广播出去。
如果整个局域网存在一个环路，使得数据包又重新回到了最开始的交换机A，这个包又会被A再次复制多份广播出去。
如此循环，数据包会不停得转发，而且越来越多，最终占满带宽，或者使解析协议的硬件过载，行成广播风暴。
DNS
如果分析类似网页加载不出来的问题时候，我们首先需要清楚的知道加载一个网页的流程
• DNS 解析:将域名解析成 IP 地址
• TCP 连接：TCP 三次握手
• 发送 HTTP 请求
• 服务器处理请求并返回 HTTP 报文
• 浏览器解析渲染页面
• 断开连接：TCP 四次挥手
Q: 对于已连接网络无法上网问题的快速排查思路？
断线问题
如下是本地测试打印，操作步骤是主动删除已连接热点
如下是本地测试打印，操作步骤是超出范围断开
Q: 断线一般有哪些原因？
A:
- 用户手动断开
- FWK断开
- Beacon miss断线
- KickOut断线
- Nud failed断线
- Rx disassoc or deauth断线
Q: 如何通过日志如何快速定位断线是上层还是底层发起的？
A:如果是底层断线，会先收到底层断线发上来的DISCONNECT Event，然后supplicant才把state切到DISCONENCTED.
如果是上层断线，disconnection request会先到supplicant，supplicant state会先切到DISCONNECTED, 发送disconnect request给driver去真正端开wifi连接.
归纳下来就是迅速定位是底层还是上层有一个好的办法就是：
过滤这两个关键字：wpa_supplicant: nl80211 , wpa_supplicant: wlan0看看先后关系
Q: 有哪些日志关键字可以过滤来分析断线问题？
如下是一些关键字，当然前提你得清楚这些关键字的含义
//bugreport：
CMD_IP_REACHABILITY_LOST|NETWORK_DISCONNECTION_EVENT|Received Heart Beat Failure|dev wlan0 INCOMPLETE|get addr info failed|arp who-has|ICMPv4 dst|LOST_PROVISIONING|wma_peer_sta_kickout_event_handler|NetConnTag|No address associated with hostname|DnsMain|IcmpReader|NetworkProvider|NetworkDiagnostics|DnsService|PROBE_DNS
//driver:
STA kickout|blm_fill_reject_list|wma_peer_sta_kickout_event_handler|Sending Deauth frame with reason
//fw
ROAM_STA_KICKOUT_RECV|consecutive failure=
fw的关键字主要是看tx fail的阀值是否达到了上限，很多都是RSSI值太低导致，还有一种常见的问题是AP没有回ack导致手机一直tx fail,最终触发kickout，这种需要提供sniffer log确认。
连接不上问题
本地测试密码错误抓取的bugreport，以便后续分析日志对照
//Auth fail
rx Auth frame from peer with failure code对应的fail code参见 802.11 Association Status Codes
https://wiki.n.miui.com/display/~lihaizhou/802.11+Association+Status+Codes
eg: code = 17 Association denied because AP is unable to handle additional associated stations
// portal fail
2020-12-03T18:08:11.852 - PROBE_DNS connect.rom.miui.com 12511ms FAIL
2020-12-03T18:08:39.391 - PROBE_HTTP http://connect.rom.miui.com/generate_204 Probe failed with exception java.net.UnknownHostException: Unable to resolve host "connect.rom.miui.com": No address associated with hostname
2020-12-03T18:08:39.394 - Probably not a portal: exception java.net.UnknownHostException: Unable to resolve host "m.baidu.com": No address associated with hostname
//filter：
Cannot add/update network|save network failed|All saved networks are lost|Association Rejection|CTRL-EVENT-ASSOC-REJECT|EVENT_DHCPACTION_TIMEOUT|NETWORK_SELECTION_DISABLED_BY_WRONG_PASSWORD|AUTHENTICATION_FAILURE|pre-shared key may be incorrect|wpa_supplicant: wlan0
//driver：
Auth frame from peer with failure|Auth Failure occurred
Q：连接不上通常有哪几种情形？如何快速甄别？
Auth失败
一般driver日志中会打印出Auth frame from peer with failure后面对应code值，code值查阅
802.11 Association Status Codes即可，正常返回的是0，如果问题有sniffer的话，也可以看auth帧的status值
像数值17 对应的含义 Association denied because AP is unable to handle additional associated stations 被AP拒绝了，这时候同时连接AP的sta可能太多了超过了AP的负载
四次握手异常
1,2握手失败是密码错误导致，其它的可能是路由器设置问题
DHCP失败
DHCP请求没有回复，看看当时rssi判断信号弱不弱，为什么连接成功但是DHCP会失败：因为连接过程一直发送管理帧，数据小，DHCP是数据帧，比较大，在信号弱时无法正常交互。
