Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

May 31 2017

15:07

Spectrum Analyzer in the context of LibreRouter

Hello to all!

My name is Nicolas Pace and this is the first time and engage into participating in the GSoC for Freifunk.

For this opportunity I’m engaging with the LibreMesh community on the context of the LibreRouter project by implementing a Spectrum Analizer for LibreMesh and also for LEDE/OpenWRT.

Spectrum Analisis is a very powerful tool for anyone that wants to enhance the quality of the links created, but also can be used as a base for more complex functions like diagnose of the physical layer, or many other things that have been implemented in other firmwares.

 

What has been done already

During this last weeks I’ve the chance to engage the community, and also to deepen my understanding of the problem at hand.

Also, I’ve got a working prototype of the command-line interface, and a prototype of code that has been used to show that information.

Next steps

  • To create a lightweight service that shares the information with the web
  • To make a nice interface for the output

Thanks for the opportunity of joining you, and hope to deliver as expected!

Der Beitrag Spectrum Analyzer in the context of LibreRouter erschien zuerst auf Freifunkblog.

14:03

Bringing a Little SDN to LEDE Access Points

Hi everyone!

My name is Arne Kappen and this is the beginning of my second participation in GSoC for Freifunk.

Last year, I implemented an extension for LEDE’s netifd which enabled network device handling logic to be outsourced to an external program and still integrate with netifd via ubus. My work included a proof-of-concept implementation of such an external device handler allowing the creation and configuration of OpenVSwitch OpenFlow switches from the central /etc/config/network file [1].

Sticking with Software-Defined Networking (SDN), this year I am going to provide the tools to build SDN applications which manage wireless access points via OpenFlow. The main component will be establishing the necessary message types for the control channel. I am going to extend LoxiGen to achieve this. In the end, there should be OpenFlow libraries for C and Java for the development of SDN applications and their agents running on LEDE.
I will also write one such agent and a control application for the ONOS platform to test my implementation.

My ideal outcome would be a REST interface putting as many of the APs configuration parameters under control of the SDN application as possible. Such a system could provide comfortable management of a larger deployment of LEDE access points and be a stepping stone for more complex use cases in the future.

I am looking forward to working with Freifunk again. Last year’s GSoC was a great experience during which I learned a lot.

[1] Last Year’s GSoC Project

Der Beitrag Bringing a Little SDN to LEDE Access Points erschien zuerst auf Freifunkblog.

May 30 2017

19:52

Implementing Pop-Routing in OSPF

Hello everyone.

I’m Gabriele Gemmi, you may remeber me for… Implementing Pop-Routing[1]
This is the second time I participate in GSoC and first of all I’d like to thanks the organization for giving me this opportunity.
Last year I implemented PR for OLSR2. The daemon, called Prince [2], is now available in the LEDE and the OpenWRT feeds.

What is Pop-Routing

PR is an algorithm that calculate the betwenness centrality [3] of every nodes of a network and then uses this values to calculate the optimal message timers for the routing protocol on each node. In this way a central node will send messages more frequently and an outer one less frequently.
At the end the overall overhead of the network doesn’t change, but the convergence gets faster.

Objectives

My project focuses on extending Prince functionalities to use Pop-Routing with OSPF. I decided to work with BIRD, since it’s written in C and it’s already available for OpenWRT/LEDE
In order to do this I need to develop 2 components:
— A plugin for BIRD that expose the OSPF topology in NetJSON and allows to update the timers
— A plugin for Prince that communicate with the BIRD plugin

I already started developing the former [4], and I’m looking forward to implement the latter.
I’ll keep reporting my updates here, so stay tuned if you wanna hear more.

Cheers, Gabriele

[1]: https://blog.freifunk.net/2016/05/23/implementing-poprouting/
[2]: https://github.com/AdvancedNetworkingSystems/poprouting/
[3]: https://en.wikipedia.org/wiki/Betweenness_centrality
[4]: https://github.com/AdvancedNetworkingSystems/bird

Der Beitrag Implementing Pop-Routing in OSPF erschien zuerst auf Freifunkblog.

18:41

GSoC 2017 – RetroShare mobile improvements

Hi readers! I am Angela Mazzurco and I am very grateful to the GSoC community
(Google, Freifunk, RetroShare etc.) for giving me te possibility to participate
as GSoC student this year!
I study Architecture and Engineering at Pisa University, and here in Pisa I am
involved in the local community network (eigenNet/Ninux.org).
Thanks to the local community I get to know RetroShare and now I use it on my
daily life when I am in front of my laptop. Remote comunication today is very often
displaced from the personal computer to the smart-phones, because of this very
often I have to downgrade to less ethical and less secure communication
platforms, because most of my friends are reachable only on the smart-phone.
This last unfortunate situation inspired me to help developing RetroShare for
mobile phones.
In this deirection the RetroShare community has already done some effort but
still the Retroshare Android app is in an early stage and need much improvement.
I ‘ll give my contribution to this big project, trying to solve issues with the
interface and helping to develop it, to make it user friendly and easy to use
for all users.
During the community bonding period I started to prepare the developing
envir one ment with suggestions from my mentors, I have been remotely meeting them
on RetroShare and I have been successful compiling RetroShare for desktop, and
now I am preparing the toolchain to compile RetroShare for Android, that is not
so easy as it may seems.
The application interface is writted in Q ml , a language part of Q t framework,
so my first steps have been prepare Qt Creator IDE to, and to create my own fork
of the Retroshare project [0]
The app comunicates with the Retroshare API to get the information, using unix 
sockets, and also with the native Android operating system, using JNI ( Java Native
Interface) .
After having the toolchain working I’m going to start improving the QML
interface, adding features, improve the integration with Android operating
system, improve usability, and fix a bunch of bugs.
Cheers!

Der Beitrag GSoC 2017 – RetroShare mobile improvements erschien zuerst auf Freifunkblog.

15:06

GSoC 2017 – RetroShare via Freifunk

Hello, my name is Stefan Cokovski and I’m an undergraduate student at the Faculty of Computer Science and Engineering, Saints Cyril and Methodius University of Skopje. My field is Computer Networks Technologies.

Firstly, I would like to thank Google and the team responsible for organizing GSoC. GSoC is a wonderful opportunity for many students all over the world to gain some real experience working on open-source projects, but also to expand their network with new friends and potential colleagues. I would also like to thank Freifunk (for taking many projects related with computer networks under their wing and for also supporting the project RetroShare) and the lead developers (and my mentors) of RetroShare for being here for me during this community bonding period, answering my questions and helping me to improve my ideas. I’m sure they will continue to help me during the later parts of GSoC.

Before I tell you what my project involves, I would like to introduce you to what exactly RetroShare is and maybe convince you to start using it (if you don’t use it already) and possibly join the development process.

RetroShare is a decentralized, private and secure commmunication and sharing platform which provides many interesting features like file sharing, chat, messages, forums and channels. RetroShare is a free and open-source project, completely free of any costs, ads and terms of service. RetroShare is available on several operating systems, including various GNU/Linux distributions, FreeBSD, Microsoft Windows and Mac OS X.

Sounds interesting? Read more.

Why should you use and recommend RetroShare to your friends?

With the recent disclosures involving the violation of privacy, exercising the right to have secrets and secure communication between friends has never been more difficult. Information is often intercepted by various agencies and the need for a secure communication and sharing platform has never been greater. This is where RetroShare comes in play.

RetroShare:

  •   is a completely decentralized, friend to friend network designed for people who don’t want to be dependent on centralized systems which often invade their users’ privacy.
  • provides you the means of exercising your right to have secrets and control what you share and to whom you share it.
  • makes use of strong cryptographic algorithms, while keeping simplicity of use which is very important for average computer users.
  • can be the all in one alternative you’re looking for to replace the dozen other communication methods you’re using at the moment.

Technical specifications:

RetroShare’s network topology, by definition, is a decentralized friend to friend network (F2F). RetroShare uses DHT (distributed hash table) to locate friends and make the initial connection process easier. Transport is provided by IPv4 TCP and UDP, Tor, I2P, while IPv6 support is still in development. Authentication is utilized with PGP keys and the traffic is encrypted with TLS (OpenSSL). UPnP and NAT-PMP provide port forwarding support, while UDP support helps to connect to friends which are behind NAT. RetroShare can be extended via plugins.

Alright, so now since you’re at least partly familiar with what RetroShare is, let me tell you about my project.

Currently, RetroShare is mostly being used as a desktop application. It has a Qt-based GUI which has been polished over time. RetroShare also has a web interface (bingo, this is what I’m interested in). Sorry for keeping you in suspense there. The web interface is a bit behind the main Qt GUI in terms of functionality and appearance. In an age where mobile and portable devices dominate the percent of online devices, it’s absolutely crucial for RetroShare’s web interface to be improved in both appearance and functionality. Being a RetroShare user myself, I (and also many others) have expressed the need for an improved web interface which can drastically improve RetroShare usability on devices other than desktops and open up many possibilities. What I mean is the following: with a solid web interface, RetroShare users can host the core of the application on a machine which could, for example, run 24/7 and thus help support the network by being a constantly active node and enjoy in the features that RetroShare provides on an interface suitable for mobile and portable devices. By now you should be wondering: “Well then, why is there no version of RetroShare for Android?”. Due to the nature of RetroShare (network bandwidth, hardware and other requirements), simply porting the application for Android (or any other mobile operating system) will not result in a stable and usable solution for the end user. Many other applications provide decent web interfaces which allow control and use via mobile and portable devices and my goal with this project will be to improve RetroShare’s web interface to this point.

Just for a reference, I will show you how RetroShare’s web interface (just on the home screen, as to not leak any information from the chats and etc) looks at the moment. And if I’m successful, I will get to show you how it will look at the end of this Google Summer of Code.

Der Beitrag GSoC 2017 – RetroShare via Freifunk erschien zuerst auf Freifunkblog.

09:39

Summer of code: Week 1

¡Hola! 
I am a student of computer science, but most of my knowledge comes from my diy projects. I am a jack of all trades kind of a guy; I have tinkered with low level stuff like add-ons and fpgas,
but I also worked with everything UE4 gaming engine, blender and other high level programs. I like creating visual things such as music visualizations, graphs and other more interactive ways of displaying data. This summer I will help improve the visualization capabilities of nodewatcher.

My project has two main branches, improvement of existing graphs and developing a brand new way to visualize used IP space of nodewatcher. Nodewatcher has many graphs and a lot of data to visualize. Understanding the data is hard without the proper representation. My knowledge of d3.js will help me create interactive, smooth and slick graphs that will help improve the nodewatcher presentation of node data. Creating more dynamic and visually appealing graphs is important and very useful, especially for new users who might get lost in the data.
My second contribution would be a brand new map of the used IP space. At this moment nodewatcher doesn’t have any way to represent the IP pools that nodes are using. Looking at hundreds of subnets is hard to visualize and time consuming. This map would provide a way to show which space is already used and which isn’t.  I have already made a small prototype visualizing the wlanslo IP pools ( https://amorpha.tnode.com/NodeMap/cidr.html ). It takes a while to load as it has to draw over 7 thousand subnets, but when it’s done, you can clearly see which space is used and which isn’t. The map also provides a way to zoom in on different subnets of wlanslovenia giving a better look into how they are composed.
Reports about progress will be posted to developers mailing list ( https://wlan-si.net/lists/info/development ). 
Me, my sumbrero and I are read for the summer of code
Adiós!
——————————————————————————————————————————————————————————————————————————————————————————-
Pozdrav!
Sem študent računalništva, ampak večina mojega znanja prihaja iz mojih diy projektov. Sem “jack of all trades”, zanimajo me vse stvari, od nizko nivojnega programiranja čipovja ter fpga-jev, vse do UE4 gaming engina, blender animacij ter drugih visoko nivojskih programskih problemov. Rad se ukvarjam z vizualizacijo podatkov, kot recimo vizualizacije glasbe, grafov in drugih interaktivnih načinov prikazovanja podatkov. To poletje bom pomagal z izboljšanjem načinov prikazovanja podatkov, ki jih ima nodewatcher.
Moj projekt ima dva glavna taska; Eden je izboljšava že obstoječih grafov, drugi projekt pa je narediti čisto novi način prikazovanja uporabljenega ip prostora v nodewatcherju. Nodewatcher vsebuje dosti grafov a le ti bi lahko bili izboljšani. Podatke je težko razumeti, brez pravilne reprezentacije. Moje znanje d3.js mi bo pomagalo narediti interaktivne, responsive grafe ki bodo izboljšali prikazovanje podatkov. Izboljšanje grafov je zelo pomembno saj ljudje, ki prvič odprejo nodewatcher težko razberejo vse podatke in se lahko zgubijo, če ti niso pravilno prikazani.
Moj drugi del, bo čisto nova mapa na kateri bo narisana proaba ip prostora. Do zdaj ni bilo dobenega načina kako si predstavljati ip pools, ki jih nodi uporabljajo. Gledati po stotine subnetov v tekstovni obliki je zahtevno in zelo težko. Ta mapa bo prikazala kateri prostor je že uporabljen in kateri je še prost. Naredil sem majhen prototip, ki prikaže wlanslo ip prostor ( https://amorpha.tnode.com/NodeMap/cidr.html ). Traja kar dolgo da se izriše saj obstaja preko 7 tistoč subnetov, ampak ob koncu lahko vidimo kako je ip prostor uporabljen. Ta prototip vsebuje tudi wlanslo subnete na katere lahko približate tako da lahko vidite hirarhijo dela omrežja.
Moja poročila bodo objavljena na (  https://wlan-si.net/lists/info/development ).
Jaz ter moj sumbrero sma pripravljena na poletje kodiranja.
Pozdrav!

Der Beitrag Summer of code: Week 1 erschien zuerst auf Freifunkblog.

08:28

GSoC 2017 Attended Sysupgrade

GSoC 2017 – Attended Sysupgrades

Hello, my name is Paul Spooren and I’ll be working on attended sysupgrades this Google Summer of Code. I’m 24 years old and studying computer science at the university of Leipzig. With this blog post I try to explain my project, the advantages and it’s challenges.

Topic Change from captive portals.

When I applied to GSoC my first application covered the implementation of “Captive Portals” for the LibreMesh. After discussing details with my mentors we decide to switch the project.
The main shortcomings where the following:
* Captive portals need testing on all kind of devices, Apple devices using a different approach than Android, Linux distribution differ, all kinds of Microsoft’s Windows as well. Testing would claim to much effort to provide a stable solution
* Captive portals usually intercept HTTP traffic and changing it content with a redirect to the login provider’s splash page. This does not work with encrypted traffic (https) and would result in certification errors.

Discussing what has generic use to OpenWRT/LEDE and LibreMesh we came up with the topic of a simple sysupgrade solution and fixed on that.

What are attended sysupgrades?

Performing updates on routers is quite different from full Linux distribution. It’s not always sustainable to do release upgrade via a packet manager. Instead it’s usually required to re-flash the system image. Depending on the installed packages an image rebuild may be to complex for regular users. A more convenient way is needed.

The main idea is to provide a simple function within the web interface to automatically download a custom sysupgrade-image with all currently installed packages preinstalled.
An opt-in option would check for new releases and notify via luci(-ng) or command line.

This approach would also help to upgrade a router without full computer hardware. The web interface can be accessed from mobile phones and as no complicated image downloading is required all users can perform sysupgrades on their own.

Distributions like LibreMesh may have a more frequent package release cycle and devices may don’t offer opkg due to limited flash storage. The simple sysupgrade approach could be used as a opkg replacement for these special cases and keep devices up to date.

How does it work?

The web interface will have a new menu entry called “Attended Upgrade”. The page send the currently installed release to the server and checks it response. If an upgrade is available a notification will be shown. A click on the download button sends a request to the server and downloads the image. Another click uses the sysupgrade mechanism and installs the image. After reboot the system should run as excepted with all before installed packages included.

This project will implement an “image as a service” server side which provides custom build images depending on installed packages. A JSON API will enable routers to send requests for custom images. Build images will be stored and reused for other requests with the same package selection and device model.
A simple FIFO queue will manage all builds requests. Created images will be stored by priority queue system so most requested combination are always in cache.

Challenges

* With new releases packages may be renamed. This can be due to a split after growing in size as more and more features are added or if different versions of a tool exists. The update server has to know about all renamed packages and created an image with all needed programs. Therefore a replacement table will be created which can be managed by the community. Merges, splits and new naming convention will be covered. To make updating easy the server will try to handle changed names as automatic as possible. If there exists different possibilities to choose from there will be a menu in the web interface.

* Currently luci is the de facto web interface of LEDE/OpenWRT. Eventually it will be replaced by luci-ng with a modern JavaScript framework. All router sided routing has to be easily portable to the new web interface.

Implementation details

The main logic will happen within the browser and so can use secure HTTPS to communicate with the update server. The users browser communicates between router and upgrade server. The following diagram tries to illustrate the idea.

Once opened the upgrade view will ask the router via an rpcdcall to receive the installed release and send the version to the update server as an *update availability request*. The server will answer with an *update availability response* containing information about the update if exists or a simple status 204 (No Content) code. If a new release exists the web interface will perform another rpcd request to get details of the device, installed packages versions and flash storage. The information are then combined and send as an JSON request to the update server as an *image request*.

The update availability request should looks like this:

{
    "distro": "LEDE",
    "version": "17.01.0",
    "packages": {
       "opkg": "2017-05-03-outdated"
       ...
    }
}

The update server will check the request and answer with an *update availability response*:

{
    "version": "17.01.1",
    "packages": {
        "opkg": "2017-05-04-new",
        "ppp-mod-pppoe2": "2.0"
    }
    "replacements": {
       "ppp-mod-pppeo": "ppp-mod-pppoe2"
    }
}

The response contains the new release version and packages that will be updated. Not that even if there is no new release, packages could be updated via a sysupgrade. The idea is that packages without opkg installed can receive package updates as well.

All changes will be shown within the web interface to let the user know what will change. If the user accepts the upgrade an request will be send to the server. The image requests would look something like this:

{
    "distro": "LEDE",
    "version": "17.01.0",
    "revision": "48d71ab502",
    "target": "ar71xx",
    "subtarget": "generic",
    "machine": "TP-LINK CPE510/520",
    "packages": [
        "ppp-mod-pppoe2": "2.0",
        "kmod-ipt-nat": "4.9.20-1",
        ...
     ]
}

Once the update server received the request it will check if the image was created before. If so it will deliver the update image straight away. If the request (meaning device and package combination) was done for the first time a couple of checks will be done if the image can be created. If all checks pass the wrapper around the LEDE ImageBuilder will be queued and a build status API is polled by the web interface. Once created a download link is provided.

In the unlikely event of an unsolvable package problem the replacement table can’t fix itself the user will be asked to choose from a list. The new combination of packages will be send to the server as a new request resulting in an sysupgrade image. This approach still needs some evaluation if utilizable and really needed.

Using the ImageBuilder offers an generic way to offer sysupgrades for different distribution. The image builder feeds can be extended to include distribution specific packages like LibreMesh package feed

The replacement table could be implemented as followed:

# ./lede/replacements/17.01.1
{
   "libmicrohttpd": [
   "libmicrohttpd-no-ssl": [
       "default": true
    ],
    "libmicrohttpd": []
    },
    "openvpn": [
        "openvpn-openssl" [
            "default": true
        ],
        "openvpn-mbedtls": [
            "installed" [
                "polarssl",
                "mbedtls"
            ]
         ],
         "openvpn-nossl": []
    ],
    "polarssl": [
        "mbedtls": [
            "default": true
        ]
     ]
 }

libmicrohttpd was replaced by libmicrohttpd-no-ssl (installed as default) and libmicrohttpd.
openvpn splittet into various packages depending on the installed crypto library, openvpn-openssl is the default while openvpn-mbedtls is only installed if mbedtls (or it’s prior name polarssl) was installed before.

For better readability the yaml format could be preferred.

LibreMesh introduced a simple way to manage community specific configurations. This configuration method is flexible for other communities as well and should be integrated into the update server. A optional parameter could contain the profile name which will be auto integrated into new images.

"community": "quintanalibre.org.ar/comun/",

The parameter could also contain a full domain with leads to the needed files, this feature need more evaluation.

Possible features

* The current design is an attended upgrade triggered by and dependent on the web interface. A feature could be to add logic to the command line as well.

* Once the sysupgrade is possible via shell, an unattended sysupgrade would be possible. A testing and a release channel could enable unattended upgrades for tested images (device specific) only. If an image works after an attended upgrade it could be tagged and offered via the release channel.

* Mesh protocols may change and outdated routers loose connectivity. A possible solution to upgrade the devices losing contact could be to automatically login the outdated routers to updated routers open access points, perform an update and reconnect to the mesh.

Final Thoughts?

All thoughts above are not final and are more likely an RFC. I’m very happy to receive comments and critic. My goal is to have an generic update service where all communities and LEDE/OpenWRT itself can benefit from.
Feel free to contact me at paul [a-t) spooren (do-t] de or on freenode/matrix as aparcar.

Der Beitrag GSoC 2017 Attended Sysupgrade erschien zuerst auf Freifunkblog.

06:50

GSoC 2017-netjsongraph.js: visualization of NetJSON data

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

Der Beitrag GSoC 2017-netjsongraph.js: visualization of NetJSON data erschien zuerst auf Freifunkblog.

05:02

GSoC 2017 – wlan slovenija – HMAC signing of Nodewatcher data and IPv6 support for Tunneldigger

Howdy!

I am a student at Faculty of Computer and Information Science in Ljubljana, Slovenia. Like (almost) every “computer enthusiast” I liked gaming and later found myself developing an OpenGL graphics engine. All engrossed in C++ and all sorts of algorithmic challenges I slowly came to realize that something is missing. Yes, my knowledge of anything network related. So, combining my two other interests, those being information security and inexplicable love of tunnels, I applied myself to Google Summer Of Code with the following ideas. As a participant in this year’s Google Summer of Code I will develop some new goodies for two projects of wlan slovenija open wireless network.

The first one is for the nodewatcher, which is an open source system for planning, deployment and monitoring of the wireless network. It is a centralized web interface which is also used for generating on OpenWrt based firmware images for specific nodes. After flashing the wireless router with the generated image, it just needs to be fed some electricity and it automatically connects into the network using VPN, or in case of an existing nearby node wirelessly. Nodwatcher then collects all the data about node’s performance by connecting to nodes to obtain data, or by nodes pushing their data to nodewatcher. This data is not sensitive, but we can still worry about it being manipulated or faked while in transit between the node and nodewatcher. The problem though is that all the monitoring reports are currently unsigned. This poses a security risk in the form of a spoofing attack, where anyone could falsify the messages sent to the nodewatcher. The solution is to assign a unique nodewatcher signing key to every node. The node will then sign the monitoring output using a hash function in HMAC (Hash-based message authentication code) mode. This means that a computed “signature” would be sent along with every message and nodewatcher can check whether the data was altered in any way. In the event of a signature verification failure a warning will be generated within the nodewatcher monitoring system. This is imporatant, because it assures the integrity of recieved data and inspires confidence in using it to plan deployment of new nodes in the future.

The second contribution will be to the Tunneldigger, which is a simple VPN tunneling solution based on L2TPv3 tunnels. It is used to connect nodes which do not have a wireless link between them in to a common network. Using existing network connectivity it creates L2TP tunnels between nodes. The current limitation is that tunnels can only be established over IPv4. This poses a problem because due to dramatic growth of the internet, the depletion of the pool of unallocated IPv4 addresses is anticipated for some time now. The solution is the use of its successor, IPv6. Since the tunnels are already capable of carrying IPv6 traffic, the capability of establishing them over IPv6 will be developed. The Tunneldigger will also support IPv4/IPv6 mixed environment where both server and client have some form of IPv6 connectivity. That way the Tunneldigger will finally be made future proof!

Reports about my work will be available on developers mailing list.

Yay for the free internet!

Der Beitrag GSoC 2017 – wlan slovenija – HMAC signing of Nodewatcher data and IPv6 support for Tunneldigger erschien zuerst auf Freifunkblog.

May 29 2017

23:08

GSoC 2017 – LuCI2 on LibreMesh

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.

LuCI2 – UBUS

It seems to me the right choice to interact with UBUS through an API rest avoiding the rendering of LuCI2 on the router. For now the interaction with the frontend is programmed as an AngularJS service, but it could be abstracted from the Framework, published as a separate package, strengthening the possibility of using lighter or updated Frameworks.

AngularJS, Gulp, Bootstrap, Icons….

The development of Javascript in the last years has a difficult rhythm to follow, and more than everything to maintain. Decisions about which frameworks to use may be correct at the beginning of development and look outdated when a stable release is published. This happened to LuCI2, the solution is to modularize as much as possible to make small parts reusable, agnostic and maintainable. This way, versions developed on different frameworks can coexist, mobile applications, even command line. In addition, most web libraries are not designed to take up little space. In the context of embedded devices it is problematic to choose libraries developed for the web only because they are the most popular.

Roadmap

  • Make the core elements of LuCI2 modular and abstract from the web framework.
  • Look for alternatives to AngularJS that better fit the limitations of the routers.
  • Try to implement retrocompatibility with the modules already developed
  • Document the necessary changes to migrate components.

Der Beitrag GSoC 2017 – LuCI2 on LibreMesh erschien zuerst auf Freifunkblog.

21:46

GSoC 2017 – Add MPTCP support in LEDE/OpenWRT trunk

Brief intro

My name is Ferenc Fejes. I’m MSc CE student at the University of Debrecen, infocommunication networks specialization. I glad to introduce my project which is Add MPTCP support in LEDE/OpenWRT. The main idea is from my mentor, Benjamin Henrion. If we have a Wi-Fi mesh network, there are probably more than one network path between the nodes. The point is, we can gain additional throughput if we use those path simultaneously.

The goal

Currently no MPTCP support in GNU/Linux nor Windows systems. So the key is, the user using regular TCP/UDP at his system until the first hop, which is a LEDE box with MPTCP support. At this point, this router operating as an intercepting proxy: read the incoming traffic from the host, and distribute that on multiple interface, using MPTCP. At receiver side, we can do the same but in reverse order: get the data from the MPTCP connection and send is to the sink host in regular TCP (or UDP). With this operation, the whole MPTCP transmission remains hidden for the end hosts, but they will enjoy the gain from it – because MPTCP has a good capability to aggregate the bandwitdh of the different paths. Of course, if the bottleneck between the end host and the first hop, the user did not get any gain from this operation.

The plan

The key steps for reach the goal of the project:
1. Set up virtual/real machines with MPTCP support. This is not a problem since kernel patches for MPTCP support available.
2. Make a simple multipath topology: end hosts with no MPTCP support, two machine with MPTCP support, functioning as a router and has two different network path between them
3. Search and configure an efficient and transparent proxy software on them, which can suitable for intercept TCP traffic and work as a tunnel for other protocols (like UDP, SCTP, etc.)
4. Reproduce the working configuration on LEDE supported devices, with two Wi-Fi bridge links between the LEDE boxes.
5. Verify the aggregation with iperf3 measurements.

Der Beitrag GSoC 2017 – Add MPTCP support in LEDE/OpenWRT trunk erschien zuerst auf Freifunkblog.

18:52

geolocator (Software defined GPS)

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 are 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 this will be cleared 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 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 redundancy software, i discuss with Zeeshan, the maintainer of geoclue, to build support in gps-share for standalone GPS [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 receiving by its surrounded WIFIs. The WiFi informations should send to the new above mentioned backend[4].
cheers
Jan-Tarek Butt

Der Beitrag geolocator (Software defined GPS) erschien zuerst auf Freifunkblog.

14:07

GSOC 2017 – Implement NetJSON output in ubus (OpenWRT/LEDE)

The main aim of the project is to bring in support for NETJSON object in the LEDE/OpenWRT Linux distributions. The support for NETJSON is brought in at the interconnect system- ubus. In this project, we need to add support for a new ubus API which allows retrieving these two NetJSON object types: DeviceConfiguration and DeviceMonitoring.

What is NetJSON ?

NetJSON is a data interchange format based on JSON designed to ease the development of software tools for computer networks. This specification defines several types of JSON objects and the manner in which they are combined to represent a network: configuration of devices, monitoring data, network topology and routing information.

Why NetJSON is important to OpenWRT/LEDE ?

 Network infrastructure is deeply closed source. Open source won the battle in web development and system administration, but not in network management. The status-quo in networking is closed source software, poor interoperability and poor documentation.
NetJSON aim to challenge the status-quo and improve the openness of internet infrastructure by offering a set of tools (like a framework) which communities and companies can use to build network infrastructure using mainly open source software products.
  1. NetJSON would allow standardization similar to NETCONF. Since NetJSON uses JSON format, it makes the management of configurations done at a higher scale to be automated easily.
  2. By using NetJSON objects to either produce or collect information, in different vendor’s different hardware, it allows the developers to work on their ideas faster and in a better way.

Project goals:

  • Bring CLI support to accommodate the new parameters: DeviceConfiguration and DeviceMonitoring.
  • Write backend ubus APIs to collect the data and store the data in NetJSON objects: DeviceConfiguration and DeviceMonitoring and display them.
  • Revisit the implementation of JSON plugin in SCAL and try to extend the support for NetJSON. For the missing data models in the JSON plugin, try to write a data parser which uses the scal APIs to get data and convert that into NetJSON format and store in the DeviceConfiguration NetJSON object for outputting it.
  • Adapt the code in node-watcher agent and reuse it in SCAL as a plugin. This plugin should output the monitoring data in a NetJSON DeviceMonitoring format..
  • Writing makefile to compile the files added for supporting NetJSON in the ubus IPC/RPC system in OpenWRT/LEDE distribution.
  • Document the work done, installation guide and usage examples of the new CLIs.

Project Details:

  • CLI support: The CLI should be able to input the required data and display error message if entered wrongly. Generic CLI: ubus call netjson <config | monitor> <general | network | interface | none_to_display_all> <parameter | none_to_display_all> Example CLI: ubus call netjson monitor interface eth0 .The above CLI would display all the statistics related to eth0 in the DeviceMonitoring NetJSON format. CLI depth should be increased for certain commands like the interface and network entries to get the interface name. The cLI backend tool would be a separate API which calls the SCAL plugins.
  • ubus call netjson API support: We should register the namespace netjson in the libubus. This allows the procedures with any number of arguments.
  • NetJSON objects: SCAL is an abstraction layer to push information onto the ubus from the device.  SCAL allows gathering data on the device from UCI, ubus calls, shell commands, etc and publishes it on the ubus using a different datamodel. Already available SCAL JSON plugin takes these data models and convert it into a JSON format. My work involves extension of this plugin to support the NetJSON to be done. Add features to the JSON plugin in C which is needed in order to define the full data model using the NetJSON schema. Also for data formats which doesn’t have support in the SCAL JSON plugin, parse the scal datamodel and then store in a DeviceConfiguration NetJSON object. This is SCAL plugin is created for retrieving the information directly using C.

Timeline:

  • May 30th : GSOC coding officially begins.
  • Task to be completed by the 2nd June: Bring CLI support for the above things to be implemented. Test the CLI and check if error cases are handled by the CLI.
  •  5th June to 8th June: NetJSON DeviceMonitoring and DeviceConfiguration objects/schema structures to be defined in the ubus architecture. ubus call netjson API support is to be implemented in this time period.
  • June 12th till June 16th : Implement the NetJSON DeviceConfiguration to be retrieved for the whole device. The whole NetJSON DeviceConfiguration would be the output. SCAL plugin to be added to support the NetJSON format in C itself. Also try making changes to the exisiting JSON plugin to transalate it into the NetJSON format.
  • June 19th to 23rd : Based on the inputs provided in the CLI, output the DeviceMonitoring NetJSON object. For eg: “ubus call netjson config interface wlan0 status
  • June 26th : Demo to the OpenWRT/LEDE community apart from the mentors to get feedback. Based on the feedback improve the implementation.
  • June 26th to July 7th: Implement the NetJSON DeviceMonitoring to be retrieved for the device in whole.
  • July 8th to July 20th : Based on the inputs provided in the CLI, output the NetJSON DeviceMonitoring object. For eg: This CLI would only output monitoring data for wlan0. “ubus call netjson monitor interface wlan0”
  • July 20th : Demo to the OpenWRT/LEDE community apart from the mentors and get feedback.
  • July 21st to July 27th : Improve the implementation based on the feedback from the community.
  • July 28th : Phase 2 evaluation.
  • July 28th to August 17th : Send the NetJSON objects in a HTTP message based on the HTTP GET request message. Use existing libraries in ubus architecture to send the data based on the request message.
  • August 18th to August 21st : Improve upon any possible design based on the Mentor feedback and community feedback.
  • August 21st to August 24th : Code cleanup, final documentation review and possible merge/commit to the LEDE/OpenWRT distribution or ubus.

Der Beitrag GSOC 2017 – Implement NetJSON output in ubus (OpenWRT/LEDE) erschien zuerst auf Freifunkblog.

08:52

GSoC 2017 Project – OpenWifi: LEDE/OpenWRT configuration Mangement

GSoC 2017 – OpenWifi

Hi, my name is Johannes Wegener and I’ll be working on OpenWifi this Google Summer of Code. I’m 27 years old and study computer engineering at TU Berlin. In this blog post I’m going to explain to you what OpenWifi is and what should be done during this summer of code.

What is OpenWifi?

OpenWifi is a OpenWRT/LEDE configuration management system. It is intended to manage a bigger or smaller amount of OpenWRT/LEDE devices.

If a new access point joins a network it is be able to auto detect the management Server and register to it. After the node has been registered its configuration (static configuration like what you’ll typically find in /etc/config/ on OpenWRT/LEDE devices) will be downloaded by the server and stored in a database.

It is now possible to query and modify aspects of the configuration. It also possible to change values depending on other values. This means configuration changes can be applied to a lot of different routers. There is an older templating system which shall be replaced by a new graph-oriented one. It also manages SSH-Keys, has a rudimentary file upload functionality (for uploading new images for example) and extensible API. It is possible for example for a node to ask for an image it should install. (Currently this is not very dynamic – but it is intended that an image could be selected on various parameters)

The Server also regularly pulls the health-state of the node and displays it in an overview. Furthermore the server acts as a luci2 proxy.

It is also extensible via PlugIns and is able to serve as an entry point to other services like icinga or location services. (Both already have a proof of concept PlugIn available)

How does it work? aka what makes it tick?

The main software is written in python and uses the pyramid framework and sqlalchemy as ORM. It uses pyramid-rpc for json-rpc requests (which is used for nodes to register for example) and cornice for a REST-style API (which is intended for the user of the system). The Core-System can be found in this repository .

Most of the tasks operating on nodes are done by a jobserver that uses celery – so that they don’t block the main thread.

All Webviews have been moved to a different repository and are realised in fact as a PlugIn. (If you just want to manage your nodes on CLI/with scripts this will be possible in the near future!)

The nodes use a notification script written as a shell script. It uses a fixed DNS entry (openwifi), a configuration file (/etc/config/openwifi) or mdns (using umdns or avahi) to detect a server and register to it. The packages can be found in the openwifi-feed repository . There is also a boot-flasher which is intended for flashing an alix2-style board from ramfs – since it is also possible to execute commands on the node I’ll integrate an update solution that uses sysupgrade.

The communication between the server and the node is realized currently via rpcd. But one goal during this Google Summer of Code is to abstract that and realize it via a rpcd-communication-PlugIn – this would make it possible to also a NetJSON-communication-PlugIn for example.

The PlugIns are realized with python entry points . There are some special named entry points which will extend the main application. You could have a look at the example plugin to get an idea how it works.

How to try it?

You can easily try the software with docker . Navigate to the Docker directory – there three files that will assist you with the setup. In conf.sh you setup if you want to use LDAP for authentication, avahi for mdns announcement and dnsmasq as dhcp server in the docker container.

With build_image.sh you build the docker image. It tries to detect if you need to use sudo for docker or not. Last but not least you need run_image.sh to start the image.

You can easily add PlugIns to the docker image if you just check them out or copy them inside the Plugins directory. To start off I would recommend to add the Web-Views Plugin and use avahi. Now you can navigate your browser to http://localhost:6543 to see the webviews (you need to restart the container after Plugin install – use docker stop OpenWifi and docker start OpenWifi).

What is needs to be done?

In the next section I’ll explain what should be done during Google Summer of Code. I need to prioritize these things because I’m not sure if it is possible to do everything. I think most important things are Testing, Authentication and the new graph-based database model.

Testing-Infrastructure

Currently just very few things have tests. But because it is possible to start a LEDE container in docker (there are some scripts helping to create a LEDE container in the Docker/LEDEImage directory) a lot of things are possible to test with docker orchestration. I want to provide a small LEDE image with the code to test it.

Before adding big new things I like to transfer the development to true test-driven development and having test for at least 90% of the core component code. And after that continuing development by writing tests first.

For that I would also have a look at coverage.py .

Security and authentication

There is a simplistic authorization for OpenWifi with a LDAP backend. I would like to add authorization based on user/password (without LDAP), API-Key and client side certificate (for the nodes to authenticate theirself against the API).

I would like to have the authorization as granular as possible. Authorization should check whether the authorized identity is able to operate on this node and what kind of action is allowed.

Security is provided by TLS. Last week I added the last bits to also use https for client communication – but right now it needs to be setup up by the user. I would like to add the appropriate hooks to the notification shell script.

Expand new graph-based DB-Model

The new DB-Configuration model is based on a graph – where configurations can be connected by links (the link can contain addition information – like what kind of link it is – currently the addition data is the option name (for example if you have a wifi-iface configuration the “device” links it to a wifi-device)).

The model is implemented and there is a query API to get and set options. But for communication purposes the configuration is stored as uci-json-config. There is code to convert between these two (but the one from uci to graph-model needs quite some more intelligence to detect everything right). There are also some hooks that update each part. But the update process is not consistent – the graph-based config gets a new ID for example. It would be nice to have a consistent conversion.

Furthermore I like nodes to share parts of a configuration. This should be easy to implement with some small DB changes. For this consistency is also very important. By default UCI generates unique strings for every configuration – this could be used for consistency.

The DB-Model also currently lacks creating new configurations and reordering configurations.

API

The API to modify nodes should get expanded and everything should get documented. (see above) This should be done in code and a document generated by sphinx.

I also like to implement a CLI program to use the API.

Versioning

The uci-json parser supports diffs between configurations. I would like to save a diff for each change which is applied – to have roll back configurations or delete a specific change.

There is a simplistic revisioning implemented. But the diff should be updated to a class of its own with json import and export and operations to apply a diff to a UCI configuration. (upgrade and downgrade)

Modularity and expandability

OpenWifi is right now is already quite modular – but I also want to modularize configuration parsing and communication. It would also be nice to have some interoperability with OpenWISP .

I use alembic for tracking database changes it would be nice to find a good way to use alembic for database changes needed by PlugIns as well.

Scheduled Updates

I want to schedule config updates – for example if you have a mesh you probably want to update the deepest nested nodes first and than the ones above etc. – this should be easy with celery (as long as the mesh is known and somehow represented in the database).

Der Beitrag GSoC 2017 Project – OpenWifi: LEDE/OpenWRT configuration Mangement erschien zuerst auf Freifunkblog.

May 21 2017

18:12

PowQuty Live Log introduction

Hi everyone,

I’m Stefan and happy to present my GSoC 2017 project to you.
That is extending the PowQuty daemon and luci web-app with an event log and notification system for events violating the EN-50160 norm.
Probably most of you don’t know powquty. Therefore i will give a short introduction to it, before I present my actual project.
 

PowQuty

PowQuty[1] is an application for measuring power quality parameters of the power grid like voltage and frequency. It receives samples by a USB connected oscilloscope and writes the calculated values to a log file. This log can be read by the powquty luci web-app. The web interface will plot the measurements directly into several graphs. These are power over time, frequency over time and metrics over time.
It was implemented during the last GSoC by Neez El Sayed [2] and its intention is „to strengthen the role of open software in the uprising smart grids by providing some essential functionalities”.
 

PowQuty Live-log

The goal of this project is to provide an event log of measurements that are outside defined parameters.
Public power distribution networks have to meet certain criteria. These are formulated in the EN50160 norm.
If there is a power drop, or a frequency spike PowQuty will write this to its log like every other value. The user can examine the log file or its graphical representation for critical values, but essential equipment could already be damaged.
If such an event occurred, a user or power network administrator should be notified. This event log will get a graphical interpretation in the luci powquty app as well to enable a better tracking of events.
This will allow users of PowQuty to react quickly to changing conditions in power supply networks.

Therefore we will add a notification system to PowQuty as well as additional logging options.
To collect events at a central server we will extend the mqtt usage to send an mqtt notification on a violating event.
In addition we will add an email and slack notification option to allow quick responses.

 

[1]: https://github.com/thuehn/PowQuty
[2]: https://blog.freifunk.net/author/Neez-El-Sayed/

Der Beitrag PowQuty Live Log introduction erschien zuerst auf Freifunkblog.

May 14 2017

20:11

Our GSoC 2017 projects

In 2017 we got 15 slots for our projects. That’s great, we’ve never got so many slots for GSoC before. Our students are from 8 countries. They do their work for 6 sub organizations.

Until the end of May the Community Bonding Period takes place, so students can introduce their projects to the community. They also prepare together with their mentors the folling coding period.

This post will give a short overview on the selected projects. In the next weeks some detailed blog posts will follow describing all the projects.

GSoC project overview

Title Org Student Abstract RetroShare Improvements retroshare ange The aim of this proposal is to improve RetroShare incrementally during the summer in the following work lines:
– Semi-automatic RetroShare friendship suggestion based on phone contacts
– Semi-automatize JSON API code and documentation generation
– Multiple simultaneous heterogeneous network connection for each peer
– Improve RetroShare Android usability and performances
– Seamless key exchange via Quiet Modem
– Chat and messages multiple device synchronization
– Directories multiple device synchronization Implementing Pop-Routing in OSPF ninux Gabriele Gemmi Prince is a network daemon that continuosly monitors the network topology and sets the timers for OLSRv2, it is developed in C and we are currently deploying it in the Ninux community network in Florence. This year
we want to implement Pop-Routing for another link-state routing protocol: OSPF. OSPF is the state-of-the-art interior routing protocol for wired networks and it is used also in some wireless community networks. This
project consists in realizing a plug-in of the OSPF open source routing daemon (Quagga or Bird) that will:
– Expose the network topology to Prince using NetJson
– Receive and re-set the network parameters from Prince Improving nodewatcher data representation capability wlan slovenija rasovica Currently nodewatcher has very limited overview of used IP space without more precise division of existing and used subnets. This could be improved using compact and colorful matrix with IP ranges and links to nodes. I would display data about used ips similar to the [IP Census 2014](http://census2012.sourceforge.net/images/hilbert_icmp_map_lowquality.jpg), better tables and other data representation that would help explain the network structure, it would help in explaining the network and its statistics even to an uninformed observer. I would also update the look and functionality of other graphs and tables representing statistical data from nodewatcher Extending LoxiGen and ONOS to enable SDN control of wireless switches via OpenFlow lede Arne Kappen LoxiGen is a tool by the Floodlight project to generate OpenFlow libraries for several programming languages including Java and C. The goal of this project is to extend LoxiGen to include messages for controlling wireless switches using OpenFlow.
It will include the necessary extensions to LoxiGen as well as a proof-of-concept implementation of the control channel. This encompasses an application for the ONOS SDN controller and an agent for the LEDE router operating system.SDN-enabled wireless switches offer comfortable centralized management of larger deployments and may provide the basis for more complex use-cases in the future such as network slicing and seamless mobility. OpenWRT/LEDE Configuration Management lede Johannes Wegener Improve the proof-of-conecpt version of a OpenWRT/LEDE configuration software. Web interface for Retroshare, a secure communication software retroshare Stefan Cokovski I am applying to work on the web interface for RetroShare, secure communication software. RetroShare already has a web interface with limited functionality and questionable look, compared to the main Qt GUI which RetroShare uses. My goal will be to improve the already present functionalities, introduce new functionalities to the web interface and design a new look for the web interface. Implement NetJSON output in ubus (OpenWRT/LEDE) lede Arunkumar Ravichandran To bring in support for NETJSON object in the LEDE/OpenWRT Linux distributions. The support for NETJSON is brought in at the interconnect system- ubus. To add support for a new ubus API which allows retrieving these two NetJSON object types: DeviceConfiguration and DeviceMonitoring.
DeviceConfiguration NetJSON object is filled in using the plugins available in System Configuration Abstraction Layer(SCAL).
DeviceMonitoring NetJSON is retrieved by reusing the code parts and adding hooks in the nodewatcher-agent. LibreMesh Captive Portal and Access Control libremesh paul0 LibreMesh could need an splash page with information about services usable offline as well as an captive portal to manage access control. Both should be configurable via the webinterface.

This proposal is based on the following Freifunk idea:

LibreMesh Captive Portal and Access Control

https://wiki.freifunk.net/Ideas#LibreMesh_Captive_Portal_and_Access_Control

Spectrum Analyzer libremesh Nicolas Andres Pace I believe that Community Networks‘ Operating Systems could use the Spectrum Analysis a lot to make better decisions on how they use the electromagnetic field wisely and efficiently.

As of now, no Free OS has been using Spectrum Analysis, so they can’t know whether the radios are being used efficiently or not.

This module would allow all routers that use Atheros radios (the main radio manufaturer around) to see how is the spectrum and take better decisions on which channels they use.

Deliverables
* Create an OpenWRT/LEDE package to get Spectrum info from the radio.
* Create a LuCI interface to visualize the Spectrum information retrieved.

HMAC signing of Nodewatcher data & IPv6 support for Tunneldigger wlan slovenija red_moo Currently all monitoring reports by WLAN nodes are unsigned and can be spoofed by anyone. This represents a security problem and a possible solution is to add HMAC-based signing to encrypt node monitoring reports to prevent spoofing.
Nodewatcher’s monitoring system will also be improved so it will generate an event and a warning in case of a signature verification failure.The aim of the second part of this GSoC project is to design and implement IPv6 support for Tunneldigger so that it works in IPv6-only and IPv4/IPV6 mixed environment where both server and client have IPv6 connectivity in some form. Add MPTCP support in LEDE/OpenWRT trunk lede SPYFF Create an MPTCP supported OpenWRT/LEDE trunk and ensure its operation in a multipath Wi-Fi aggregation environment. The trunk should contain the tooling for establish a SOCKS proxy for operating systems without MPTCP support. geolocator (Software defined GPS) FF Nordwest Jan-Tarek Butt A dynamical and flexible geolocator which should provide a software defined GPS device and receives its position over WIFI hardware with various services like openwifi.su, MLS and etc. netjsongraph.js: visualization of netjson data ninux GeekPlux NetJSON is a great work attracted some interest from around the world, but there are a lot of defects. And I’m a front-end developer and now focus on Data Visualization, so I want to contribute to NetJSON. In my proposal, I come up with my idea and list some tasks and schedules. lime-webui: port to LuCI2 libremesh Marcos Gutierrez Make an inventory of all LuCI components that LibreMesh uses and that will not be compatible with LuCI2. Analyze which dependencies must be replaced or rewritten and generate the views according to the new framework selected. Powquty Live-Log lede Stefan Venz PowQuty provides statistics from measurements taken by a USB oscilloscope. The statistics provide information about the power distribution network, but don’t highlight the most important information. Power networks need to comply with EN50160, if this norm is violated, damage to connected devices is possible.
To avoid damage, powqutyd will log violations and notify users on occurrence.

Der Beitrag Our GSoC 2017 projects erschien zuerst auf Freifunkblog.

March 05 2017

11:04

GSoC 2017 and Freifunk: Students wanted

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)

Der Beitrag GSoC 2017 and Freifunk: Students wanted erschien zuerst auf Freifunkblog.

March 01 2017

20:59

Runderneuerung blog.freifunk.net

Unser Freifunkblog ist auf eine neue Plattform umgezogen. Das alte Drupal 6, das sein Lebensende längst erreicht hat und keine Updates mehr bekam, haben wir abgelöst und die Inhalte nach WordPress migriert. Nun ist das Blog mit neuer Technik unter der Haube und neuem Design für die nächste Zeit gerüstet. Der älteste Artikel im Blog ist im Übrigen über 11 Jahre alt und stammt aus dem Jahr 2005.

Zugang zum Blog

Alle Artikel, Schlagwörter und Autoren sind erhalten geblieben. Frühere Benutzer wurden wieder angelegt, nur die Passwörter  haben wir nicht übernommen. Die Anmeldung kann mit der beim alten Blog verwendeten Emailadresse erfolgen. Mit der „Passwort vergessen“-Funktion kann man ein gültiges Passwort erhalten. Bei Problemen mit der Anmeldung schreibt bitte eine Email an das Webteam (web(at)freifunk.net).

Wer noch keinen Account auf diesem Blog hat und einen hier Freifunkartikel veröffentlichen möchte wendet sich bitte auch an das Webteam. Gerade für communityübergreifende Themen eignet sich diese Plattform.

Aufräumarbeiten

Einige Bilder lassen sich leider nicht mehr auffinden, da sie extern eingebunden waren und nicht mehr online sind. Auch der in Drupal integrierte Editor hat manchmal ganz schön viel unsinnigen HTML-Overhead erzeugt und führt auch unter WordPress zu komischen Formatierungen. Diese ließen sich nicht automatisiert aufräumen, das ist wohl mal ein Thema für einen Editathon :).

 

Der Beitrag Runderneuerung blog.freifunk.net erschien zuerst auf Freifunkblog.

August 22 2016

22:53

Implementing Pop-Routing – Final Evaluation

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

Der Beitrag Implementing Pop-Routing – Final Evaluation erschien zuerst auf Freifunkblog.

19:53

Implementing Pop-Routing - Final Evaluation

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

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl