GSoC 2017 – RetroShare mobile improvements – Final evaluation update

Hi Freifunk and GSoC communities!

Finally we arrive at the end of the summer and also at this third final evaluation of GSoC!
I’m proud I have participated to this edition of GSoC and I am thankful for this opportunity.

This past month I did lot of new work and lot of interesting improvements.

One of the funniest and visible things are the implementation of the 8biticon library that provides a reliable avatar face generated using GXS id as input, it is reliable in the sense that having the same GXS id as input will generate always the same avatar.

The nice thing about this is that it can be used as an user friendly way to verify identities, the user doesn’t need anymore to check long fingerprints but she can do a quick verification just by looking at the generated face.

Another interesting thing I have implemented is sending little files and images via chat using data URL. This works encoding a file to base64 and send it with a header specifying the mime type. The maximum file size is 60KB, and for images, if it’s bigger than that or if it’s size is more than 160×160 pixel, the program resizes it to fit.

This branch results very interesting for me because it uses all the things that I learned this summer: call C++ code from QML, call Android Java code from C++ interact with Android OS, create custom QML components from C++ code…

 

Of course, a big part of work has been to find and fix bugs, on Android and on desktop. At the moment the last commit has little known bugs that I’m going to solve as soon as possible.

One of this bugs causes program crash on some Android devices when send or receive an emoji. This happen because I implement an alternative emoji font if no native compatible emoji font is found. On Android, the Android Emoji font is who provides the typography of emojis, but in some devices its not shown. So I decided to integrate the OpenSansEmoji project. That way, when the program doesn’t detect a compatible emoji font, it uses the OpenSansEmoji.

But the implementation of that is not working as good as expected and causes the crash mentioned above.


Another typical work has been to improve the UI aesthetics in little things: correct a height in one place, change the color somewhere else, draw a line separating the contacts. I create a custom button component with animation and the possibility to attach to them an icon. This is done thinking about to also centralize the application style sheets.

And thinking about the end user, I tried to improve how the user share or import the nodes identities. I put a shortcut on the menu to share identity, and also refactor a little bit the import/export trusted nodes view, making an informative popup that shows you a little bit of information about each option.

 

Also I have done some little attempt to implement key exchange using the device sound card using libquiet available in C, Java, JavaScript and more languages.

This is a very interesting functionality that would improve the key exchange process and make it user friendly.

The functionality is not implemented yet as I believe it would take more time then the GSoC as it seemed more difficult than we thought initially, but I would like to continue working on this topic in the future.

In latest days I have been working with my mentors to do the final polishing and integrate most of the code in RetroShare official repository master branch, most of the code have already been merged as you can see in this commit e06bffdb by one of my mentors.

As always you can find all the code and activity track on my gitlab repository, I also suggest to take a look to the detailed technical report and if you are eager to test the results on your phone you can download the Android Package too.

Finally I want to say goodbye, and again appreciate the opportunity to participate to this exciting GSoC!

Implementing Pop-Routing in OSPF – July Updates

In the last months some issues emerged with the original plan of my project.
After implementing topology export in NetJSON format for BIRD, I started investigating how to modify the timers of OSPF, and finally found that OSPF has a limitation regarding the timers, which states that all the routers on the same network must have the same timers. This is surprising, since the RFC supports specifying the timer in the messages, and thus it would be trivial to have nodes with differentiated timers (as OLSR and other protocols do, for instance). Actually somewhere else in the RFC it is stated that even if the timers could be diversified, they must be used as a network-wide parameter, otherwise routers wont pair as neighbor. This issue is not easy to solve, and would break the compatibility with other OSPF implementations, thus, together with my mentor we decided to change the project on something that we could accomplish in the remaining time and that was still helpful for Wireless Communities.

Since many WCNs in Europe are still using OLSRv1 we’ve decided to implement PopRouting on it. The NetJSON plugin[1] is already available so we only had to implement the Timer’s plugin and the PRINCE plugin to communicate with it.

During this mont I’ve implemented and alpha version of the Pop-Routing plugin[2] for OLSRd. This plugin is quite simple, it listens to a specified port and it parse two commands : “/HelloTimer=xx.yy” and “/TcTimer=xx.yy”, where xx.yy are floating point numbers.

I’ve also implemented the Prince plugin[3] that communicate with OLSRd. It fetches the topology from the NetJSON plugin and it pushes the updated timers to the PopRouting Plugin.

The next month I am going to fix all the bugs I found, document the plugins and test Pop-Routing with NEPA test.

Despite those problems the implementation of NetJSON for OSPF is working and we hope it will be merged in the BIRD codebase soon.

Cheers, Gabriel

[1]: https://github.com/OLSR/olsrd/tree/master/lib/netjson
[2]: https://github.com/AdvancedNetworkingSystems/olsrd/tree/poprouting/lib/poprouting
[3]: https://github.com/AdvancedNetworkingSystems/poprouting/blob/refactor_ospf/prince/src/olsr/olsr.c

GSoC: Improving nodewatcher data representation capability (update 3)

I have been working on improving the wlan-slo main page. This page has not been updated in a long time and it is crucial at introducing new people to mesh networking.

Continue reading “GSoC: Improving nodewatcher data representation capability (update 3)”

GSoC 2017-netjsongraph.js milestone 2

After a month of efforts, netjsongraph.js has been greatly improved.
First, I added some API and options are compatible with previous versions, except those that can not be added to the WebGL element. Followed by updating the documentation and some examples so that users can better understand and try out our projects. Finally, I have optimized interaction and performance.

netjsongraph dark theme
netjsongraph dark theme

Interaction

  • added highlight effect on nodes and links when hovered.
  • added tooltips with node information
  • added pan and zoom interaction
  • added node and link information panel when clicked
  • adjust the size of the canvas when the window resized

Performance

The large part of the performance of force-directed layout is consumed in each element position calculation in every tick. So if the position calculation of the elements is before canvas rendering, it is effective to reduce the performance loss.
So I made a static layout https://github.com/netjson/netjsongraph.js/issues/44, there is no animation when rendering, directly render a static force-directed layout in the page.

Other

Besides, I have refactored the event controller, in order to make zoom and pan or other events added easily.
But now the overall rendering results are not good as our expected. There is a little lag in animation, I currently have no idea about the reason, perhaps because this is not best practice of three.js. In the next stage, I will focus on solving performance problems and improving the visual effect.

Next Plan

The links below may be useful:

  • http://taligarsiel.com/Projects/howbrowserswork1.htm
  • http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/
  • https://github.com/alex/what-happens-when
  • https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame

GSoC 2017 – Add MPTCP support in LEDE/OpenWRT trunk – July progress

What we have so far

After lots of experiments, I figured out the way which enables the transparent MPTCP operation for both the client and the server (with the regular kernel).
I tested the configurations at my virtualized environment, check the video below. For configuration infos, please read the video description. (the post continues)

Continue reading “GSoC 2017 – Add MPTCP support in LEDE/OpenWRT trunk – July progress”

geolocator-software-defined-gps-second-evaluation

Hi everyone,

 

I am now taking you over my second evaluation. A German version of this blog post can be found here [0]. For people who did not read over the geolocator (Software defined GPS) project before, here is a link to the project introducing (english)[1] and (german)[2]. The first evaluation from last month can be found here (english)[3] and (german)[4]. First of all I would like to tell you about the web backend:

 

Web Backend

As I said it in the blogpost before, the new web backend should replace the old one.
The current openwifi.su web backend consists of a collection of different programs in different programlanguages. The new one is written in Golang it has a fully backward compatibility. The new web backend is more secure.  It checks all requested strings at the end of the url that they contain only comma separated macaddresses with 12 hex characters, as a validation check.

 

Also the new web backend fix an issue by calculating the requested position. The method before just adds all latitude values and devides them over the amount of positions. Same for longitude. The new way is a geographic midpoint calculation. First the lat/lon values will be converted into radius and then the radius will be converted into a Cartesian coordinate system, after that the midpoint calculation will be done and will gave us a lat/lon in the form of radius and the values will be converted back into degrees, that is all.

 

The web backend has a new feature which should help to enhance the position quality. If there are BSSIDs unknown in the database of openwifi.su, the new backend sends an extra request for the unknown BSSIDs to Moziller location service [5] and brings that information into the calculation of the response.

 

At the moment the new web backend is being tested. In the next few days a first version of the new web backend will be released. The current code can be found here [6].

 

LEDE Package

The last project is to build packages for LEDE and send merge requests to Gluon. The idea behind that is, for WiFi routers and other WiFi devices to be able to automatically receive their own position. This could be a nice feature for mobile Freifunk Routers. It could also provide a good alternative instead of setting positions by hand. A first version of that package is here [7].

 

For the integration in Gluon I plan 4 new packages. The first one is the gluon-geolocator, which depends on gluon-node-info and provides the programme with the capability of receiving geopositions based on surrounding WiFis.

 

The next 3 packages are just for the Gluon configmode. The configmode is a state that begins at the initial start of a Gluon router and the owner of that router can configure it over a LAN connection.
I would like to integrate the following 3 packages within the gluon-config-mode-geo-location.
They are named:
gluon-config-mode-geo-location-with-geloc-map,
gluon-config-mode-geo-location-with-geloc,
gluon-config-mode-geo-location-with-map

 

As their names indicate, the package gluon-config-mode-geo-location-with-geloc-map should integrate the options of the geolocator and an OSM map into the configmode. The other 2 packages, gluon-config-mode-geo-location-with-map and gluon-config-mode-geo-location-with-geloc should either integrate only an OSM map or just the configuration options of the geolocator. Also the package gluon-config-mode-geo-location should be able to and will show the current location interface without any map or geolocator.

 

A merge request of the above new packages will follow soon. Some of the gluon-config-mode-geo-location extensions are currently not finish yet.

 

In the next few weeks I would like to finish the integration into Gluon, as well as continuing to develop the new web backend and releasing the first version of it. There are many ToDo points currently open e.g. Multicore functionality, optionally other geographic midpoint calculations. At the beginning of August there is the SHA2017[8], which I will use for a marathon session.

 

With best wishes
Jan-Tarek Butt

 

GSoC 2017 – Milestone 2

Following the rather stark change of direction after the last milestone (see my last post), I have worked on the integration of my project with Johannes Wegener’s: OpenWifi.

July Progress

For my software-defined networking (SDN) agent, I have added support for configuration through a UCI config file as well as process management through procd. This ties the daemon in neatly with the LEDE/OpenWRT system. Now, parameters such as the SDN controller’s address are read from this file and the configuration can be reloaded at runtime without stopping the agent.
Using the UCI system also exposes the configuration parameters to Johannes’ OpenWifi system. He and I discussed the bootstrapping process with our mentor and we have come up with the following idea: When a newly installed LEDE/OpenWRT access point first boots, it discovers the OpenWifi server via mDNS and fetches its configuration from it. With the address contained in the configuration, my SDN agent on the access point is able to connect to the SDN controller and thus integrate automatically with an existing centrally managed deployment. In the event of a configuration parameter change (e.g. a switch to a different SDN controller), OpenWifi can trigger a configuration reload to quickly update all access points in the network.

On the controller side, I have implemented a REST client to interface with OpenWifi. Through it, the controller can register with the OpenWifi server. During the registration, it installs its address and OpenFlow listening port in the UCI configuration which later gets sent to access points.
I have also begun writing a REST interface for my controller to offer more comfortable management of SDN applications and the network state. Right now, I can query the controller about its resources: access points, switches and clients. With the basics in place, expanding the interface to expose more SDN functionality should be pretty straightforward.

Next Steps

During the final part of this year’s GSoC, I want to focus on adding functionality, testing and documentation. I will spend the remaining weeks of the project like this:
1) write an SDN application
2) expose the app’s functionality via the controller’s command-line and REST interfaces
3) test it on the university department’s testbed
4) document its usage
5) goto 1)

Since the foundation for the SDN applications is in place and running, I am optimistic about getting a lot done during August. I will start with a client hearing map that keeps track of associated and unassociated clients in the vicinity of the deployment’s access points. Leveraging the hearing map, I want to implement a client load balancer that distributes associated clients evenly across available access points. I will also look into automated channel selection to avoid interference between neighbouring access points.
Finally, I would like to wrap up the controller in a docker image for easy deployment.

Luci2 on Libremesh – July

At the moment the development of luci2 is found rethinking some decisions and advancing in others. The thread of the discussion can be seen in
https://github.com/jow-/luci-ng/pull/42 mainly pushed by @ianchi and commented on by @jow.
For my part I started looking for a mid-point between the LiMe App (developed in preact for LibreMesh) and Luci2. At this moment LiMe App uses orangerpcd in the backend and the same api is being migrated to be consumed from ubus.
The plug-in test for “luci2” in preact can be seen at https://github.com/gmarcos87/preact-luci, although the main development will continue from now on in Agular, but trying to maintain an aprouch where views/apps are Completely defined in json.
I hope to get to the next post with the libremesh api on ubus ready to be consumed by Luci2, whatever their final destination.

GSoC 2017 – Spectrum Analyzer updates (2)

This is the second update of the spectrum analyzer project.

I’m glad to say that we have a visualization that is allowing us to view the output of the card in a meaningful way.

After polishing this interface I will create the waterfall and the cumulative views that are useful for this.

I will leave you a screenshot of how it looks right now (it will get better soon).

Also, we have started conversations with a University that has done an MVP of a PAWS database. The purpose of this is to gather information on the spectrum usage in the TVWS frequency.

With the help of the TVWS Frequency Shifter that Elektra is developing, we will be able of doing site surveys on those frequencies.

This will allow any OpenWRT device with an ath9k radio and a frequency shifter and a GPS to act as a surveyor of those frequencies.

Also had the chance to support the LibreMesh project by adding a Continuous Integration server that will be soon merged to the master branch. That will allow the project to keep on safely by having tests that ensure that the code does what it says it does.

GSoC 2017 – wlan slovenija – Report 2 – HMAC signing of Nodewatcher data

What’s been done

The first blog post that describes the idea and goals can be read here and the first update here.

The data that the nodewatcher receives from nodes had no signature, so anyone could intercept the packets, change the content and send them on their merry way. Authentication using SSL certificates was already implemented, but a lightweight, fast solution, that doesn’t require the use of big libraries like OpenSSL and any extra dependencies on nodes was desired. That means two things. First finding a good sha256 implementation or writing my own. Some libraries implement extra precautions to prevent side-channel attacks, which take advantage of some physical characteristic of the implementation. Even then not all implementations are safe depending on the system on which the algorithms run. It was decided that in this context these attacks don’t bother us too much and the attacker would need physical access to the device anyway. Therefore Brad Conte’s open source implementation was used.

The second part involved writing the hash-based message authentication code. I tried to optimize the algorithm as much as possible saving space and time. After combining both parts the correctness of implemented HMAC-sha256 was thoroughly tested using official test vectors.

The extra option to select the desired authentication was added to nodewatcher-agent, with SSL certificates being the default. If HMAC signing was selected, a HMAC signing key needs to be provided. The signature converted to base64 is then inserted in to the message header and checked when received by the nodewatcher.

What’s next

Now I will start working on IPv6 support for the Tunneldigger.

I am contributing using my github account.

Forward! Good luck!