AirJaldi Mesh Router

Air Jaldi Mesh Router (AJMR) Technical Description

The AJMR is built around a SBCs (Single Board Computers) which we extract from low-cost popular WiFi devices such as Linksys’s WRT54G.
While most of the SBCs we use, utilizes a 200mhz MIPS CPU with 4Mb of Flash memory and 16Mb of RAM, we also use much lower-scale units and recently also more powerful units. We find the Netgear WGT634U, to be most suitable for our application and we are happy to see a constant decrease in it’s price. This small SBC draws less power then its bulkier cousins, features a MiniPCI slot for radio card, hosting a great Atheros b/g radio, double the flash and ram of the WRT54G and maybe the greatest feature of all is a USB2.0 port.
Most of our current development is based around this unit.

The SBCs are enclosed in a low-profile, weather-proof enclosure which was designed in Dharamsala and is being furbished in Delhi. The present enclosure is the 3rd version, designed based on field experiments in the harsh Himalayan climate. It had proved to stand the extreme cold and snowy winter, the heavy monsoon rains, and the scorching sun of summer heat. Manufacturing costs for the enclosures are just a bit over $10, for the small quantities which we make. We expect to lower the price much more once higher volumes will be produced.

The SBCs also undergoes some Hardware modifications and additions in Dharamsala:
Power supply integrated with a POE (Power Over Ethernet) injector, which allows for long-distance PoE feeds.
Tolerant power-supply for wide-range input voltage 90-240v.
Current-limited battery charger (best results with 12v 7.2Ah dry cells).
Low-voltage disconnect (LVD), to prevent router hung if battery is depleted and to prolong battery life.
Optional solar-powered battery chargers.
Improved antenna feed system, to decrease RF transmission losses.
Optional sensors for remote monitoring, graphing, and logging of temperature and voltage.
Optional lightening surge protector for antenna feed.
Optional lighting surge protectors for Ethernet feeds.

The router’s firmware (operating system) is a Dharamsala-brewed Linux clone, based on multiple open-source projects. Thanks to the amazing and promising development of OpenWRT project http://www.openwrt.org/ we now need very little additions of our own. The OpenWRT project’s contribution to our work has been priceless – thank you guys! The core of OpenWRT is based on http://uclibc.org and http://www.busybox.net/. With so many supporters and contributors, today one can find a very rich selection of pre-compiled packages and tools, hence allowing the people on the ground to focus on local issues, while enjoying pre-tested and fully functional OS.

Multiple Mesh routing protocols where tested and are supported optionally. A locally tweaked OLSR had become the protocol of choice for the present mesh.

Major development efforts are aimed towards prevention of wireless transmissions collisions a.k.a “hidden node problem”. At present an iptables queue is controlling transmissions based on an advanced token-passing protocol among the mesh members. This technique, while increasing latency, prevents radio collisions and therefore provides a network free of packet-loss even when radio links quality is very poor. The concept idea and much of the development efforts are coming from “Frottle” http://frottle.sourceforge.net/ and the great guys at http://www.melbournewireless.org.au/. While we feel that such a solution is essential for the scalability of WiFi based networks, the present implementation is extremely difficult to tune in Mesh environments, hence we where forced to give-up on it’s use for most of our network. We feel that a complete re-write is called for, focusing on tight integration into OLSR, possibly an OLSR plugin. We hope to focus much of our future development efforts to produce a field-tested “Mesh frottle” solution.

Running a later Linux Kernels (2.4.30 and also 2.6) the units supports all the advanced networking elements which are critical for deployment of such an advanced network:
• Full iptables stateful firewall, including all forms of NAT, traffic shaping, QOS management, packet tagging and even latest Layer-7 classifiers.
• Policy routing (iproute2) is included along with “tc” and multiple supported queues.
• Tcpdump – packet sniffer for network debugging.
• Arptables – for L2, MAC filtering and Linux-bridge for L2 bridging support.

The unit support SNMP for remote management, NTP for maintaining accurate network-time (critical for encryption) and remote syslog host support, for concentrated logging.

Encryption is done using the on-board hardware accelerator and supports both 128bit WEP and WPA protocols for wireless encryption. An optional OpenVPN (www.openvpn.net) package can be included, which turns the unit into a military-grade VPN tunnel end-point. Since OpenVPN encryption can only be done in software, the unit cannot handle high-speed encrypted data. It is however sufficient for most low-speed (less then 1mbps) WAN applications.

The units also provide DNS and DHCP servers, with support for multiple (up to 5) physical LANs (can be extended up to 256 LANs, using VLAN tagging and matching L2 switching devices).
Fixed (MAC Based) and/or dynamic address allocation.
Optional PPPoE support can be used if interface to ADSL or similar line is needed.
A shrink Asterisk VoIP software PBX can be installed on the unit, allowing support for a small number of IP-phones or ATAs. We feel that tight integration of telephony applications will be essential for future deployments in rural areas and developing countries. It is planned to port the existing firmware to run on devices which include ATA (Analog Telephone Adapters) within the same SBC, to further reduce the overall cost of telephony systems deployments in rural areas.

At present, all management is done using remote SSH access. No GUI is offered at this point. In general, all configuration and management of the unit is done using unix command shell, and basic knowledge of Linux is needed to manage the device. There is hardly any documentation at this point, and many future efforts should be focused on ease of management, configuration and control, along with in-depth technical documentation.