WTP与AC连接需要注意的问题

由于我们假定WTP不知道AC的IP地址是多少，所以WTP需要盲目的找：

• 用224.0.1.140为目的地址发送Discover包
• 用255.255.255.255为目的地址发送Discover包

我更倾向于224.0.1.140.(RFC5415有规定224.0.1.140为CAPWAP用的组播地址)，基于此，我们有以下问题要注意：

1. AC需要在处理目的地址224.0.1.140的包

为了让AC处理目的地址224.0.1.140的包，需要配置config.ac:

...
  <AC_MCAST_GROUPS>
  ...
+ 224.0.1.140
  ...
  </AC_MCAST_GROUPS>
  ...

即需要在AC_MCAST_GROUPS域里添加224.0.1.140这么一行，否则AC不会去处理目的地址为224.0.1.140的包。

而我们要求WTP在224.0.1.140这个组里发现AC，所以AC必须出来目的地址为224.0.1.140的包。

2. WTP把发现包发往224.0.1.140

为了让WTP把发现包发往224.0.1.140，需要修改config.wtp:

...
  <AC_ADDRESSES>
  ...
+ 224.0.1.140
  ...
  </AC_ADDRESSES>
  ...

添加224.0.1.140这样一行的话，WTP就会把发现包发往224.0.1.140

3. 添加224.0.1.140的路由规则

在我们目前的嵌入式路由设备上，通过udp包发往组播地址的数据包是发送不出去的，但是如果添加一条这个组播地址的主机路由就可以发送得出去。

所以，我们需要在WTP运行所在的嵌入式设备中添加这么一条主机路由：

route add -host 224.0.1.140 dev eth1

NOTE:
* eth1是WAN连接设备（不考虑PPPoE等连接方式）
* 这个还需要完善，因为eth1设备一down掉，这个路由规则就没了，而我们要求这个规则一直存在，要不然需要发发现包时就发送不出去。

4. 添加iptables规则

因为WTP发送发现包是发往224.0.1.140的，AC在收到这个发现包时，是以单播的方式回复WTP的，而这个回复包在WTP所在的设备中并没有对应的连接跟踪条目，因此就会给这个回复包建立一个NEW状态的连接跟踪。

而filter表的INPUT链中，会把来自WAN侧、并且连接跟踪状态是NEW的数据包DROP掉，从而导致WTP与AC无法连接。

考虑到AC给WTP的回复包的协议类型是UDP，源端口是1234，所以我们需要在WTP所在的设备上加入这么一条iptables规则：

iptables -A INPUT -p udp --sport 1234 -j ACCEPT

这样，AC给WTP的回复包就不会被丢掉，从而使得WTP与AC的连接过程得以继续。