Posted: Thu May 06, 2021 18:44 Post subject: [SOLVED] Instability with IoT devices (ESP32, Rpi)
New to DD-WRT using the following FW:
DD-WRT v3.0-r40009 std (06/11/19)
on a Netgear R7000P.
I have created a separate network bridge with a VAP to use for my IoT devices, including an ESP32 and a Raspberry PI. This works great for a while, however after 1-2 days it becomes really unstable and Im not able to ping these devices anymore.
br0: General network
br1: IoT network
br2: Guest network
For the Rpi I have a 4G backdoor and can ssh into it, and ping the router interface to get it back again.
For the ESP32 it looks like this, when Im trying to ping it from a host in br0 when it has stopped responding:
Code:
ping 192.168.2.139
PING 192.168.2.139 (192.168.2.139): 56 data bytes
Request timeout for icmp_seq 0
92 bytes from dd-wrt (192.168.1.1): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 47fd 0 0000 3f 01 ae63 192.168.1.109 192.168.2.139
92 bytes from dd-wrt (192.168.1.1): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 2fa0 0 0000 3f 01 c6c0 192.168.1.109 192.168.2.139
Request timeout for icmp_seq 1
If I telnet to the router and ping it from the bridge interface, i can get it to respond again:
Code:
PING 192.168.2.139 (192.168.2.139): 56 data bytes
64 bytes from 192.168.2.139: seq=1 ttl=255 time=5691.435 ms
64 bytes from 192.168.2.139: seq=2 ttl=255 time=4683.283 ms
64 bytes from 192.168.2.139: seq=3 ttl=255 time=3674.759 ms
64 bytes from 192.168.2.139: seq=4 ttl=255 time=2665.544 ms
64 bytes from 192.168.2.139: seq=5 ttl=255 time=1657.094 ms
64 bytes from 192.168.2.139: seq=6 ttl=255 time=648.400 ms
However very high latency.
Then i can get answer on ping again from a host on a different bridge on the network, but very unstable:
Code:
ing 192.168.2.139
PING 192.168.2.139 (192.168.2.139): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
64 bytes from 192.168.2.139: icmp_seq=0 ttl=254 time=2318.266 ms
64 bytes from 192.168.2.139: icmp_seq=1 ttl=254 time=1317.799 ms
64 bytes from 192.168.2.139: icmp_seq=2 ttl=254 time=317.057 ms
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
64 bytes from 192.168.2.139: icmp_seq=3 ttl=254 time=5400.487 ms
This is the Iptables I use on the router:
Code:
# Block access from IoT Network to Main Network. Allow Access from Main Network to IoT Network.
iptables -I FORWARD -i br0 -o br1 -j ACCEPT
iptables -A FORWARD -i br1 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i br1 -o br0 -p udp --dport 5684 -j ACCEPT
iptables -A FORWARD -i br1 -o br0 -m state --state NEW -j REJECT
# Block access to from Guest Network
iptables -A FORWARD -i br0 -o br2 -j REJECT
iptables -A FORWARD -i br1 -o br2 -j REJECT
iptables -A FORWARD -i br2 -o br0 -j REJECT
iptables -A FORWARD -i br2 -o br1 -j REJECT
The bridge table:
Code:
Current Bridging Table
Bridge Name STP Interface
br0 no eth1 eth2 vlan1
br1 yes vlan3 wl0.1
br2 yes wl0.2
Other stuff I have tried without no success:
- Disable the power saving management on the Rpi wifi adapter.
- Tested all different WLAN network modes
- Disabled WMM support
Yes, update to a build from April 2021. Nobody wants to spend time on your problem if it's a problem that has already been fixed in a newer version.
Beyond that, you are going to need to search the forums because many times issues like this are very dependent on the driver used for the radio.
You also should run the manufacturers firmware for a week to test. If the IOT devices remain connected to the wireless transmitter under the manufacturers firmware but not under dd-wrt then that is significant as well.
Yes, update to a build from April 2021. Nobody wants to spend time on your problem if it's a problem that has already been fixed in a newer version.
Beyond that, you are going to need to search the forums because many times issues like this are very dependent on the driver used for the radio.
You also should run the manufacturers firmware for a week to test. If the IOT devices remain connected to the wireless transmitter under the manufacturers firmware but not under dd-wrt then that is significant as well.
Thanks for the answer. I have used a lot of time in searching for this matter, without finding any solutions other than the tips of the power saving on the RPi and the WMM support. So hopefully someone has some other tips or have similar recommandations.
Which FW release do you recommend? I tried some of the latest before installing this version as it was recommended as a stable version. But with the recent versions I experienced a lot of issues with cyclic reboots, and not possible to access the UI.
If you have not already read the forum guidelines, please do !!
I am guessing you have a Marvell router they are known for this problem I think and newer builds have a setting for this (I am not sure I do not have Marvell routers)
If you have not already read the forum guidelines, please do !!
I am guessing you have a Marvell router they are known for this problem I think and newer builds have a setting for this (I am not sure I do not have Marvell routers)
I normally would transfer your post to the right forum so if you let me know what model you have I will transfer it.
Thanks, the model name is already in the post. It is based on Broadcom BCM4365E. Feel free to move to appropriated forum.
So, was able to upgrade to release v3.0-r46604 std without problems now.
After going through all the wireless settings, and setting explicitly all options that was set to auto, Channel, mode, etc. And also regulatory domain, seem to help. Haven't had any instability since.