Difference between revisions of "Mesh/Firmware"

Mesh/Firmware (view source)

Revision as of 04:45, 2 July 2015

1,722 bytes removed , 04:45, 2 July 2015

no edit summary

Juul

Bureaucrats, Administrators

892

edits

@@ Line 32: / Line 32: @@
 * Support TDMA on Linux (Adri is working on FreeBSD support, maybe we can port).
-= Firmware generation features =
-It should be easy to generate a new firmware with the following custom config:
+= Stuff we are working on =
-*Location and ownership information.
-:Contact info should be saved in a secure database but maybe not on the node itself?
-*Randomly generated passwords set for wpa2, admin interface and ssh.
-:The SSH password should be stored securely and a couple of stickers with the wpa2 and admin password should be printed for the user.
-*Web interface
-*ssh key generation
-[http://meshkit.freifunk.net/ Freifunk Meshkit] is pretty neat!
-We'll be dividing the image generation and node configuration aspects into two parts.
-[https://github.com/sudomesh/sudowrt-firmware Sudomesh Firmware Image Builder Github Repo] has our image builder and
-[https://github.com/sudomesh/makenode Sudomesh Node Configurator Makenode Github Repo] is our node configurator.
-[https://github.com/sudomesh/sudowrt-packages Sudomesh OpenWrt Packages] has all of the sudomesh openwrt packages that we're using/we've written.
-We flash nodes with the sudomesh image and then we use the makenode to set them up with networking configs, ssh keys, etc. We also use makenode in conjuction with meshnode-db to write pertinent info to a database.
-Status:
-Pretty much finished! We're testing the last few issues!
-= Stuff the firmware should have =
 <big>Ranked from most to least important</big>
@@ Line 88: / Line 61: @@
 [[User:maxb|maxb]] has implemented a MVP of this. Chris (snake_wrangler) is working on polishing, etc. it.
-== SSH server ==
-The SSH server should be contactable from any interface. It should initially allow root access using a random generated password that the mesh group has and that the node owner can get and change if they are so inclined.
-Status: Implemented. Mostly openwrt stock but we've added keygen features for the node-configurator
 == Extender node firmware ==
-We want to have a fairly simple extender node firmware that we can just flash to any openwrt compatible device and have it be able to be plugged into our routerboard and be a sudomesh radio which will be bridged. That way, the only routing that needs to take place will be on the routerboards.
+See the [[Technical Overview]] to learn about home nodes and extender nodes.
-We've developed [https://github.com/sudomesh/notdhcp notdhcp], which will allow a routerboard and extender node to negotiate a connection/configurations.
-One thing is that we'll likely want to target a variety of hardware (if not chipsets), without having to run any sort of makenode after the firmware has been flashed.
+With the extender node firmware we're targeting a variety of hardware (if not chipsets), and we don't want to run any sort of makenode after the firmware has been flashed.
-A good example of how this could be done is by creating a /file/etc/uci-defaults script which will run first boot and can set configs depending on the "board" type:
+We're doing this by creating a /file/etc/uci-defaults script which will run first boot and can set configs depending on the "board" type:
 [https://gist.github.com/max-b/97bd7d59259cfbdfbbb2 uci-defaults script gist]
 == Mesh Protocol ==
@@ Line 118: / Line 81: @@
 == Multiple virtual network interfaces with their own SSIDs ==
-*One ad-hock mode, unencrypted interface for the mesh nodes, e.g. sudomesh-backchannel
+*The Mesh interface: An ad-hock mode, unprotected interface for the mesh nodes to talk to each other with Babel handling routing, ssid: pplsopen-node2node
-*One access point mode, unencrypted interface, for non-mesh devices to connect to the mesh, e.g. sudomesh.
+*The Open interface: An access-point-mode, unprotected interface, for non-mesh devices to connect to the mesh, ssid: peoplesopen.net
-*One access point mode, private interface with WPA2, for the people who own the nodes. [optional]
+*The Private interface: An access-point mode, private interface with WPA2, for the people who own the nodes, ssid: Decided by node owner
 Traffic on the private interface should be completely separated from traffic on the non-private interfaces unless a client connected to the private interface requests an IP on the mesh.
@@ Line 213: / Line 176: @@
 Here is our [[Mesh/Network_topology|Network Topology]].
-== Mesh VPN ==
+== Mesh VPuN ==
-If the mesh does not see any other nodes (and maybe even if it does?), and it has internet, then it should connect to another node or two over VPN. The easy solution is to use the same VPN servers as for the internet.
+If the mesh does not see any other nodes (and maybe even if it does?), and it has internet, then it should connect to another node or two over a [[VPuN]] server. The easy solution is to use the same VPuN servers as for the internet connection.
 [[Mesh/Network_topology|Network Topology]]
 Status: Implemented
 == Location and status reporting ==
@@ Line 242: / Line 204: @@
 == Intelligent Wifi Channel Switching ==
-It would be nice to be able to have the network intelligently determine channels
+It would be nice to be able to have the network intelligently determine channels but we don't want a node changing channel if it means other nodes connected to it will have to change as well so it may make sense to only set the channel once on first boot based on which channels have other nodes.
 == IPv6 support ==
-We should have IPv6 support, but I am ok with launching the mesh with only IPv4 and adding in IPv6 later. ([[User:Juul|Juul]] ([[User talk:Juul|talk]]))
+We should have IPv6 support, but I am ok with launching the mesh with only IPv4 and adding in IPv6 later. We can do without IPv6 but not without IPv4 ([[User:Juul|Juul]] ([[User talk:Juul|talk]]))
 = Stuff the firmware could have =
@@ Line 286: / Line 248: @@
 The MyNets are no longer in production, but the TL-WDR4300 are the exact same board, just with external antennas.
-Then we can use "extender nodes" which can basically just do wifi and bridging. This would be basically any router which supports openwrt. We'll probably begin by targeting a variety of ubiquiti long-distance high power radios (Nanostation M line, Bullet M line, Picostation M line, Nanobridge/beam/etc).
+Then we are using [[extender node|extender nodes]] which plug into the home node and just bridge/forward traffic. This could theoretically be any router which supports openwrt. We've begun by targeting a variety of ubiquiti long-distance outdoor radios (Nanostation M line, Bullet M line, Picostation M line, Nanobridge/beam/etc).
-Really the extender nodes are just doing dumb bridging. The only reason we want them to run openwrt is so that they can do some fancier address assignment with [https://github.com/sudomesh/notdhcp notdhcp] and have some nice UI features. We could actually setup something like 2 ends of an airfiber and just configure them the way we want (wouldn't need the dynamic features of notdhcp).
+We would also like to support non-openwrt routers (like Ubiquiti Airfiber and Nanobeam 802.11ac devices) but these will only be able to extend one of the three networks (Mesh, Public or Private) and will need to use WDS mode to do so (at least for Mesh).