We're pretty close to a version 0.0.1 of the node-configurator stack. I'm hoping that Rhodey and myself can finish it over the next 3-4

On Thu, Oct 24, 2013 at 8:46 AM, Mitar &lt;mitar(a)tnode.com <mailto:mitar@tnode.com>> wrote: Hi! I remember you had some discussion about how to flash routers. I think there are several options: - having a generic firmware you configure by hand/webinterface - having a image generator which generates image with all configuration included for a particular node - having an generic autoconfiguring firmware, which - does everything by itself - optionally fetches additional/configuration data from the network/central server - registers at first boot with networks/central server We are working on a two-part solution: 1. A script that makes it super easy to bulk-flash ubiquiti routers with a single firmware. We only have a script that uses the TFTP method, but I'll make the script attempt to flash via the web interface first, and then use the tftp method as a fallback. 2. A node-configurator daemon. Nodes look for this on the local network on first boot (actually every boot until they've been configured) and connect. The node-configurator is controlled via a web interface that talks to the server in real time using websockets. So you just go to the website, using a laptop or smartphone, and wait for one or more nodes to pop up in the list as they boot and connect to the configurator server. Then you fill out a few essential pieces of info and the configurator sends that + secure ssh keys and a few other essentials to the node. The idea is that first boot happens on sudomesh's LAN, not on the mesh, so the nodes are fully configured before they are shipped. Initially we were going to flash each node with its individual pre-configured firmware, and we may still add that feature into the node-configurator (by scanning the LAN for nodes with port 80 open running known web admin interfaces), but for now we will have dedicated flashing-sessions where we focus on just getting the firmware on to the devices in bulk, and then we can configure and upgrade the firmware from the node-configurator before shipping. Flashing used routers unfortunately means that we often have to use the TFTP method, since the settings have been changed from the defaults. We're pretty close to a version 0.0.1 of the node-configurator stack. I'm hoping that Rhodey and myself can finish it over the next 3-4 days. We'll probably re-use parts of this to create the in-field update functionality. A lof ot our choices in the next few weeks hinge on whether or not we want to support devices with 4 MB of flash memory, since that would mean using squashfs which basically required us to reflash the devices for any non-trivial updates. If we use jffs2, then we'd almost certainly need more than 4 MB of flash, but we'd be able to continually update most things without requiring a reflash and reboot. Limiting ourselves to 4 MB and in-field reflashing has the following against it: 1. If in-field re-flashing fails then recovery means physically replacing the node. 2. The node will be down for minutes while it re-flashes. 3. Re-flashing requires enough free ram for the entirety of the new firmware (e.g. 4 MB free at all times) effectively reducing the amount of ram we can use at any time by 4 MB. This may not be a problem since Attitude Adjustment basically dropped support for 16 MB ram devices. 4. Fitting everything into 4 MB of flash is somewhat limiting and annoying to deal with. We'd be sacrificing precious developer time in order to support slightly cheaper routers. It seems silly that we have to worry about 4 MB vs. 8 MB flash in 2013. If we knew for certain that all devices coming out starting e.g. next year were at least 8 MB, then the solution would be obvious, but I don't know the industry well enough to say either way. The only device we're looking to support that has 4 MB of ram is the TP-Link WRT-703N. It has 32 MB of ram, so not a problem for Attitude Adjustment. It has host-mode USB, so it would be pretty simple to simply add a usb memory stick for an additional cost of ~$2.50, which would give them 256 MB of flash and open up some other exciting opportunities. I guess I'm pretty much saying: Let's set our minimum specs at 8 MB flash and 32 MB ram, use jffs2 and see where it takes us. Am I missing any? Some possible relevant links for flashing and ideas: - https://github.com/battlemesh/openwrt-config-system - https://dev.wlan-si.net/ticket/1135 - https://dev.wlan-si.net/ticket/654 - https://dev.wlan-si.net/ticket/1153 Some ideas we were playing around as well: - a phone app which you install, connect to the existing original wireless network of the node you want to flash, press a button and it flashes Interesting idea! - entering your public IP of your home router you want to flash and some server flashes the node for you over the Internet Huh? Is this even possible? Is the web interface enabled on the public-facing side of ubiquiti nodes per default? -- Marc _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh

On Thu, Oct 24, 2013 at 8:46 AM, Mitar &lt;mitar(a)tnode.com&gt; wrote: think configuration We are working on a two-part solution: 1. A script that makes it super easy to bulk-flash ubiquiti routers with a single firmware. We only have a script that uses the TFTP method, but I'll make the script attempt to flash via the web interface first, and then use the tftp method as a fallback. 2. A node-configurator daemon. Nodes look for this on the local network on first boot (actually every boot until they've been configured) and connect. The node-configurator is controlled via a web interface that talks to the server in real time using websockets. So you just go to the website, using a laptop or smartphone, and wait for one or more nodes to pop up in the list as they boot and connect to the configurator server. Then you fill out a few essential pieces of info and the configurator sends that + secure ssh keys and a few other essentials to the node. The idea is that first boot happens on sudomesh's LAN, not on the mesh, so the nodes are fully configured before they are shipped. Initially we were going to flash each node with its individual pre-configured firmware, and we may still add that feature into the node-configurator (by scanning the LAN for nodes with port 80 open running known web admin interfaces), but for now we will have dedicated flashing-sessions where we focus on just getting the firmware on to the devices in bulk, and then we can configure and upgrade the firmware from the node-configurator before shipping. Flashing used routers unfortunately means that we often have to use the TFTP method, since the settings have been changed from the defaults. We're pretty close to a version 0.0.1 of the node-configurator stack. I'm hoping that Rhodey and myself can finish it over the next 3-4 days. We'll probably re-use parts of this to create the in-field update functionality. A lof ot our choices in the next few weeks hinge on whether or not we want to support devices with 4 MB of flash memory, since that would mean using squashfs which basically required us to reflash the devices for any non-trivial updates. If we use jffs2, then we'd almost certainly need more than 4 MB of flash, but we'd be able to continually update most things without requiring a reflash and reboot. Limiting ourselves to 4 MB and in-field reflashing has the following against it: 1. If in-field re-flashing fails then recovery means physically replacing the node. 2. The node will be down for minutes while it re-flashes. 3. Re-flashing requires enough free ram for the entirety of the new firmware (e.g. 4 MB free at all times) effectively reducing the amount of ram we can use at any time by 4 MB. This may not be a problem since Attitude Adjustment basically dropped support for 16 MB ram devices. 4. Fitting everything into 4 MB of flash is somewhat limiting and annoying to deal with. We'd be sacrificing precious developer time in order to support slightly cheaper routers. It seems silly that we have to worry about 4 MB vs. 8 MB flash in 2013. If we knew for certain that all devices coming out starting e.g. next year were at least 8 MB, then the solution would be obvious, but I don't know the industry well enough to say either way. The only device we're looking to support that has 4 MB of ram is the TP-Link WRT-703N. It has 32 MB of ram, so not a problem for Attitude Adjustment. It has host-mode USB, so it would be pretty simple to simply add a usb memory stick for an additional cost of ~$2.50, which would give them 256 MB of flash and open up some other exciting opportunities. I guess I'm pretty much saying: Let's set our minimum specs at 8 MB flash and 32 MB ram, use jffs2 and see where it takes us. Interesting idea! some Huh? Is this even possible? Is the web interface enabled on the public-facing side of ubiquiti nodes per default?

I can take a look through this. I have a build configuration set up on my machine, but I suppose it might make the most sense to set it up on one of the VPS hosts? On Fri, Oct 25, 2013 at 5:50 PM, rhodey &lt;rhodey(a)anhonesteffort.org&gt; wrote: _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh