Tag: gsoc

GSoC 2017-netjsongraph.js milestone 1

Posted on by GeekPlux

netjsongraph.js(GitHub) is a visualization library for NetJSON. During the first month, gratifying results have been achieved. I have done most tasks for the first stage of netjsongraph.json. Thanks for the nice mentor and this great chance to let me learn a lot of skill and techniques. Here are some results:

Minor version published

Npm is currently the largest open source package management community, it is very convenient for developers to release or iterative update netjsongraph.js.

Development workflow imporved

I have imported some modern front-end development tools to simplify the development process, including webpack (build tool), yarn (package management), babel, eslint, jest (test framework). Developer can run or test the project by one line command. all tools are advanced and familiar to JS developers, so they can contribute more easily.

Rewrited visualization by webGL

I had developed three demos with three different technologies: Sigma.js, Pixi.js and Three.js.
Sigma.js code looks very concise, but importing of its plugins (such as force layout plugin) in modern way is so hard. Pixi.js and Three.js I used it only to render d3 force layout. And three.js looks slow than Pixi.js but its slowness may caused by lines render way.
But I finally decide d3 4.0 and three.js is the best choice currently. Because they are both famous and iteration rapidly. Pixi.js is also great but it only support 2d render, so if we want to expand our visualisation to 3D in the future, we can only choose three.js. Three.js is a library which lightweight webGL packaging in order to avoid writing WebGL directly that is very hard and verbose.
Then I refactored the demo to a Class and write some API backward compatible, including function to fetch data, theme switching, autosize, metadata and nodedata panel and zoom, hover, click event handler. It looks like:
netjsongraph.js
Metadata and node data panel are on top left and right corner, force graph for Netjson visualization in the center.

Tests added

Some unit tests have beed added and CI has beed integrated by Travis and Coverall. Because I wrote tests rarely before, so I meet some trouble and read a lot docs and examples to learn how to write test and how to use Jest. One problem I’ve met is test failed when import object with WebGL renderer. I’ve send a issue: https://github.com/facebook/jest/issues/3905 .

Next stage

I will complete the compatible API in the next week, and below are tasks for next milestone:

  • add optional geographic map
  • add a way to redraw graph by supplying new data
  • add more interactions
  • improve force layout details

Conclusion

Next version which have more interaction and rendered by WebGL is comming soon. and it will be soon integrated in the brand new OpenWISP 2 Network Topology module.

During this period I learned a lot of things, including how to use git rebase, how to write commit messages more clearly, how to write test, KISS principles, worse is better principles and so on. Great thanks for GSoC, Freifunk and mentor Federico.

​

geolocator (Software defined GPS) first evaluation

Posted on by buttjantarek@googlemail.com
Hi together,
Now I am coming to my 1 phase: evaluation. An introduction into the geolocator (Software defined GPS) has been already done last month. You can find it here [0]. In the previously mentioned blog post I have told about the 3 main sub-projects: web backend, gps-share, LEDE Package. In this post I will show you what I have done in each sub-project. Beginning with the web backend:

web backend

This sub-project should replace the old web backend of the openwifi.su project. 
The old backend is split into various programs and scripts, grown over years. First of all I started with the part of receiving positions. This program is written in ruby and just parses the URL as a string. So users can simply call 
wget -O - http://openwifi.su/api/v1/bssids/64700274945A,0018E7DC21BB,30FC681F37A6,F81A673626E8,EC086BA8ED18,8416F9A8E2FA,E894F6A230E4,98DED020D00A,EC086B3349B2,F81A677F5CD8,A0F3C1654BA6 2&>1
and will receive latitude and longitude. The BSSIDs in the above URL are from surrounded WiFi networks. The old ruby code just drops all characters up to the last splash and splits the BSSIDs by comma. The result array will be integrated into and SQL command which returns a position for each BSSID. The code for this part is non public, because the developer doesnt want to risk attacks by hackers. I started porting the old ruby code to golang. Currently I am working on the database connection. So in the next few days the backwards compatibility will be finished. The current code can be found here [1].

gps-share

gps-share is a software which provides GPS informations in the local network, written in rust [2]. It supports many GPS hardwares and shares the GPS informations over a network-NEMA format. Zeeshan Ali, the maintainer of geoclue, has already released a first version of gps-share [3]. Zeeshan and I discussed on the Mozilla Location Service Mailing-list about that project [4] . As I told it in the last blogpost, the gps-share is an alternate project to the original idea. This helps geoclue to work directly with GPS-hardware´s and builds an defined interface via dbus to receive geopositions over GPS hardware, surrounding WiFis or other ways.

LEDE Package

The last  sub-project is a new LEDE-package, which provides geo positions received by their surrounding WIFIs. I have already built a first version of that package here [5]. I also started discussing with maintainers of the gluon framework, which is a popular framework in the Freifunk community. My plan is to integrate the goelocator also in gluon so routers can automatically receive its position. A first draft can be seen here:

An idea is that the Web interface of the router could detect installed packages and provide their options on the Web interface. This means, that in the drop down menu, the option “Automatic (geolocator)” will only be shown if the package geolocator is installed. This makes it easier for local (freifunk) communities to integrate new options of position detection into their firmware.
This is also my last week of my exam period. Now I can work full time on the project. Next plans are improving functionality of the new backend, building CI unit test for the new planed API and building the Mozilla Location Service communication interface to sync the requests between MLS and openwifi.su.

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

Posted on by red_moo

What’s been done

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

After getting a bit more familiar with the code base the first thing that had to be done was to set up the work environment. I chose to go the virtual machine route so an actual router did not need to be used, making the development easier. An instance of the nodewatcher is running on a virtual machine running Ubuntu Linux. It runs in a Docker development environment and is set up by using the provided Docker Compose configuration. To enable data collection from nodes the monitor system also needs to be running.

To test the the nodewatcher’s HMAC signing capabilities I set up a dummy test node, turned on HMAC signing and used a python script to push some data on to the nodewatcher.

The next step was to set up a development node. With a lot of help from my mentor Kostko I used firmware-core to create a LEDE virtual machine, compile nodewatcher-agent packages, transferred them to the LEDE machine, used SSH to connect to it, installed them and tested the basic nodewatcher-agent functions. The whole setup and development process was documented in detail in the nodewatcher-agent README. Then I set up the agent’s http.push module and pushed some data on to the nodewatcher instance.

A local network like one in the above image was set up for development. Due to my lack of experience with networking I encountered some issues like not being able to ssh into the LEDE VM and not being able to send packets from LEDE VM to Nodewatcher VM, but with patience from my mentor it all works and the lesson was surely learned.

What’s next

So the hardest part is done, right? I am now working on adding a HMAC signing like it’s already done in the python script. It needs to be developed for both pushing the data from a node to the nodewatcher and pulling the data from a node.

I am contributing using my github account.

Onwards! Good luck!

PowQuty Live Log First Update

Posted on by Stefan Venz

As mentioned in my previous blog post, i am going to add a live log and notification system for
certain events to the power monitoring tool PowQuty. The first steps have been done and the
configuration has been extended.
Three types of notifications have been added to the configuration options during the first month of coding.
Namely email, slack and mqtt. Mqtt was in use before, but was extended to allow a second host and topic for
the power quality events.
The powquty configuration page was redesigned to use a separate tab for each notification option
to increase overview.

The old configuration page would have been very crowded with all the new options
The new configuration view with mqtt tab open

Power quality events, that cause a notification are:

  • Voltage dip between 10% and 90% of the reference voltage of 230V
  • Voltage swell above 110% of the reference voltage of 230V
  • Voltage dip < 10% of the reference voltage
  • More than 5% of the samples of one harmonic are above the threshold

As the power supply network in Berlin was not willing to provide such events an option for test measurement
input was needed. A file read flag for powqutyd was added and needs a little bit of clean up
before a pull request on the upstream powqutyd.
The library for the USB-oscilloscope provides the number of EN50160 events per measure cycle and
the kind of each event. As of now some basic slack notifications are added, which provide the event
type and the event start time from measurement start in milliseconds to the channel and team set
in the luci web interface or under /etc/conf/powquty.

Slack notifications with start time in milliseconds relative to measurement start, probably will be UTC or local in the future

In the notification the type of event is provided to allow the network administrator to react directly
to the changes, without to check the log any further.
The other notification options will be added and tested soon.

GSoC 2017-netjsongraph.js: visualization of NetJSON data

Posted on by GeekPlux

Project intro

NetJSON is a data format based on JSON(What is NetJSON?), and netjsongraph.js(GitHub) is a visualization library for it. This library has attracted quite some interest from around the world, but there are some defects, such as tests and modern build process lacking.

Therefore our goal is to improve the features and development workflow of netjsongraph.js. To be specific:

  • make it faster with large numbers
  • make it more mobile friendly
  • use modern tools that are familiar to JS developers, so they can contribute more easily
  • add automated tests so we can be more confident of introducing changes
  • get rid of complex features
  • make it easy to extend, so users can experiment and build their own derivatives
  • make it easy to redraw/update the graph as new data comes in, at least at the library level we should support this
  • geographic visualization (like https://ninux.nodeshot.org/ (nodeshot project)

Arrangement

About me

I’m a graduate student from China and also a front-end developer with more than one-year working experience. And now I am interested in the Data Visualization and already made several visualization projects of network structure. So lucky my proposal selected by Freifunk in Google Summer of Code 2017. It’s a great opportunity to participate in a promising open source project. Thanks for my mentor’s guidance and hope I can finish an excellent job. So I listed the following plan:

Tasks and Schedule

  • create a new branch: build the project with yarn, Webpack and Babel. 1 week
  • To build a (mostly) backward compatible version 1 week
  • draw a demo graph using canvas or WebGL. 2 week
  • make a example page to show visualization results. 1 week
  • add test(using Ava and XO) and CI. 1 week
  • discuss and design visualization view 1 week
  • import and integrate with OpenStreeMap or Mapbox to make a map. 1 week
  • visualization implemention. 8 weeks
  • beautify the visualization. 1 weeks
  • improve visualization and test. 4 weeks
  • design interface for plugin (to make this library extensible) *2 week
​

GSoC 2017 – LuCI2 on LibreMesh

Posted on by Marcos Gutierrez

My name is Marcos Gutierrez, I am from Argentina and this year I participate in the GSoC 2017 in Freifunk. My main task is to incorporate LuCI2 into LibreMesh and to adapt or rewrite the modules that are currently used.

LuCI2 – UI

In my first approach to LuCI2 I realize that there is much more to do than it seemed. The development of Luci2 is still looking for a more stable path, there are good ideas, but a resolution, to my understanding, is incomplete. Only the base UI build weighs 1.4MB, this far exceeds what LibreMesh requires. So I should explore some alternatives to drastically reduce the size.

Continue reading “GSoC 2017 – LuCI2 on LibreMesh” →

geolocator (Software defined GPS)

Posted on by buttjantarek@googlemail.com
Hi everyone,
 
My name is Jan-Tarek Butt. I am in my fourth term of computer science at Emden University in Lower Saxony (Germany). Some of you may know me from the last Google Summer of Code. I am one of the students who is participating for Freifunk in the Google Summer of Code 2017. In the following post I would like to introduce you to my Google Summer of Code project. I split up the project, same like last year, into 3 main subjects: web backend, gps-share, LEDE Package,

web backend

The first one is a restful API backend[0], which should include a backwards compatibly to the api format of the old openwifi web backend[1]. The new backend should be written in Go, which will be clearer in the next few days. The New API should use Mozilla Location Service as fallback if it is not possible to determinate a position based on the own db entries. Received WiFi information can also redirect to Mozilla Location Service[2]. So some of you might have the question what is Mozilla Location Service. It is simply a service with a big database full of wardriving informations from mobilephones. Mobilephones scan for surrounded wifi networks and send this with its own position to the Mozilla Location Service. These datas will be integrated into the database. If you want to know your position without having GPS, just send only your surrunded wifis to the Mozilla Location Service and you will receive your position based on the wifi informations see the picture below.

gps-share

The first Idea was to create a software defined GPS as udev device which should provide NEMA-famata protocols over tty and receive the necessary informations over wifi. While discussing with people on the Mozilla Location Service Malinglist, it turns out that something similiar is already done in geoclue which provides geo coordiantes over dbus and can receive coordinates via Mozilla Location Service. geoclue works with network-NEMA and Mozilla Location Service. Over network-NEMA geoclue can receive GPS informations from Mobilephones and GPS modems working over local networks. To avoid of developing redundant software, i discussed with Zeeshan, the maintainer of geoclue, about building support in gps-share for standalone GPS instead [3]. This is a software which should provide GPS NEMA-Format from GPS hardware over network-NEMA for geoclue. gps-share is written in Rust for ensuring reliability.

geolocator

The third subproject is a new lede package called geolocator, which should provided geo positions received by their surrounded WIFIs. The WiFi informations should be sent to the new above mentioned backend[4].
cheers
Jan-Tarek Butt

GSoC 2017 and Freifunk: Students wanted

Posted on by Andreas Bräu
GSoC Logo

Good news: Freifunk has been accepted again as mentoring organization for GSoC. If you’re a student, please bookmark March 20th in your calendar. That is the date when student application period opens and proposals can be submitted. In the meantime you should visit our ideas page and get in touch with the mentors and our community.

Applications for GSoC

This year we offer much more ideas than in the past but as always we don’t know how many slots (aka projects) we will get from google at the end. So we can’t give you any guarantee for proposals to be chosen. We will select the students and assign them to projects, but the final announcement will be made by the GSoC Program Office.

You aren’t limited to the ideas listed on our ideas page. It is possible to propose your own idea. But keep in mind that you need a mentor from one of our communities, too.

If want to apply please visit our students checklist page before. You can find a lot of information there on how to get in touch with our community. You’ll also find our application template there. It’s necessary to follow that template for a successful application.

During GSoC

There are some things we expect from you:

  • provide status updates to your mentor and your project, you should specify details with your mentor (how often, what medium to use, …)
  • commit early and often to the public repositories of your project
  • sign up our WLANWare mailinglist
  • join one of our community meetings
  • write at least 4 blog posts at this blog:
    1. During the community bonding period. Deadline is May 30 – introduce your project here, present your ideas, show us your project plan with milestone
    2. Before first evaluations. Deadline is June 26 – show your results and explain your status
    3. Before second evaluations. Deadline is July 24 – show your results and explain your status
    4. Before final evaluations. Deadline is August 21 – finally present your project and show us your result. Maybe it’s already live 🙂

To give you a short prospect of what is planned to get you into the project after successful application:

Timeline

Community Bonding (May)

Use this period to refine your proposal. Add more specific milestones. Try to get into software development, e.g. by fixing small bugs. Talk to your mentor and the developers of your project to introduce yourself and your proposal.

From 26th to the 28th of May (the last weekend before Coding Phase 1 starts) there’s the Wireless Community Weekend (WCW) in Berlin. Here the Freifunk community will meet with their guests to create an unconference and hackathon. You have the chance to learn a lot about free wireless networks. It’s your chance to show your project/idea to a lot of community members. So you can get your first feedback before coding starts.

If you need help with accomodation or travel costs, please don’t hesitate to ask your mentors or organization admins.

Coding phases

There’s something new this year: We have 3 coding phases with 3 evaluations. Both, students and mentors have to complete evaluations to proceed. Maybe you can use these evaluations as milestones of if you want to work agile as sprint dates.

If you can’t make it to the WCW in May there’s another great chance in the first coding period to meet a lot of developers and community members during Battlemesh V10 in Vienna from June 05 to June 10. Focus of this event are routing protocols. You can use that event to get a lot of detailed technical knowledge, e.g. by doing pair programming.

If you have any questions please contact the organization admins.

So let’s have a great summer! 🙂

(Thanks to Clemens who wrote some parts if this text before)

Implementing Pop-Routing – Final Evaluation

Posted on by Gabriele Gemmi

Hello again, for two months I have been working on my project and I have achieved all the goals.

An alpha version of my program was released for the mid-term evaluation.Since then I have fixed all the bugs, packaged the program for OpenWRT, tested the code and written the documentation.

Everything is available on the GitHub repository [0]

I structured my work opening by issues for all the bugs I had to fix and for everything I wanted to improve. Then, I organized the issues in milestones. Milestone 0.1 [1] is the one that I had to complete to finish the project. When that milestone was closed I made the branch “v0.1” [2].

Tests

In order to be sure that my program worked correctly. I wrote a simulator in python. It’s made by a small server, with the same interface as OONF’s telnet plugin, and two python libraries written by my mentor: cn_generator [3] and pop-routing[4]. The first one generates synthetic graphs using the Cerda-Alabern[5] algorithm, the second one is a pop-routing implementation in python. In the server I implemented the commands to push the NetJson[6] topology and the ones to receive the timers values.

When prince requests a topology from my test program, cn_generator generates a random graph and pushes it back; meanwhile using the python implementation of pop-routing, the references values are computed. The values received from prince are then compared to ones calculated using python.

The goal of tests is to verify that the difference between the reference and the measured values is always less than 1%.

Measurements

I’m going to use my work to write my Bachelor Thesis, so I wanted to perform some measurements to check how well it worked.

My goal was to implement the algorithm on an embedded device, so I chose to measure the execution time on a “Ubiquiti Picostation M2HP” to see how well it was performing.

I branched Prince [7], modifying the code to measure the time needed to calculate the betweenness centrality and push it back along with the timers.

I used the graph generator to create graphs from 5 to 500 nodes, and I measured the time needed to compute with a sample every 10 nodes. For each sample I ran 5 tests, then calculating the mean and the standard deviation. The results are shown here:

As you can see from the graphic above, the computation time on the embedded device is quite good if we use the heuristic (8s for 100 nodes), it proved to be unusable without it (100s for 100 nodes)

OpenWRT Package

The last objective I gave myself in the previous post was to write a plugin for OLSRd. Since OLSRd isn’t maintained anymore – and since all the developers are working on OONF – I decided to focus on it while avoiding the plugin. Instead, I wrote a makefile and packaged prince for openWRT / LEDE. The makefile hasn’t been published yet in any openWRT feed, but it is hosted in my repository [8]. Instructions are available along with documentation.

Future Work

I’ll keep working on this project, mantaining the code and fixing the future issues. Since the graph-parser library is the last piece of code implemented in C++ and it depends on the Boost libraries, I’m looking forward to re-implement it in pure C.

One of my goals was also to run prince in my WCN (Ninux Firenze), but switching from OLSRd to OONF is taking more time than expected, so I’m hoping to try it in the future.

Gabriel

[0]: https://github.com/gabri94/poprouting/
[1]: https://github.com/gabri94/poprouting/milestone/1?closed=1
[2]: https://github.com/gabri94/poprouting/tree/v0.1
[3]: https://ans.disi.unitn.it/redmine/projects/cn_generator/repository
[4]: https://ans.disi.unitn.it/redmine/projects/pop-routing/repository
[5]: https://pdfs.semanticscholar.org/4ac8/05e7359c6b20c3cdd5da24284d3826b9609c.pdf
[6]: http://netjson.org/
[7]: https://github.com/gabri94/poprouting/tree/exec_time
[8]: https://github.com/gabri94/poprouting/blob/master/Makefile.openwrt

DynaPoint Final

Posted on by Tobias Ilte

Hi everyone,

this is the final blog post about DynaPoint. Short recap: I created a daemon which regularily monitors the Internet connectivity and depending on that activates and deactivates the proper access points. That way the handling with APs would become easier as you already could tell the status by the AP’s SSID. I also created a LuCI component for it to make the configuration more easy.

In the past weeks I was able to add some new features, fix bugs and complete the LuCI component. Especially the latter was really interesting and gave me some knowledge about how LuCI works.

In the last post I mentioned that it’s better to verify Internet connectivity by using wget instead of just pinging an IP address.
Consequently I switched from Pingcheck to wget. I also added an option to use curl instead of wget. With curl you also get the option to choose the interface for the connection.
When you provide internet via VPN-interface you can explicitly check the connection of that interface now. The reason why I don’t use curl as default is because of curl’s rather large size. For some routers with only 4 MB of storage it might be too much.

I also added an “offline threshold”, which will delay the switch to offline mode. So for example when you set the interval to 60 seconds and offline_threshold to 5, the switch to offline mode will be made after 5 cycles of checking (=300 seconds).

So how does an example configuration look like?

To use dynapoint just add dynapoint_rule ‘internet’ and dynapoint_rule ‘!internet’ in the desired sections in /etc/config/wireless:

config wifi-iface
    option device ‘radio0’
    option network ‘lan2’
    option mode ‘ap’
    option encryption ‘none’
    option ssid ‘freifunk’
    option dynapoint_rule ‘internet’

config wifi-iface
    option device ‘radio0’
    option network ‘lan2’
    option mode ‘ap’
    option encryption ‘none’
    option ssid ‘freifunk-maintenance’
    option dynapoint_rule ‘!internet’

The configuration of dynapoint takes place in /etc/config/dynapoint:

config rule ‘internet’
    list hosts ‘http://www.example.com’
    list hosts ‘http://www.google.com’
    option interval ’60’
    option timeout ‘5’
    option offline_threshold ‘3’
    option add_hostname_to_ssid ‘0’
    option use_curl ‘1’
    option curl_interface ‘eth0’

All of that can also be configured via LuCI:

If you want to try out DynaPoint for yourself please visit https://github.com/thuehn/dynapoint for more information.

Future work

Currently there is only support for one AP per state. In the next weeks I want to add support for multiple APs per state.
Also I want to add support for more rules. At this time there is only support for one rule “internet”. I want to make this more generic and provide support for custom rules.

Acknowledgements

I want to thank my mentor Thomas Hühn for his excellent mentoring and great ideas during this project. 
Also of course thanks to Freifunk for letting me realize this project and thanks to Google for organizing GSoC.