ac的dhcp池里option43配错导致ap无法上线问题排查过程
dhcp池里ac地址配错，导致ap无法上线问题排查过程
问题：ap手动设置ac的ip正常注册在线，但dhcp获得ip和ac地址发现无法在ac上注册成功。
组网：
ac旁路结构，路由器lan口地址172.16.1.1，开dhcp服务，option43提供ac的地址172.16.1.206，地址池172.16.100-200，网关ip172.16.1.1。
解决过程：
如上图，路由器上开dhcp服务，给ap提供dhcp服务，dhcp池设置ip范围是172.16.1.100-172.16.1.200，掩码24，gw是172.16.1.1，ac的地址是172.16.1.206
ap1上电后，查看dhcp分配情况，发现分配地址是172.16.1.200，但在ac172.16.1.206上看不到ap1上线
路由器上
ac上
ap1 ping正常
登录ap，设置ac地址为手动配置172.16.1.206，并在路由器4口抓包
发现ac上，看到ap上线了
抓包tcpdump -i eth4 -nnev udp port 5246 -c 20 抓ap的capwap消息，udp port是5246，并抓20包自动退出-c 20，-nnev是关闭dns查询，数字化显示，显示mac地址，并显示详情
tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes
17:29:35.427300 6c:ef:c6:65:ab:c0 > 64:c3:41:b2:18:21, ethertype IPv4 (0x0800), length 567: (tos 0x7,CE, ttl 64, id 43379, offset 0, flags [DF], proto UDP (17), length 553)
172.16.1.200.5246 > 172.16.1.206.5246: UDP, length 525
17:29:35.427579 64:c3:41:b2:18:21 > 6c:ef:c6:65:ab:c0, ethertype IPv4 (0x0800), length 277: (tos 0x7,CE, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 263)
172.16.1.206.5246 > 172.16.1.200.5246: UDP, length 235
17:29:40.429262 6c:ef:c6:65:ab:c0 > 64:c3:41:b2:18:21, ethertype IPv4 (0x0800), length 825: (tos 0x7,CE, ttl 64, id 43559, offset 0, flags [DF], proto UDP (17), length 811)
172.16.1.200.5246 > 172.16.1.206.5246: UDP, length 783
17:29:40.429650 64:c3:41:b2:18:21 > 6c:ef:c6:65:ab:c0, ethertype IPv4 (0x0800), length 277: (tos 0x7,CE, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 263)
172.16.1.206.5246 > 172.16.1.200.5246: UDP, length 235
17:29:40.431498 6c:ef:c6:65:ab:c0 > 64:c3:41:b2:18:21, ethertype IPv4 (0x0800), length 603: (tos 0x7,CE, ttl 64, id 43560, offset 0, flags [DF], proto UDP (17), length 589)
172.16.1.200.5246 > 172.16.1.206.5246: UDP, length 561
17:29:40.432161 64:c3:41:b2:18:21 > 6c:ef:c6:65:ab:c0, ethertype IPv4 (0x0800), length 1050: (tos 0x7,CE, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 1036)
172.16.1.206.5246 > 172.16.1.200.5246: UDP, length 1008
17:29:40.616124 6c:ef:c6:65:ab:c0 > 64:c3:41:b2:18:21, ethertype IPv4 (0x0800), length 80: (tos 0x7,CE, ttl 64, id 43564, offset 0, flags [DF], proto UDP (17), length 66)
172.16.1.200.5246 > 172.16.1.206.5246: UDP, length 38
17:29:40.616458 64:c3:41:b2:18:21 > 6c:ef:c6:65:ab:c0, ethertype IPv4 (0x0800), length 60: (tos 0x7,CE, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 44)
发现ap的mac是6c:ef:c6:65:ab:c0，ip是172.16.1.200，ac的ip是172.168.1.206，mac地址是64:c3:41:b2:18:21，2毫秒后，开始有响应。
root@IIIoT:~# arp -n ap上执行命令arp -n
IP address HW type Flags HW address Mask Device
172.16.1.1 0x1 0x2 20:1f:54:f5:36:61 * br-wan
172.16.1.206 0x1 0x2 64:c3:41:b2:18:21 * br-wan
ap的banner显示mac地址
NAME: WAP6240-IE
MAC: 6c:ef:c6:65:ab:c0
奇怪，删除ap上手动配置ac地址，改成从dhcp的option43里获取ac地址，重启ap，在路由器上再次抓包
~ # tcpdump -i eth4 -nnev udp port 5246 -c 20
tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes
17:58:51.777366 6c:ef:c6:65:ab:c0 > 20:1f:54:f5:36:61, ethertype IPv4 (0x0800), length 567: (tos 0x7,CE, ttl 64, id 52870, offset 0, flags [DF], proto UDP (17), length 553)发给了这个mac地址
172.16.1.200.5246 > 17.16.1.206.5246: UDP, length 525 发出的目的ip 是17.16.1.206，好像ip错了，正确的ip是172.16.1.206，ip第一段错了
17:58:58.793246 6c:ef:c6:65:ab:c0 > 20:1f:54:f5:36:61, ethertype IPv4 (0x0800), length 567: (tos 0x7,CE, ttl 64, id 53510, offset 0, flags [DF], proto UDP (17), length 553)
172.16.1.200.5246 > 17.16.1.206.5246: UDP, length 525 没有响应，在重发
17:59:22.803515 6c:ef:c6:65:ab:c0 > 20:1f:54:f5:36:61, ethertype IPv4 (0x0800), length 567: (tos 0x7,CE, ttl 64, id 54484, offset 0, flags [DF], proto UDP (17), length 553)
172.16.1.200.5246 > 17.16.1.206.5246: UDP, length 525 没有响应，在重发
17:59:52.823960 6c:ef:c6:65:ab:c0 > 20:1f:54:f5:36:61, ethertype IPv4 (0x0800), length 567: (tos 0x7,CE, ttl 64, id 56270, offset 0, flags [DF], proto UDP (17), length 553)
172.16.1.200.5246 > 17.16.1.206.5246: UDP, length 525 没有响应，在重发
18:00:18.835629 6c:ef:c6:65:ab:c0 > 20:1f:54:f5:36:61, ethertype IPv4 (0x0800), length 567: (tos 0x7,CE, ttl 64, id 57090, offset 0, flags [DF], proto UDP (17), length 553)
172.16.1.200.5246 > 17.16.1.206.5246: UDP, length 525 没有响应，在重发
18:00:20.843741 6c:ef:c6:65:ab:c0 > 20:1f:54:f5:36:61, ethertype IPv4 (0x0800), length 567: (tos 0x7,CE, ttl 64, id 57274, offset 0, flags [DF], proto UDP (17), length 553)
172.16.1.200.5246 > 17.16.1.206.5246: UDP, length 525 没有响应，在重发
18:00:39.874509 6c:ef:c6:65:ab:c0 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 567: (tos 0x7,CE, ttl 64, id 18424, offset 0, flags [DF], proto UDP (17), length 553)
172.16.1.200.5246 > 255.255.255.255.5246: UDP, length 525 发出二层广播和三层广播发现消息
18:00:39.875037 64:c3:41:b2:18:21 > 6c:ef:c6:65:ab:c0, ethertype IPv4 (0x0800), length 277: (tos 0x7,CE, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 263)
172.16.1.206.5246 > 172.16.1.200.5246: UDP, length 235 有ac的响应
18:00:39.875166 20:1f:54:f5:36:61 > 6c:ef:c6:65:ab:c0, ethertype IPv4 (0x0800), length 277: (tos 0x7,CE, ttl 64, id 53519, offset 0, flags [DF], proto UDP (17), length 263)
172.16.1.1.5246 > 172.16.1.200.5246: UDP, length 235 有另一个ac的响应
18:00:44.876971 6c:ef:c6:65:ab:c0 > 20:1f:54:f5:36:61, ethertype IPv4 (0x0800), length 825: (tos 0x7,CE, ttl 64, id 46801, offset 0, flags [DF], proto UDP (17), length 811)
172.16.1.200.5246 > 172.16.1.1.5246: UDP, length 783 选择向这个ac的响应
18:00:44.877689 20:1f:54:f5:36:61 > 6c:ef:c6:65:ab:c0, ethertype IPv4 (0x0800), length 277: (tos 0x7,CE, ttl 64, id 54647, offset 0, flags [DF], proto UDP (17), length 263)
172.16.1.1.5246 > 172.16.1.200.5246: UDP, length 235
18:00:44.879582 6c:ef:c6:65:ab:c0 > 20:1f:54:f5:36:61, ethertype IPv4 (0x0800), length 603: (tos 0x7,CE, ttl 64, id 46802, offset 0, flags [DF], proto UDP (17), length 589)
发现最初ap发出的ip错误，mac地址发给20:1f:54:f5:36:61查询发现是路由器lan口地址，重发几次后，发出广播消息，所有的ac都会响应。
XOS#show ip arp
IP Address MAC Address Interface Type
172.16.1.187 c0:a6:6d:45:06:80 vlan1.3 ether
172.16.81.205 00:0f:c9:24:10:b1 vlan1.1 ether
172.16.1.1 20:1f:54:f5:36:61 vlan1.3 ether 发现这是路由器lan口地址对应mac是20:1f:54:f5:36:61，最初ap的capwap消息发给了路由器lan口mac地址
172.16.1.200 6c:ef:c6:65:ab:c0 vlan1.3 ether
Total arp count : 4
tcpdump不好判断，生成抓包文件，下载下拉查看
/mnt/userspace # tcpdump -i eth4 -w abc0.pcap 生成抓包文件
tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes
^C311 packets captured 中断后生成文件
313 packets received by filter
0 packets dropped by kernel
crt打开tftp服务器，准备传出文件
cmd下查看udp69端口是否打开？
C:\>netstat -aon | findstr :69 查看69端口是那个进程号打开，行尾红色为进程号，本例为22560
UDP 0.0.0.0:69 *:* 22560
UDP [::]:69 *:* 22560
C:\>tasklist | findstr 22560 根据进程号查询文件名
SecureCRT.exe 22560 Console 1 59,104 K 证明是crt打开了文件
确定文件保存目录
路由器里传出文件
/mnt/userspace # tftp -pl abc0.pcap 172.16.81.205 tftp传出文件
abc0.pcap 100% |*************************************************************| 34733 0:00:00 ETA传递完成
在已经获得tftp目录下打开抓包文件，并过滤bootp，arp和capwap消息
现在问题是dhcp获得的ac地址错误，导致ap注册关联消息发给网关
检查一下dhcp的offer消息
Value: 800c0131372e31362e312e323036 17.16.1.206
在ap上查询
root@IIIoT:~#
root@IIIoT:~# cd /tmp
root@IIIoT:/tmp# cat wtp.cfg dhcp获得ac的地址，
<WTP_DHCP_AC_IPV4_ADDR> 17.16.1.206 发现这个地址错误
root@IIIoT:/tmp# cat wtp.ip 这是目前ap连接的ac的ip地址
172.16.1.1 发现是网关的地址
在路由器上查看配置
修正
路由器上重新抓包查看：
tcpdump -i eth4 -nnev ether host 6c:ef:c6:65:ab:c0
19:56:08.315353 20:1f:54:f5:36:61 > 6c:ef:c6:65:ab:c0, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
172.16.1.1.67 > 172.16.1.200.68: BOOTP/DHCP, Reply, length 300, xid 0xaf764a47, Flags [none]
Your-IP 172.16.1.200
Client-Ethernet-Address 6c:ef:c6:65:ab:c0
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.16.1.1
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 172.16.1.1
Domain-Name-Server Option 6, length 4: 114.114.114.114
Vendor-Option Option 43, length 15: 128.13.1.49.55.50.46.49.54.46.49.46.50.48.54
ascii码显示的ac地址 1 7 2 . 1 6 . 1 . 2 0 6
19:56:09.304704 6c:ef:c6:65:ab:c0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.1.206 tell 172.16.1.200, length 46 arp查询
19:56:09.305024 64:c3:41:b2:18:21 > 6c:ef:c6:65:ab:c0, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 172.16.1.206 is-at 64:c3:41:b2:18:21, length 46 arp响应
capwap消息
19:56:14.311909 6c:ef:c6:65:ab:c0 > 64:c3:41:b2:18:21, ethertype IPv4 (0x0800), length 825: (tos 0x7,CE, ttl 64, id 18791, offset 0, flags [DF], proto UDP (17), length 811)
172.16.1.200.5246 > 172.16.1.206.5246: UDP, length 783 注册消息
19:56:14.312308 64:c3:41:b2:18:21 > 6c:ef:c6:65:ab:c0, ethertype IPv4 (0x0800), length 277: (tos 0x7,CE, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 263)
172.16.1.206.5246 > 172.16.1.200.5246: UDP, length 235 响应
问题总结：
原以为dhcp获得的ac地址和手动设置ac地址两个发discover包会有所区别，起始没有区别。
获得地址错误，查询路由器发现不是直连路由，会发向网关mac地址。