一个ROS+OP的迷幻问题

KleinerSource commented 4 years ago

反馈bug/问题模板，提建议请删除

1.关于你要提交的问题

Q：是否搜索了issue (使用 "x" 选择)

[ x ] 没有类似的issue

2. 详细叙述

op 除了某+服务以外其他的服务均未开启

(1) 具体问题

A：主路由是routeros 拿op做旁路另有个wifi路由做AP dhcp 为ros 设定默认网关到op 但是只要是 op启动之后有设备wifi连接到 AP (部分设备例如小米网关灯笔记本电脑等) 就会不停的释放和获取dhcp地址(15秒左右一次) 无限循环释放获取ip 不管绑定或未绑定都一样但是在过程中只要重启op 就都正常了只要op 重启好之后连接的部分设备就会有这种情况发送 op重启过程中连接wifi设备都正常.

(2) 路由器型号和固件版本

A：软路由大雕很多个版本都试过结果一样, 但是试过K某好像没有这个问题

(3) 详细日志

A：

iyuangang commented 4 years ago

跟我家的方案差不多，差异为我的中心思想为一个设备负责任务不能与其他设备重复。 routeros 负责拨号，关闭dhcp服务，开启防火墙，除WAN口外其他口bridge，分配ip地址R1。 op 负责 DHCP 及其他任务，单口连接routeros LAN口，设置IP R2及默认网关为R1，设置DNS，开启op DHCP。 WiFi 负责无线接入，关闭WiFi Lan口 dhcp ，设定LAN口IP R3，网线连接WiFi lan口及routeros LAN 口。WiFi WAN 口空置。其中 IP R1 R2 R3 均在同一网段，DHCP 也在同一网段。

对于下载机等不需要特殊服务的大流量客户端，设定静态ip 网关为R1 对于其他有特殊需求的客户端，DHCP 分配，网关DHCP分配为R2，可享受特殊需求。

KleinerSource commented 4 years ago

我就是因为喜欢 ros的 window 方式管理看的直观操作方便所以把dhcp 拨号等功能全都交给他 op只做一项服务但是这个dhcp问题一直无解

swirly0p commented 4 years ago

网络-接口-br-lan-DHCP，把OP的DHCP关闭了吗？

KleinerSource commented 4 years ago

dhcp当然关了而且这个问题只出现在部分wifi身上有线设备没问题 ios设备也没问题 ps4 也没问题

nichwang88 commented 4 years ago

我也是主路由ROS（DHCP服务器在ROS中），旁路由openwrt，若干无线路由器为AP，没有出现任何DHCP问题。你的问题出现在WIFI上，检查你的AP设置是否有问题，是否设置AP模式，或者还是路由模式，DHCP没有关的可能性。

KleinerSource commented 4 years ago

我也是主路由ROS（DHCP服务器在ROS中），旁路由openwrt，若干无线路由器为AP，没有出现任何DHCP问题。

你的问题出现在WIFI上，检查你的AP设置是否有问题，是否设置AP模式，或者还是路由模式，DHCP没有关的可能性。

我ap也是同版op 设置也一样。而且只用ks版的lede是没有这问题的我也很纳闷

KillingJacky commented 4 years ago

禁用FullCone NAT重启路由器解决。可能还需要重启运行dhcp client的程序 or 虚机。

KleinerSource commented 4 years ago

禁用FullCone NAT重启路由器解决。

可能还需要重启运行dhcp client的程序 or 虚机。

关闭 fullcore 并重启路由器和wifi 均无效

KillingJacky commented 4 years ago

如果你的ROS是装在某种虚拟环境中，需要重启ROS所在的虚机。我猜你的某些申请不到IP的WiFi设备是DHCP Discovery的时候带了让DHCP Server以广播方式回应，而你的广播包在层层转发中丢了。你可以用WireShark抓一下包。

KleinerSource commented 4 years ago

如果你的ROS是装在某种虚拟环境中，需要重启ROS所在的虚机。

我猜你的某些申请不到IP的WiFi设备是DHCP Discovery的时候带了让DHCP Server以广播方式回应，而你的广播包在层层转发中丢了。

你可以用WireShark抓一下包。

我ros是物理机只有op是虚拟机而且我之前 ros+ks版lede+lean版op（wifi）是没有这个问题的换成ros+lean版op+lean版op（wifi）才出现这个奇怪的问题而且出问题的设备基本上都是米家网关和灯像手机平板笔记本这类东西都没问题

KillingJacky commented 4 years ago

如果你的ROS是装在某种虚拟环境中，需要重启ROS所在的虚机。我猜你的某些申请不到IP的WiFi设备是DHCP Discovery的时候带了让DHCP Server以广播方式回应，而你的广播包在层层转发中丢了。你可以用WireShark抓一下包。

我ros是物理机只有op是虚拟机而且我之前 ros+ks版lede+lean版op（wifi）是没有这个问题的换成ros+lean版op+lean版op（wifi）才出现这个奇怪的问题而且出问题的设备基本上都是米家网关和灯像手机平板笔记本这类东西都没问题

我的情况是，lean OP装在pve虚拟环境中作主路由，pve bridge出来接交换机，接AP（普通路由器），也是某些设备无法申请到IP，WiFi association 阶段是可以过的，抓包发现OP发出的dhcp offer、dhcp ack等包根本无法发出OP（在pve bridge中dump的包），确定了OP设置的问题。同时，pve中还有另外一个隔壁家的lede，替换掉Lean OP，没有任何问题，对比lede与OP的设置发现，OP使能了FullCone NAT，关闭后，dhcp offer包可以正常发出，问题解决。我这边也是有线设备正常，WiFi AP下设备异常，猜测是Linux FullCone实现不够完美，UDP广播包在穿越多级交换后到达Linux Kernel，FullCone之后的包，出不去Linux Bridge，链路比较复杂没有去细究了。以上，供您参考。细看了一下您的情况，好像不太一样，你不是申请不到IP，是反复申请，怀疑还是LAN中有2个DHCP Server。

KleinerSource commented 4 years ago

如果你的ROS是装在某种虚拟环境中，需要重启ROS所在的虚机。

我猜你的某些申请不到IP的WiFi设备是DHCP Discovery的时候带了让DHCP Server以广播方式回应，而你的广播包在层层转发中丢了。

你可以用WireShark抓一下包。

我ros是物理机只有op是虚拟机

而且我之前 ros+ks版lede+lean版op（wifi）是没有这个问题的

换成ros+lean版op+lean版op（wifi）

才出现这个奇怪的问题

而且出问题的设备基本上都是米家网关和灯

像手机平板笔记本这类东西都没问题

我的情况是，lean OP装在pve虚拟环境中作主路由，pve bridge出来接交换机，接AP（普通路由器），也是某些设备无法申请到IP，WiFi association 阶段是可以过的，抓包发现OP发出的dhcp offer、dhcp ack等包根本无法发出OP（在pve bridge中dump的包），确定了OP设置的问题。

同时，pve中还有另外一个隔壁家的lede，替换掉Lean OP，没有任何问题，对比lede与OP的设置发现，OP使能了FullCone NAT，关闭后，dhcp offer包可以正常发出，问题解决。我这边也是有线设备正常，WiFi AP下设备异常，猜测是Linux FullCone实现不够完美，UDP广播包在穿越多级交换后到达Linux Kernel，FullCone之后的包，出不去Linux Bridge，链路比较复杂没有去细究了。

以上，供您参考。

细看了一下您的情况，好像不太一样，你不是申请不到IP，是反复申请，怀疑还是LAN中有2个DHCP Server。

请问抓包再哪个设备上执行呢我现在这几个这些小米设备的ip都是10秒一次 ros日志是 dhcp assigned 然后dhcp deassigned

KleinerSource commented 4 years ago

如果你的ROS是装在某种虚拟环境中，需要重启ROS所在的虚机。

我猜你的某些申请不到IP的WiFi设备是DHCP Discovery的时候带了让DHCP Server以广播方式回应，而你的广播包在层层转发中丢了。

你可以用WireShark抓一下包。

我ros是物理机只有op是虚拟机

而且我之前 ros+ks版lede+lean版op（wifi）是没有这个问题的

换成ros+lean版op+lean版op（wifi）

才出现这个奇怪的问题

而且出问题的设备基本上都是米家网关和灯

像手机平板笔记本这类东西都没问题

我的情况是，lean OP装在pve虚拟环境中作主路由，pve bridge出来接交换机，接AP（普通路由器），也是某些设备无法申请到IP，WiFi association 阶段是可以过的，抓包发现OP发出的dhcp offer、dhcp ack等包根本无法发出OP（在pve bridge中dump的包），确定了OP设置的问题。

同时，pve中还有另外一个隔壁家的lede，替换掉Lean OP，没有任何问题，对比lede与OP的设置发现，OP使能了FullCone NAT，关闭后，dhcp offer包可以正常发出，问题解决。我这边也是有线设备正常，WiFi AP下设备异常，猜测是Linux FullCone实现不够完美，UDP广播包在穿越多级交换后到达Linux Kernel，FullCone之后的包，出不去Linux Bridge，链路比较复杂没有去细究了。

以上，供您参考。

细看了一下您的情况，好像不太一样，你不是申请不到IP，是反复申请，怀疑还是LAN中有2个DHCP Server。

我在ros 有3个段的ip 刚才测试了一下把有问题的设备调到 1段就没有这个问题调回原来的ip段就这样我感觉好迷茫