IOT / ESP8266 stuff and multiple access points

Forums › LAN (ethernet/Wifi/routers/Bluetooth) › IOT / ESP8266 stuff and multiple access points

mdf

2331 posts

Uber Geek

Trusted

Subscriber

# 255674 23-Aug-2019 11:30

I have multiple access points for my wifi network - Cambium E400s in my case with an EdgeRouter Lite. I have had all sorts of issues in getting various IOT stuff onto my wifi. This has included bulbs (LIFX), controllers (Broadlink) and actual ESP8266 boards (Wemos). I have usually managed to get there in the end, but recently everything got kicked off and I could not get them back on.

There seem to be hints on the internet that others have had similar problems, but not necessarily definitive solutions.

After much cussing, I may finally have cracked it and sharing here to maybe help others avoid my pain. I'm not sure if this is unique to Cambium APs (or perhaps even the ERL), but the internet seems to hint that it is possibly more to do with invariably cheap wifi chips (perhaps even ESP8266s) that find their way into IOT stuff. Someone that knows more about wireless networking than me (i.e. something that knows anything about wireless networking) might be able to chime in with whys, wherefores and whether it is unique to my set up or not.

For my set up, I have managed to get reliable results with:

Client isolation OFF (yes, I know that now)
Proxy ARP / respond to ARP requests on behalf of clients OFF (thanks @rphenix)
Using different SSIDs for each AP

That last one is the latest development and took me by surprise when it actually worked. I could see in the logs that the IOT device would attempt to connect, then shortly after get booted off for "disconnect-info code=8". I couldn't find that code on anything Cambium related, but Ruckus suggests that "Reason Code 8 is due to client leaving the BSS by means of AP moving the client to another access point using non-aggressive load balancing".

I'm not really sure what that means, and I didn't want to muck around with the roaming settings in my APs. The entire point of them is that we get wifi around the house seamlessly. However for me, I was able to set up another WLAN just for IOT stuff and then set a different name for that WLAN SSID on each access point (Cambium's cloud management solution lets you do this easily enough once you find the setting). None of the IOT stuff is intended to move around the house, so tying them to a single AP shouldn't matter.

Only 24 hours in so far, but managed to get everything to connect first try (compared to dozens of failed efforts previously) and everything seems solid so far.

hio77

'That VDSL Cat'
11062 posts

Uber Geek

Trusted

Spark

Subscriber

# 2304536 23-Aug-2019 12:04

I run ESP8266's on my E400s perfectly fine, never have an issue.

I have client isolation On, Proxy ARP On, Single SSID across all AP's for HAB (Routed vlan)

No roaming turned on on that SSID.

I did have issues with drops for awhile, they seem to all center back to Breadboard links rather than actually the network - The ones that sit in my Rack run for months on end without needing a reboot.

#include <std_disclaimer>

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.

davidcole

4533 posts

Uber Geek

Trusted

# 2304547 23-Aug-2019 12:15

2 people support this post

Aren't ESP8266's generally installed in a static location, so roaming shouldn't be an issue.

Previously known as psycik

OpenHAB: Gigabyte AMD A8 Brix, OpenHAB with Aeotech ZWave Controller, Raspberry PI, Wemos D1 Mini, Zwave, Xiaomi Humidity and Temperature sensors and Bluetooth LE Sensors
Media:Chromecast v2, ATV4, Roku3, HDHomeRun Dual
Windows 10 Host (Plex Server/Crashplan): 2x2TB, 2x3TB, 1x4TB using DriveBender, Samsung 850 evo 512 GB SSD, Hyper-V Server with 1xW10, 1xW2k8, 2xUbuntu 16.04 LTS, Crashplan, NextPVR channel for Plex ,NextPVR Metadata Agent and Scanner for Plex

hio77

'That VDSL Cat'
11062 posts

Uber Geek

Trusted

Spark

Subscriber

# 2304555 23-Aug-2019 12:23

davidcole:

Aren't ESP8266's generally installed in a static location, so roaming shouldn't be an issue.

With the way many of the AP's these days work in some of their autonomous modes, they can change their power down and thus cause a roam event to happen...

#include <std_disclaimer>

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.

mentalinc

1752 posts

Uber Geek

Trusted

# 2304579 23-Aug-2019 13:14

I had the issue (may still do) where they would only connect to the AP they first joined when they booted up.

Ie. move to the other end of the house and they wouldn't join the closer AP.

Will try the above (but not writing different code for different AP SSIDs depending on where they are physcially lotcated.

I have a seperate Automation SSID, but it has the same name on both APs per the above...

CPU: Intel 3770k| RAM: F3-2400C10D-16GTX G.Skill Trident X |MB: Gigabyte Z77X-UD5H-WB | GFX: GV-N660OC-2GD gv-n660oc-2gd GeForce GTX 660 | Monitor: Qnix 27" 2560x1440

richms

22533 posts

Uber Geek

Trusted

Subscriber

# 2304581 23-Aug-2019 13:21

One person supports this post

All my ESP8266 stuff seems to be fine on my unifi gear. Sometimes will see one connected to an AP not too close to itself, but still with -70 or so signal and working. Eventually will move to a closer AP but I think its trying to limit the number of clients on one AP since the closest to that room would have 40+ things on the iot vlan SSID.

Richard rich.ms

chevrolux

4212 posts

Uber Geek

# 2304641 23-Aug-2019 13:50

I think it depends on the code they are running too. I run lots of wemos d1 mini's with ESPeasy, and they seem to like to lock to a specific AP based on MAC regardless of where I move them to.

Whereas the Sonoff's running Tasmota will happily roam to other AP's based on signal strength alone.

mdf

2331 posts

Uber Geek

Trusted

Subscriber

# 2304646 23-Aug-2019 13:58

Just to be clear, (almost) all my problems relate to getting IOT stuff to acquire an initial IP address. The Lifx bulbs, for example, took an age to set up initially but once successfully connected to the wifi were solid for the last year or so.

But once they did lose the connection, there was nothing I could do to get them back on to the wifi. I could see them attempting to connect but then never get an IP and the setup would eventually time out.

Following @mentalinc's post (and others - cheers), I'm now wondering whether it might have just been connecting to a "new" SSID name (the renamed network on the single AP) that might have helped? I did repeatedly reset them but maybe not all resets are created equal?

BarTender

2858 posts

Uber Geek

Trusted

Lifetime subscriber

# 2304789 23-Aug-2019 15:51

I have an IoT SSID that is only provisioned to one AP and I never have issues with any of the ESP8266/ESP01 devices connected to it. I have 2 APs covering my whole house with 2 other SSIDs being used for Family/guest networks.

If I had the sorts of issues you are talking about yes I would provision additional SSIDs on the other AP (IOT1 / IOT2 etc), or another option would be to enable MAC address authentication on your IOT network and point to a Radius server (FreeRadius) for authentication so that MAC Addresses of IOT devices are married to MAC addresses of APs. That could create issues with when the device attempts to connect to the other AP and gets rejected, but I would think that most devices would recover from that.

It's how I setup Chromecasts for a friend of mine using MAC address auth so the Chromecast only attaches to a dedicated AP.

hio77

'That VDSL Cat'
11062 posts

Uber Geek

Trusted

Spark

Subscriber

# 2304790 23-Aug-2019 15:53

BarTender:

If I had the sorts of issues you are talking about yes I would provision additional SSIDs on the other AP (IOT1 / IOT2 etc), or another option would be to enable MAC address authentication on your IOT network and point to a Radius server (FreeRadius) for authentication so that MAC Addresses of IOT devices are married to MAC addresses of APs. That could create issues with when the device attempts to connect to the other AP and gets rejected, but I would think that most devices would recover from that.

Because it's really a good idea to let you play with radius!...

#include <std_disclaimer>

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.

BarTender

2858 posts

Uber Geek

Trusted

Lifetime subscriber

# 2304801 23-Aug-2019 16:45

hio77: Because it's really a good idea to let you play with radius!...

FreeRadius makes EVERYTHING better.

richms

22533 posts

Uber Geek

Trusted

Subscriber

# 2304861 23-Aug-2019 17:29

Ive had similar problems on initial setup but it seems that it was the app discovering the device failing, not the device getting online. The phone had to be in the same /24 range as the device it was setting up to find it, even tho the network is a /22 to allow for enough addresses. I ran into the problem when my DHCP range which was n.100 - n+3.100 finally rolled over to the 3rd range, but the phone still had an ip from the second range. Seems that magighome and ewelink dont understand subnets and assume only the final octet will be differerent in their discovery phase.

Richard rich.ms

Tinkerisk

749 posts

Ultimate Geek

# 2305534 24-Aug-2019 23:13

Setting RSSI to -40dB on all APs (rooming enabled) should do the job.

- ISP1: T-OneBox FTTH modem, 1/.5G, full DS, VLAN7, VoIP + ipTV streaming flat

- ISP2: 4G/LTE USB modem + TL-MR3020, 100/40M data plan (wireless fallback)

- NET: ZBOX nano router, 2 C2960X-48TS-L, 2 GWN7630, GWN7610, EL1600usb

- SVR: E3C236 32G/20TB, H2 16G/2TB, 4 HC2 14/4/1/1TB, HC1 1TB, 42 Jetsons

- IoT+3D: LoRaWAN, 5G, CCU3 (openHAB/MQTT), 2 Ender-3, UM2E+, UM3, CNC

- USR: NUC8i7HVK, EliteBook 840, Aspire E5, N2, X300, tablet, mobiles, 2 4K TVs

- ipPBX: GRP2613, GO-Box 100, SPA112 (Fax and W-48, a 1948 Siemens phone)