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地址。