OpenWrt 18.x/19.x and (not too) smart Air Purifier Levoit/VeSync


I have a weird problem with the VeSync app/Levoit wifi-connected air purifier. I just got that thing and the account linking works this way: you first connect from the VeSync app to the device to let it know the WiFi settings and then (as I surmised) it tries to get onto the WiFi and discover the device on the local network thru the app.

The first part works, but then I'm guessing the OpenWrt firewall gets in the way of things, the app cannot discover the air purifier on the local network and setup stops.

I remember that when I previously struggled with the Chromecast-like devices discovery, adding iptables -I INPUT -p udp -m udp --dport 32768:61000 -j ACCEPT to /etc/firewall.user helped. Neither keeping that, nor commenting it out helps with the air purifier.

I'm looking for an educated guess what may need to be added to firewall/iptables to let me overcome current problem.

I have this same air purifier (lots of smoke from the wild fires in Northern CA). I have an IoT network and UPnP enabled, so it just works (this is running through an EdgeRouter X with EdgeOS). If you happen to know how I can query EdgeOS's UPnP ports, I can probably get you the specific info about the port(s) you need to open.

I think the relevant UPNP rules/ports should show up in the UI around UPNP section. If there are multiple ports/rules then you may need to identify the relevant one with air purifier.

On EdgeMax 1.10.10, UPnP doesn't have a pretty UI associated with it -- to enable it (via the web UI), you must go through the config tree. So there isn't a place (that I can find) to see the actual UPnP port status.

I'm sure there is a command line option for it, but I have never tried.

If that's the case then you can try searching for it. Google may belp.

For edgemax,I did find this

show upnp2 rules

But it comes up empty. I can't find any other places to get active UPnP ports, unless maybe this isn't actually using UPnP after all.

Thanks for the suggestions gentlemen, my upnp config is pretty restrictive, I'll see what happens when I open it up a bit.

In a standard configuration, the traffic between devices in the LAN does not move across the router's CPU, so there is no firewall involved.

On the other hand, you could have enabled "client isolation" on the wifi interface, and wireless devices will not see each other.

Also, if you happen to own a router with a mwlwifi chipset (Linksys WRTxxxx), you must know that this device is notorious for having issues with many IoT devices (specifically with the ESP 8266 chip).

1 Like

Without knowing anything about the particular device in question, I doubt it needs a UPnP configuration. The whole concept of "cloud-based" stuff usually is that the IoT devices themselves keep a semi-permanent connection to the command-and-control servers of their manufacturers (from the inside, polling the external servers), for the very simple reason that this traffic basically isn't possible to filter (unless you go extremely paranoid/ strict), while incoming traffic is almost never possible to allow for mere mortals[0]. Aside from games[1], VoIP/ SIP[2] is one of the few 'common' protocols that do require port forwardings[3].

The issues raised by eduperez are more likely to be involved in this problem.

[0] aside from very motivated target audiences, like gamers, or advanced users intentionally wanting to operate server features.
[1] latency is king, so polling isn't sufficient.
[2] for the same latency reasons and the unpredictable nature of incoming calls.
[3] in practice normal users won't have to set this up either, because either their all-in-one VoIP capable router does it for them, or because of their SIP client does the only sensible thing in NAT envionments, keeping the connection open from the inside via regular SIP pings (hole punching through the conntrack table).

I know that the device is cloud connected because I can control it via any network, including cellular(I do not need to be on the same lan). So it most certainly passes through the routing layer.

That said, it is reasonable to assume that the device initiates the connection to the server and continually keeps it alive so that it ‘just works’

Yes, I agree. I do not think any consumer device expects to be able to open ports using UPnP or have the user open them.

Well, definitely not a upnp issue. I've tested with upnp open to all local devices on all high ports and it didn't help.

It is the WRT3200ACM and when reverted to stock Linksys firmware on one partition the setup completed without issues. However when I boot back to OpenWrt, Air Purifier fails to connect to WiFi. I've tried playing with settings, nothing seems to help. If anyone has any ideas I'd be much obliged:

config wifi-device 'radio1'
        option type 'mac80211'
        option hwmode '11g'
        option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
        option txpower '30'
        option legacy_rates '0'
        option htmode 'HT20'
        option channel '9'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option key '***'
        option legacy_rates '0'
        option wps_pushbutton '0'
        option ssid '***'
        option wpa_group_rekey '0'
        option wmm '0'
        option encryption 'psk-mixed+tkip+ccmp'


I have never seen this before. Well I have seen it now even in my router. :smiley:
Anyway, have you tried changing the security settings on your router? Maybe something wrong/incompatible there?

some drivers hardcode such a setting? we had troubles setting up a smart bulb via ea3500 router using 3 different android devices. in the end created hotspot on the phone and set it up that way. first time it just worked with archer c7 and tablet

Do you have any adblockers, pi-hole type setups, or other firewall restrictions that might come into play here?

IoT devices cannot connect to the WRT3200ACM, period. See this issue for further info and a possible solution:

On the WRT3200ACM, the third radio (mwifiex_sdio) might actually be more compatible than the two main mwlwifi ones. I'd suggest to try using that with a different ESSID/ PSK first.

1 Like

Decided to experiment with radio2 like suggested and either it's the radio issue or (more likely) it's that the Air Purifier doesn't support encryption='psk2+ccmp', it works fine with encryption='psk2' tho.

Here's the full config of radio2 which results in working air purifier:

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.