LUGRo-Mesh Forum (español/english)

The Nightwing Firmware => Howtos / Documentation => Topic started by: JulioCP on May 01, 2008, 05:21:52 pm

Title: Nightwing Firmware Characteristics
Post by: JulioCP on May 01, 2008, 05:21:52 pm
Nightwing Firmware Characteristics

Nightwing is based on OpenWRT, a GNU/Linux distribution for embedded devices compiled for Atheros SoC (system on chips atheros) processors.

The software that uses to manage the mesh network is B.A.T.M.A.N., in its version 0.3-beta (compatibility version 5).

It was developed to be used to share one or various internet access, in urban environment, little communities or buildings without the need of a centralized management nor people with big technicals knowledges.

Like is inherent to the mesh networks, it allows the deployment of a system that provides free internet access to an area or community in a collaborative way. The nodes that have internet access, individually spreads the coverage towards the nodes that participate in the mesh, extending the general coverage. The nodes participation can be dynamic, tolerating that they incorporate or get out of the network without disturbing the general functioning (in reasonable limits).

It most significant characteristics are:
Zero-conf: All the interfaces, wireless as wired, are configurated automatically basing it in the MAC address that each router has in its Atheros wifi device. This way, all the Nightwing devices are located in the same channel and with the same essid. They will establish, automatically, a mesh network and will auto-asign their respective roles. It can be the role denominated “Gateway” to whom has its own internet access, or the “Client” mode that will be who contact to a Gateway and increases its own coverage.

VAP (Virtual AP): Besides participating in the mesh, each node provides coverage in its influence area in AP (access point) mode, behaving like a normal Hot-Spot  and allowing to mobile or fixed users to access internet trough an open AP without encryption. In this case, it's possible to connect rapidly from any operative system, and it accessed previous pass for a captive portal that controls the session timing and assigned bandwith to each open connection.
They also provide service trough a second VAP, encrypted with a WPA2 key and that allows using a node in a private environment, also extending the access to the local network where it's connected.

Security: Every node can be connected to a local network (LAN) without compromising its security, meaning that the external users connected to the open AP get completely isolated from the local traffic and vice versa, and between them self.
In the client mode, meaning a node that doesn't have its own internet connection, it works in its local network as a DHCP server and default gateway, configuring automatically the equipments of the local network so they can access to internet the same way that an adsl modem would.

Intelligent functioning
: When a node where connected to the local network and it didn't find access to internet in a local way or though another node, it will not interfere with the previous existent configuration of that local network.

Technicals aspects
The core of the zero-conf functioning of Nightwing is the script /etc/init.d/nightwing. This script, that  auto-executes after the normal boot of OpenWRT, creates and configures the interfaces eth0 (local network), ath0 (open VAP), ath1 (encrypted VAP) and ath2 (mesh in ahdemo mode).

At this point the node must choose its rol, meaning if the interface eth0 got automatically an IP address and its possible to access the internet (ping to various root-servers) the node will pass to Gateway mode. The batmand demon will be executed over the interface ath2, announcing himself as gateway to the rest of the mesh.

When the Nightwing script is executed, the mentioned interfaces will auto-configure from the MAC addresses of the Atheros interface, and they will be in the following subnets:

  • ath0 and ath1 in the subnet 10.x.x.y, where the bytes “x” are obtained from the MAC and the byte “y” results from dividing the address space in three subnets. The third subnet will be used in eth0 like it will be explained.
  • ath2 is configured in the subnet 5.x.x.x, where the last bytes are calculated from the MAC address.
  • eth0 will be configured by DHCP in case the node is connected to a local network that has a server for it (generally an ADSL modem or a cable modem).

Finished the configuration of the local interfaces, it will reconfigure the dnsmasq server so it can offer DHCP and DNS services in the interfaces ath0 and ath1.

If the interface eth0 didn't configure automatically, the node will try to assume the client role by lunching the demon batmand in client mode and waiting to contact a neighbor gateway. In case of doing it, it will reconfigure the interface eth0 with a DNS and DHCP server to serve the local network. If it never contact a gateway, it will remain trying it indefinitely.

If the interface eth0 was configured automatically but didn't get access to the internet, the node will not assume any role at all and will reboot, avoiding interfering with the local network configuration to which is connected to.

If the interface eth0 didn't get automatically an IP address, eg, in the supposed case that the ADSL modem in charge of doing it was out of service; it will assume the client role. But once he reestablish the internet service, it will automatically reboot to assume the gateway role.

Besides, a process in the cron is permanently testing that the gateway nodes remain with internet access, and in the case of losing it, they will reboot automatically to complete a new cycle of role definition.

In order that all the client nodes of the mesh can change of gateway to which associate, all the mesh uses as nameserver the DNS provided by OpenDNS. Which are of free access and allows, if necessary, establish filter content. Feature particularly useful when talking about a public Hot-Spot.