I spent the last weeks mainly developing the LuCI Application for VRConfig. As soon as you want to do advanced things with LuCI, it gets cumbersome.
As the API is mostly undocumented, you have to dig through the LuCI’s source code trying out functions which could be useful according to their name.
It’s a bit of a trial and error game.
Currently the LuCI app does the following.
It displays an image of the router and parses the JSON file, which contains the locations of the components.
With this information it can mark the associated physical ports to the currently selected network interface and display those network ports, which are connected to a cable. You can also hover over the components and click on them, which leads you to their respective settings page.
I also improved the annotation app. It now lets you choose the router name from a list of all currently supported router models of OpenWrt. I got that list with a series of grep and sed commands from the OpenWrt git repository.
For your information, there are currently around 1100 different router models supported. 🙂
In the next weeks I will polish the LuCI Application and try to integrate VRConfig into the openwrt build system to be able to select the correct router image and JSON file at build time.
I have some quick updates about VRConfig for you.
Short recap: VRConfig aims to introduce a graphical configuration mode for OpenWrt’s Webinterface LuCI.
For that need to collect pictures of the backside of all supported routers. The idea is to do this in a crowdsourcing manner. The community can submit pictures of their routers together with a metadata file which contains the locations of the components on the picture.
I am Tobias, a Computer Science student at the TU-Berlin. This is my second time participating in GSoC for Freifunk.
I am excited about this project as it helps to reduce the entry barrier for inexperienced users of OpenWrt and its web interface LuCI.
When you look at the current LuCI Webinterface you will notice that it looks fairly decent, especially with the Material Theme.
However for an inexperienced user without a technical background it surely looks scary. All the text full of technical terms with few pictures can look like a book with seven seals.
This project aims to introduce a graphical configuration mode.
To make the configuration interface more connected to the actual router the user owns, we want to display an image of the backside of the ports in the web interface.
The user shall be able to interact with this graphical representation of the router by hovering and clicking on the different parts like LAN ports, antenna etc.
What are the necessary steps to archive this goal?
First, we need pictures of the backside of all the different router models. Here the idea is to collect them via crowdsourcing by the community. Everyone can take a picture of their router and upload it to a Git repository. Also, the location of of the router components must be marked on every picture. For that I will develop a small application which allows the user to annotate a router picture and generates a metadata file.
Second, the annotated pictures need to be integrated into the OpenWrt buildsystem.
Third, a LuCI application needs to be developed to display the result as an interactive graphic in the web interface.
In the next blog post I will go into more detail on the individual steps as well as update you about the progress.
This year, the Google Summer of Code and FreiFunk have given to Guifi.net and QMP communities the opportunity to develope a project in this event. This project is: BGP/Bird integration with OpenWRT and QMP.
A brief description of the project
Most of the community networks run dynamic routing protocols (OLSR, BMX6, BATMAN-ADV, etc.) with non-dynamic ones (BGP, OSPF, etc.). Guifi.net (BGP) and QMP (BMX6) are a scenario where this collision of metrics and routes happens.
Furthermore, these communities are using Quagga for the BGP routing, which is a complex and oversized tool for the type of nodes that will work with it. For these kind of nodes, Bird is a really lightweight BGP daemon that is still not well supported to be used easily by the community (it does not have an easy and graphical configuration system yet).
This project will contribute with:
1st Block: Adapting Bird to fit into QMP firmware. (1 month)
Bird daemon improvements (3 weeks)
Give to Bird integration with OpenWRT: Add support for UCI configuration. Thus, will ease the configuring process and become closer to non-expert users.
Improve Bird UCI configuration adding LUCI support (web graphical interface). Adding a graphical user-friendly interface and the necessary tools to automate hardest processes of the configuration, non-expert community users could find this daemon as an easy to use routing tool.
Adapt Bird daemon to QMP (1 week)
Once working on OpenWRT and with an easy ‘to put on work’ configuration, add integration with the QMP firmware owing to replace Quagga’s routing functions in frontier nodes of the QMP network.
2n Block: Automate the translations of routes and metrics between a non-dynamic routing protocol and a dynamic one. (~2 months)
Creation of a routes and metrics exchange system (7 weeks)
Study and build an exchange system for metrics and routes between BGP (from Guifi.net) and BMX6 (from QMP).
Test and debug this solution in the real scenario (Guifi.net-QMP)
3rd Block: Project basic feedback and documentation (1 week)
Documentation, user support&feedback and results presentation.
About the author
I am Eloi Carbó, a Computer Science student specialized in Information Technology in the UPC of Barcelona. Currently I am working on my Final Degree dissertation: UPC CN-A testbed mesh network deployment, monitoring and validation. Using the Wibed Platform developed by the CONFINE Project [Link: https://wiki.confine-project.eu/wibed:start].
About the project collaborators
The project tutors are Roger Baig (fundació Guifi.net) and Axel Neumann (Freifunk and BMX6 support) and the special collaboration of Pau Escrich (fundació Guifi.net and QMP project).
The summer of code project of Steven Barth aka Cyrus is about planning and implementing an IPv6 and TLS capable
superserver in Lua as well as an HTTP/1.1-Server working on top of it
using the LuCI HTTP-Stack. This application will serve LuCI – the
Freifunk Firmware web user interface – and replace the currently used
slower CGI-solution without IPv6 and encryption support. Additionally
an RPC-Server will be built to allow remote administration of one or
more OpenWrt devices in a standardized way using JSON-RPC over TCP.
The results of the summer work of Cyrus is pretty overwhelming. There is for example nixio, the new POSIX Lua library which will help us getting rid of the Lua 3rd
party library mess. And based on that there is also LuCId – which was described in the GSoC project. It brings us a new efficient HTTP-server. Some people may have
discovered that Cyrus already checked in things into trunk ocassionally. Also SSL support is working. Another nice new feature is native
support for creating wizards which will be used in the near future. The results of LuCId are already being tested in productive environments. They are performing well. Kernel mode
IO and TLS encryption function well. Special thanks for the achievements also go to John Crispin aka BLogic who is the mentor of Steve during the summer.
The OpenWrt team (Cph) has announced a new version of its Linux distribution for embedded wireless devices named "OpenWrt Kamikaze 808 Release". I talked to Felix Fietkau already at the WCW. Unfortunately we did not have the time to do an interview at the end. But Cyrus from freifunk Halle gave a short showcase of his interface (in German). The OpenWrt team was also impressed by it and they now announce the enclosure of the Luci interface officially. Congratulations Cyrus!
It has been quite a while since OpenWrt had a new Kamikaze release. The developer team has decided that it is time to get things straight and focus on a new release. This release have the official name: OpenWrt Kamikaze 808 Release.
The schedule will look like this:
*Last day in July – final release candidate: 808 RC-1 808 RC-1 will be a feature freeze, and all changes after this point will be bug fixes.
*Last day in August – final release: OpenWrt Kamikaze 808 Release.
OpenWrt Kamikaze 808 Release will focus on bringing the following:
– Firewall rewrite
– Broadcom 47xx running reliably with the new Kernel, not including wifi
– IMQ and Traffic shaping tested with newer kernels, especially 2.6.25
– Sysupgrade for more platforms (x86 is tested again)
– The new web interface (LuCI, Lua Configuration Interface)
– Attention towards the integration of security updates
– Package maintaining and updates between releases
– Testing, testing and lots of testing…
The 808 Release will also include support for several new platforms/targets. (http://forum.openwrt.org/viewtopic.php?pid=69873 )
Some more info in English: FFLuCI is a Lua MVC-Framework for Freifunk with templating support. There are
working configuration pages for many system, network, services and wifi settings. Please visit http://luci.freifunk-halle.net for an overview of functions, screenshots, tutorials, SVN URL and snapshot images for Atheros and Broadcom.
Steven Cyrus started to develop Luci because he was not satisfied projects like XWRT implemented things. He had a look at the X-WRT Lua files in their repository first, but what was missing was a clear abstraction layer and templating support so I decided to build everything from scratch. According to Cyrus – X-WRT has a very nice UI written in shell code but there are only limited capabilities of this scripting language and so "it is time
to bring this thing to the next level using OOP and such nifty stuff."
Luci already has a number of working configuration pages. There are more – or in a few cases less – working configuration pages in (for now) German titles and descriptions for the:
Configuration Bind Interface (CBI):
You just describe the data model of the UCI file and Luci does the rest for you: It will create the HTML-form, parse and validate the user input and write the configuration data to UCI. So no need to redo all these things on every configuration page again and again. It also supports basic field dependencies, dynamic validation functions, section creation, deletion and more. See an example here: http://wiki.freifunk-halle.net/Luci:WritingModules#CBI_models
To avoid remote exploits (like those in older versions of the Freifunk Firmware) FFLuCI will set the UID/GID of pages running in the main public non-protected section to nobody/nogroup. There are many things left to do like porting over dhcpsplash, accounting, statistics and more to Kamikaze. Contributors are welcome.