That said, I have a few observations I thought would be worth bringing up:
1) WPS setup did not work for my Wifi attachment. I tried both using the button and the "wps" command via serial. I see that the app is there (though not named just "wps_app"), but I'm not sure how to make it run. (The LEDs never blinked differently, which I understand to be the indication of being in WPS setup mode.)
2) After deciding that WPS wasn't going to work, I looked at using the wifi setup wizard. Unfortunately I couldn't find it. I'm sure it wouldn't be an issue if I were on windows, but I'm not sure where to find it for use in linux.
3) I skipped the WifiSetup arduino sketch and went right to manual configuration over a serial line. FYI, my Wifi Attachment came preconfigured for 57600 baud, as opposed to the 9600 indicated in the Wifi Attachment manual. I was really confused why nothing was working until I tried that
When I saved the settings the device indicated that there was a configuration issue, however after reboot it connected to my access point without incident...
Most importantly:
4) I think there are some serious security issues with using port forwarding to make these devices accessible from outside. It took me exactly one try to crash my controller from outside my home network. I'm relatively sure there is not a good way to protect against the particular type of attack I tested. I think adding the access credentials (as was done very recently) is a good start, but not an effective solution for the long term.
As a possible solution, I propose switching to either frequent polling or, ideally, long-polling from the embedded device to the "real world".
Upsides:
- No need for port forwarding (easier setup!)
- Don't care about dynamic addresses (easier setup!)
- Not possible for an attacker (or accident) to crash the controller from outside the home network
Downsides:
- Requires an outside server for remote connections, rather than allowing for direct connections from mobile devices
- Slower response time when given commands from mobile devices or the Portal
I think with a proper implementation this would be almost imperceptibly slower than using direct connections, and would be a lot safer with a lot less hassle.
With the remote server source code distributed openly, this would allow for a single central server that could be used, or for individuals to run their own outside access if they are so equipped. It could even be integrated seamlessly with the Portal (either directly, or as a proxy of sorts).
As long as the mobile clients and Portal supported it, this scheme could be used alongside the existing topology without an issue. Users could choose which firmware to build.
I plan on doing this for myself regardless of feedback here. However, I'm hoping to gauge interest and hopefully have something that everyone can benefit from.
Thoughts?
Thanks,
-Matt
)
