今天终于解决了RouterOS与斐讯PSG718的兼容性问题！

y9ypste

此问题通过邮件、电话等方式向客服求助，客服态度很好，也很积极的解决，但估计是没有环境，所以进度较慢。但在双方的共同努力下，还是解决了。
以下都是邮件内容。
问题描述如下：
你好：
今日新购入一台斐讯PSG712路由器，经过试用，在路由模式时一切正常。但在AP模式时，使用5G WFI无法通过DHCP获取IP地址，但是能通过WIFI接入认证，能连到DHCP服务器。而2.4G WIFI却是可以正常获取IP，正常使用的。


又做了下实验，终于基本定位原因：
以下只是针对5G WiFi。

1、    用Android手机连接，能连上，不能通过DHCP获取IP地址，无法上网。但可以手工设置静态IP，上网正常。
2、    用笔记本电脑可以正常连接，可以通过DHCP获取IP地址，上网正常。
3、    奇妙的事情发生了，用笔记本电脑连接后，用Android手机也可以正常通过DHCP获取IP地址了！并且上网正常。
4、    然后，关闭笔记本电脑，重启路由器，又回到步骤1了，手机无法上网。

因此，推断桥接模式下，5G WiFi的实现有些问题，与Android手机可能存在不兼容现象。

对方回复：

您好：
        我们根据您描述的拓扑图做了测试，前端设备分别使用PSG712和TL-WDR5600作为主路由器，使用PSG712的AP模式，手机是三星note3，作为AP模式的PSG712重启了几次，之后手机都能正常获取地址。

        不知您的环境中前端设备与PSG712的连接距离如何？若方便，请把PSG712近距离连接前端路由器尝试下效果。

问题的解决：

原因还是RouterOS与PSG712有一定兼容性问题，将RouterOS DHCP Server中的“always-broadcast ”选项关闭即可，如果设置了保留IP，在保留IP上也要关闭此选项。


描述:关闭DHCP选项
描述:关闭保留IP的选项

Google了一下，发现这是个老问题了，有些客户端在频繁广播DHCP的时候会混淆，原文如下：

DHCP ‘always-broadcast’ confusion
Posted on March 21st, 2007 in General,Linux System Administration by Brandon
I run a DHCP server using Linux’s dhcpd program to serve addresses to a bunch of clients.  These clients are connected over several wireless links, and the radios are sometimes quirky.  Specifically, some clients never get the DHCPOFFER unless the ‘always-broadcast’ parameter is on.  This usually works out fine.
Today, however, we had a problem where we just saw a bunch of incoming DHCPDISCOVER messages, to which the server would reply with a DHCPOFFER. The devices would just continually send discover messages, and none would ever DHCPREQUEST an address.
From what I can conclude, I think that the clients were confused when they received multiple broadcast responses back for their DHCPDISCOVER message.  The client would then send another discover message, which just caused a never-ending loop of requests and offers.
To resolve the problem, I turned off always-broadcast for a few minutes.  This made the clients wait for a random period of time before discovering again.  Some clients accepted the IP fine even though it wasn’t broadcast.  For the ones that didn’t, I then re-enabled always-broadcast, and they picked up an address the next time that they tried.
For a long term solution, we’re working on subnetting the two /24 networks that are currently together into smaller /26 or /27 blocks.  That should reduce the possibility of having this happen again.