[WLANware] Freifunk Google Summer of Code, my introduction and proposal

Philipp Psurek philipp.psurek at gmail.com
Sat Mar 26 20:00:44 CET 2016


Hi Linus,

Am Samstag, den 26.03.2016, 13:41 +0100 schrieb Linus Lüssing:
> Great that you are interested in joining GSoC :). Your previous
> experience with wireless community mesh networks would definitely
> be helpful.

Thank you Linus. I had this spontaneous idea one hour before deadline
and managed to complete uploading my applications 15 seconds before it
would be to late.

> On Fri, Mar 25, 2016 at 07:44:35PM +0100, Philipp Psurek wrote:
> > 
> > [...] and kill some bugs I’m dealing with every day using
> > Freifunk.
> Could you also imagine looking into batman-adv, too? 

Frankly: this would be great. I understand what batman-adv is doing,
but for me it is a big mystery how its doing and what the 18k lines of
code are doing at all. This is also a reason why I choose to study
Information Technology.

> It would
> probably be a task where you would need to be prepared to not
> seeing "immediate progress", the barrier of entry is quite high, I
> think. Learning about various locking techniques, commonly used
> kernel data structures and even setting up some sort of test bed
> to be able to quickly make and test changes to the kernel module
> will take several days to start with.

I recently learned to write in C. Next course in Summer will be
Algorithms and Data Structures. For me it will definitely take more
than several days to dive in. But this stands on my to do list in the
next years, so why not now. I appreciate if you could provide me a set
of literature “form zero to batman-adv” in English or German. I could
visit my university library, start studying this now and tell you if I
understand the stuff soon or far in the future. batman-adv code is well
documented but I don’t know where to start to understand this.

A few days ago I tried to experiment with the snull interface form [1]
but the kernel API has changed … The reason was to learn how to port
fastd in the kernel space to save software interrupts on the supernode
gateways. Bad idea without knowledge and guidance.

> On the other hand, you would definitely learn a lot about
> operating and embedded systems on the way which could be handy for
> your studies and future :).

Yesterday I realized that participating in GSoC is a great opportunity
for me, for Freifunk and for me doing things for Freifunk.
Understanding batman-adv code is one of my tasks in the future. Doing
so I can see and know if I can try to port it on an FPGA and who knows,
it could be an ASIC someday, providing a cheap, low powered network for
all. But I’m at the early beginning of my journey studying IT. I know
the protocol is not written in stone, designing batman hardware is a
long term goal and if I learn more I could also realize that this is
not a good idea …

> Or are there any other favourite bugs or tools to debug you
> currently have in mind?

My biggest bug recently was mixed use of fastd and L2TP with batman on
a multi core server [2]. But due to the beginning of my study there was
no time to write a bug report and trace the issue. I’ve been told multi
core debugging tends to be impossible. But this does’t occur on single
core. In the past I had the time to report a bug [3], that has been
fixed [4].

The usual – I don’t know if I can call it so – bug are the many
broadcast. Batman deals with DHCP. I’m sure B-Tree search for ARP or
ICMPv6 Neighbor Discovery for example could be implemented … but first
I have to really understand the batman code …

> > * ad-hoc switching to the new batman-V protocol
> Being able to migrate from one routing protocol to another in a
> safe way is also a high priority item on the ToDo list of Gluon.
> There are some ideas for an "autoupdater-ng" for Gluon and your
> previous experience and ideas would probably suite that quite
> well.
> 
> Afaik Matthias wanted to develop a new configuration
> infrastructure for OpenWRT first which might result into a
> "dependancy issue", in that this task might need to be finished
> first before an autoupdater-ng could be started. So it seems
> a bit too early for the "autoupdater-ng" for this GSoC - even 
> though I personally would love to see this done as soon as
> possible :).
> 
> If you are really interested in this, maybe we could have a quick
> talk on IRC or phone with Matthias ak neoraider?

Since I stopped using the Freifunk-Advanced firmware, I didn’t really
dive into the firmware (gluon) due to time and stuff round me. But
understanding Gluon components will be no problem.

> > * making some marginal node setting changes without breaking user’s
> > security
> Again, would need a little more explanation of what you think
> could be improved, I think. You can simply build a package and add
> it, but maybe you have some ideas about how things could be done
> easier? What were your experience with adding the custom changes you
> wanted to make via a package?
Many Freifunk users don’t know what kind of treasure they’re putting on
their windowsill. After the set up (which hasn’t even been done by
them) they realize only the AP with internet inside. Some even don’t
know the node is able to mesh; not speaking about changing some node
values:
* reducing TX power due to many nodes on small area
* disabling uplink due to its slowness and better uplink not far away

Freifunk is a decentralized project, but most users expects “support”.
I do not want to log in to someone’s node. I rather would serve signed
UCI commands for certain node-ID.

> > * a radio (batman-adv) based model car …
> You mean RC cars?
Yes

> That sounds like fun, would definitely want to
> join myself :D. I can already envision a swarm of "batmobiles"
> roaming through the streets, avoiding obstacles and trying to
> maintain a connected mesh cloud while trying to maximize coverage.
There is a old railway track near my hacker space. It has been
converted to a foot/bicycle path. We plan Freifunk along this track. At
night, when there are less people, it would be fun driving along this
track: a camera streams the view, the car receives commands from mesh.
A (fast) Mars Rover on Earth ;-)

> Not sure about the priority for a Freifunk GSoC project, though.
There is no priority IMHO. Only an idea.

----

There is much to do for Freifunk. Frankly I can’t choose any of the
projects, because they are all worth to do. There are so great ideas
for GSoC in the FF wiki. After 1st term I’have to prepare and learn for
each of them if there’s code hacking involved to produce results. But
it will be worth it.

My main interests in Freifunk is the substructure: firmware, protocols,
and a clean, smooth mesh network, which acts automatically and is
immune to errors and threats.

Linus, tell me please: will I be able to contribute something to
batman-adv during this GSoC if I, as a C newbie, start learning all the
kernel stuff now? I’m willing to do so, but I’m also afraid not being
able to provide any results on time. I’ll need a lot of mentoring and
guidance if I should be picked for batman-adv.

On the other side I know OpenWrt, can build packages and can do stuff
on the minimalistic system, but I don’t know what happened with that in
the last two years. I’m happy with the UCI subsystem and didn’t know
this is an issue. If there is no space left in Gluon on the tiny 4 MiB
space, switching to musl or using only the basic stuff provided in
OpenWrt or even building Gluon modular for a certain purpose could be
an option.

… again: many ideas, less knowledge implementing them. But I know how
to read and use the library. It would be great participating, relay
participating in FF development.

I’m looking forward for a mumble session or a phone call next week. I’m
not really fluid in English, it take much time and it’s a kind strange
to write in English in a German mailing list.

Best regards,
 Philipp

[1] http://www.oreilly.com/openbook/linuxdrive3/book/index.html
[2] https://forum.freifunk.net/t/l2tp-batbone/9076
[3] https://forum.freifunk.net/t/supernodeabstuerze-in-wuppertal/659/8?u=phip
[5] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-December/012608.html


More information about the WLANware mailing list