Moen Flo remote onboarding

Robert Fleming

I had the opportunity to activate/onboard a Moen Flo from afar. This article describes how I achieved this.

This article does not describe any flaw or vulnerability in the Flo, and this process does not depend on any.

This process does depend on a local helper to (1) send a picture of the Flo device's unique QR code, and (2) press the Flo's reset button.

QR code

The QR code is on the Flo unit as well as on a sticker on the retail box. The QR code encodes a string like: 

V:2$I:01234567890ABCDE01234567890ABCDE$E:EDCBA01234567890EDCBA01234567890$

I suppose this is a list of $-terminated name-value pairs, with maybe the abbreviated names short for:

V
version
I
identity of the unit (not obviously related to serial number or MAC address though)
E
enrollment secret

Anyway that's a digression; it's not important for this article. It is, however, necessary to have a picture of the QR code.

Onboarding

Normally the Flo is onboarded locally, following this common sequence:

  1. Install and register/login to the "Flo by Moen" app (for Android or iOS).
  2. Press the Flo device's "reset" button. This causes (1) an LED to flash on the Flo, and (2) the Flo to advertise an unencrypted/open Wi-Fi access point (AP) with a name like "Flo-????". (The "????" is the last part of the MAC address given on the sticker on the retail box, but that's not important.) The flashing LED stops after a while, but if a Wi-Fi client has connected to the Flo's AP, the Flo will not cut it off.
  3. "Add Device" in the app. This will eventually lead to the app asking to:
  4. Scan the QR code.
  5. Scan for and join the local Flo Wi-Fi AP. Maybe the QR code determines what the AP's precise SSID is, I don't know.
  6. Upon successful connection, the Flo device sends the app the list of APs that the Flo can see.
  7. The user chooses the AP and supplies the password.
  8. The Flo connects to the chosen AP, completing the part of the onboarding that normally requires locality.

In this case, I wasn't local to the Flo device, which complicated the above process.

I did, however, have a Linux computer local to the Flo device, with:

  • an unused Wi-Fi adapter,
  • an Ethernet connection for its normal upstream Internet connection, and
  • a NanoKVM in case I broke the Internet connection (I did).

This particular Linux computer used systemd to manage network connectivity (and not, e.g. NetworkManager). So I used the following manual commands to connect the Linux computer to the Flo's AP: 

set dev=wlp7s0
ip link set $dev up
iw $dev scan | grep -i flo
iw dev $dev connect Flo-abcd
dhclient $dev

That dhclient invocation, not surprisingly, creates a new default route table entry, overriding the prior (Ethernet) default (i.e. cutting the computer off from remote access). Via NanoKVM I deleted the new default route table entry: 

ip route del default via 192.168.3.1 dev wlp7s0

This restored my main Ethernet connectivity and preserved the computer's connection to the Flo.

In the absence of IP-KVM, I would have looked into how to prevent dhclient from creating that new default route table entry. I would have done all this in a tmux session, with sleep 60; reboot running in another window, such that the computer would be rebooted (with its default network configuration) had I lost connectivity to it.

Anyway, the Flo's DHCP server assigns an IP address in 192.168.3.0/24, with itself at 192.168.3.1.

At my own location, I had a router running OpenWrt. On that router, I:

  1. created a new unencrypted/open AP, matching the Flo AP's SSID,
  2. changed the IP address of the router's "lan" device to 192.168.3.1, matching the Flo AP, and
  3. issued the following command: 
    ssh -g -L8000:192.168.3.1:8000 my-remote-linux-computer

That ssh command can be done safely using SSH agent forwarding.

Then I proceeded with the Flo by Moen app on the Android device I had with me. For the QR code scanning, I just displayed it on my laptop's screen. The Flo by Moen app didn't know the difference with all this, and got the Flo device online.

In the absence of the OpenWrt router, it probably would have been possible to create the "proxy" Flo AP on one's laptop (certainly running Linux and maybe other OSs).

There are many things that Moen could have done to make this more difficult, even practically impossible. I'm glad they did not, because this got me out of a jam!

P.S. be sure to delete any unencrypted/open APs you create!