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.
Had we set our 0.0.1 deadline for this week or next?
Either way, I'm planning to make my way over to Sudo in a couple hours
and would like to
into the early morning hours if anyone
else is willing to join.
-- rhodey
On 10/24/2013 03:29 PM, Marc Juul wrote:
On Thu, Oct 24, 2013 at 8:46 AM, Mitar
<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