Gluon: Feature Request: Mobile Node

[waschmi]

The City of Hamburg is fragmented in many parts that already require a different Firmware build. User have to identify their area and from what I know they won't actually mesh together. Even if the Nodes right next door, they won't work.

It seems there is a technical reason and a problem with scaling. At this rate I already expect micro-cells and firmware based on House Numbers and a working Internet Connection to join the greater Network (which actually is just the Internet, bye bye Freifunk).

Yes, people working on improving Mesh-Protocols and self configuration Nodes, at least that's the Goal I've heard. We should think about a PlanB, in case things don't work out that way.

First, I'd like to move freely around in Hamburg with a Node in my backpack an that should mesh with any Mesh-Network in reach. It makes sense to have your own node with you because not all clients have the same reach (Smartphone vs. Laptop), also in case you're with more people. I shouldn't have to plan ahead to which area I want to go and especially I shouldn't have to flash the Node every time it changes. We need a solution for that.

Second, let's say mesh network scaling just doesn't work out an devices are to limited to handle "the whole network" alone without some central servers we actually don't want. How about a mesh-protocol that "knows it's limit" and designates a few nodes to route into the next 'limited' mesh network? We could still have one big net. At least have some node that can 'sense' and mesh with the next area.

Of course that's just me wishful thinking, however the current state is just annoying.

[jplitza]

I am confused by the image you posted, which shows Schleswig-Holstein, Hamburg and parts of Lower Saxony instead of just Hamburg. On that scale, fragmentation is not only due to technical problems but also due to organizational differences.

Regarding the split inside of Hamburg (if there is such a thing), please detail how the choice of district is made and in what settings the districts differ. If, for example, the frequency is the same everywhere but the BSSID of the mesh network differs, you could write a software do detect which district you're in by scanning for available mesh cells and configure your node accordingly. Of course, this only works with correctly configured neighbours, but it enables you to mesh whenever possible.

However, in the current setup, you're node should never bridge two districts, i.e. mesh with nodes from two different districts at the same time, because that effectively revert the separation and thus probably overwhelm the network.

We are all very aware of the limitations of the mesh protocol we are using (B.A.T.M.A.N. advanced) and its bad scalability. Yes, there are (or have been) people working on better alternatives (babel, see the branch of the same name in this repository).

Finally, I'd like to mention an argument against having a node with you: B.A.T.M.A.N. advanced is designed to handle roaming clients very quickly. But to my knowledge, roaming nodes are not handles quite as fast. So if you're actually moving, you're probably trading in roaming speed.

[waschmi]

@jplitza

Obviously I don't know my Geography. An I actually don't know much about the internals details of the Network. However unless it's actually a different Technology (like oslr and batman) how is "oganizational differences" actually a reason? I mean, at least it shouldn't be. If community A uses Gluon Firmware and community B uses Gluon Firmware, why build walls where friendship could be?

I certainly think the bridging of two is completely a MUST feature and should have priority. I already heard a lot of people with different opinions on that but I really think that it is THE basic requirement for the very Idea of Freifunk. If that doesn't get fixed you might as well just stop because it just doesn't make sense to go on doing Freifunk (that's how serious I feel about that).

Roaming Nodes are also a basic requirement in my Opinion. We might have Smartphone or other mobile Devices become able to be Nodes in the Feature. Well, in case there are 'trade offs' that's actually okay, as long as it still works.

Sorry for coming a bit strong on this, it's difficult to find the right words when it feels important.

[adlerweb]

Yes, more intelligent nodes would be a huge benefit. In theory. Currently we've got one channel for the whole network, manual community selection, centralized/remote IP management etc. With more intelligence adjacent nodes could try to agree e.G. on a less used channel and automatically build up "neighborhood-cells" which is IMO not a bad idea at all. For now I however see no realistic way to connect these micro-cells - sure, we could use some routing protocol voodoo which should handle this scenario (since most uplink/long distance links are fairly static). OK, this would most likely break fast-moving nodes like you are describing once you leave the neighborhood. Stil I don't think current hardware would be able to stand the load caused by this setup - most of these plastic-boxes can barely handle the current setup so there isn't that much room to get more features without replacing a lot of the currently used infrastructure…

[viisauksena]

the point is not that 2 nodes meshing together is dangerous .. thats fine most of the time ...
the point is : if these to mehing nodes have different uplinks to different cells/communities ... due to this big layer2 network (batman-adv) things can go horribly wrong up to bricking whole networks with just one innocent - @waschmi called must have - interconnect.
If you can solve this issue - decide which connection to use if uplink and mesh Network dont fit, and block interconnect between them - it would be awesome. (but difficult, and filled with many traps like different batman-adv versions, different routing protocols etc.)

[waschmi]

@viisauksena

... things can go horribly wrong up to bricking whole networks...

Sounds like a valid reason to really make it a priority.

Again,
we basically have mesh that don't mesh.
We have central servers we don't want.
We can take everything down with just one 'bad' node?
We more or less only support one wireless chipset.
We have encrypted, non open long range Nodes (backbone) in the hands of a few.

Think about it, we might be happy when we see more people join Freifunk but whatever we expected Freifunk to be, it isn't happening if this doesn't get fixed. I'm not complaining right now, I just want to say that things must change.

[rotanid]

@waschmi the current state isn't like it is because people don't know about the problems but rather because there are no simple solutions. if there were, someone would have done it by now.
feel free to dig into these issues and help with solving this :)

[waschmi]

@rotanid

It feels like more people are like "bah, it's good enough already!". I don't mean you, it's various things that make me feel like that. Also, taking 'Statistics', have a nice Map, a Status Page with many Gizmos.... It's all nice and good but isn't this also pretty much cementing the current state? Can you say "This doesn't work, we have to replace this protocol" an deal with all the complains like "Whaaat, this doesn't have a Map? I don't want it!" or "The Statistics are necessary to manage this Community, we can not deploy your new Firmware" or "Why do you change things? I hate change!".

Hamburg is basically still using this Firmware "0.7.1 / gluon-v2015.1.2" and while they give you newer Version for download, they're not officially deploying a update. There might be very good technical and stability based reasons, maybe they just don't want to deploy it because someone complained about it on the mailing list. What I want say is, this project is already investing a lot of work into keeping things just going. Maybe this is nothing and the work on improving things is still going full throttle, no need to worry? Maybe this is already so much overwhelming work there is simply no space left for improving the important things?

I on the other hand do worry about it, I can't help it. I want something better and get scared that people might be okay with how things are.

[NeoRaider]

Let's please focus on the actual issue and not get OT too much.

The wish for a community-independent firmware has been voiced a few times, but I don't think it is a realistic goal. It would force communities to build their networks in similar ways (using the same routing protocol, same network topology, etc.). This conflicts with the Freifunk idea - each community should be as free as possible in the choice of their technology. IMHO, communities also have the right to decide where and how their network is connected to others - "automatic" bridging is a no-go.

Even in Gluon, we're working on integrating support for new protocols and topologies - and not all communities are using Gluon (and I really hope these alternative will further develop; while I think that Gluon solved many issues in a nice way, I always hope people also find other solutions and build their own things, so it's possible to learn from each other). In the long term, this will make a community-independent firmware even less realistic than it is today, where too many Freifunk networks are built upon the same set of technologies.

Scalability is another issue. The idea of automatic segmentation is very complex to get right (I guess complex enough for a few PhD theses), and there are very many open questions that I wouldn't know how to answer at all (amongst others: each segment would need a unique IP prefix and a unique ESSID... random-generated ESSIDs wouldn't look nice though), besides the technical difficulties in finding routes between segments, etc...

Regarding roaming nodes, there aren't any routing protocols at the moment that would solve that nicely. I think Babel will perform better than batman-adv, but probably not much.

That said, you're welcome to think about solutions for these issues. For my part, I don't think I will put much effort towards it though, as I'd like to use my time for tasks that can realistically be solved in this decade :)

[waschmi]

@NeoRaider

This conflicts with the Freifunk idea - each community should be as free as possible in the choice of their technology. IMHO, communities also have the right to decide where and how their network is connected to others - "automatic" bridging is a no-go.

That doesn't sound right. The basic Idea of Freifunk is to connect each other. To choose different technologies was more like based on different opinions regarding early mesh protocols and the abilities to implements them from volunteering Members. After that is was said than Network Heterogenity would make Freifunk more stable and resistant agains attacks from various sources. How did it become "the freifunk idea"? How did the geeks flameware on what's the better protocol to use become a "community right"? Who are you to tell me that automatic bridging is a "no-go"? I might just go out and make that evil briging of networks a hobby, knowing fully it will harm the networks.

Meaning we don't have the stability or network resitance that different technologies should have given us. If there was actually a Firmware that's evidently better than any other, why would anyone want to use the inferriour one, one that doesn't play well with others?

So you don't think it's realisitc to have this problems solved, in the next few years and you don't want to put up effort towards that? That's okay, you can do whatever you want. Guess who's Firmware I won't use any longer, tho.

Since Hamburg uses Gluon (a Firmware with no future), I'll stop setting up Nodes and just leech on free Internet with the Clients. Because that will leave me with more time for other things, I really should go more outside, connect with people ~building bridges~ so to say.

We can't all have what we want, right?

[NeoRaider]

Hmm, it was not my intention to sound dismissive.

As I see it from a technical point of view, we should focus on creating a network that actually works (as in, can be used to exchange information, to connect people). As people in this ticket correctly noted, this is a hard problem: our Freifunk networks are fragile, and it is easy to make a whole network unusable with a single broken node. Some issues will be solved in time, other might just not have satisfactory solutions. Switching to new routing protocols etc. is a stepping stone towards more robust networks, but will not solve our issues by itself.

Let me rephrase my statement "automatic bridging is a no-go": "Automatig bridging is a no-go with the technologies we currently have". And I don't see any magical new routing protocol on the horizon that would suddenly make it more realistic, as desirable at is might be. We need to think in small steps that improve our situation bit by bit, and maybe we can discuss the realization such concepts at some point in the future.

I see both advantages and disadvantages to the idea of making our networks bigger. Having separate networks also means that e.g. an issue making the network of Freifunk Lübeck unusable won't affect Freifunk Hamburg. Automatic bridging might cost us this advantage...

The switch from batman-adv to Babel will mostly solve our background noise issue, but there is another scalability issue that will affect Babel as well: memory. Bigger networks need bigger routing tables, and I don't think telling people to throw away all their nodes with less than 64MB RAM is a viable solution either...

Regarding your last point: Gluon is developed by many people (although we could need a few more "core developers"). Even though I won't work on these issues myself (because I see more pressing issues that have more concrete solutions), I still hope that others do (maybe in Gluon, maybe in an independent project), and I'd certainly like to get such technology into Gluon if someone manages to build something that solves these issues.

By the way: Another principle of Freifunk is "decentralization". While this word can mean many things, one thing it means for me is: Let each community build their network the way they want - which is why Gluon is not one firmware, but a modular framework that can be adjusted by configuration and adding and removing packages.

I certainly don't see a single direction Freifunk (or Gluon) must develop into. Different people have different needs. The Gluon "core" people have some ideas how to improve Gluon (sometimes very different, conflicting ideas). Many communities have different ideas again. It is obviously impossible for us core devs to implement all features desired by different users ourselves, and although we are often influenced by popular demand, nobody pays us for this, and we have our own priorities.

The solution is simple: Write code and send pull requests. If you can't code yourself, find people who can and have the same priorities as you. We will gladly accept features that are techically sound and benefit users. :)

[ohrensessel]

Hello from Hamburg, @waschmi.

Your objectives are totally ambiguous to me. Let's illuminate some things here:

• Actually, Hamburg is not fragmented in any way. However, the Plenum of the community in Hamburg decided on looking into possibilities to split our fairly large network (~1k nodes) into 3 to 4 smaller networks. "looking into" means it hasn't happened yet and people just start investigating what solutions are there for such a "netsplit" and what needs to be done.
• One main part of Freifunk is the idea of beeing decentralized. Not only in the technical sense (where we definitely can and will do better in the future), but also in the sense that some people locally form a communitiy and work on things together, spread the idea, teach and help others. (read e.g. https://freifunk.net/worum-geht-es/vision/) It never was about the idea of building a Germany-wide large network.
• You are talking about a lot of things where you seem to have some vague knowledge only. What about asking questions instead of speculating?
• Choice of firmware version in Hamburg: We had some stability issues with another firmware we wanted to deploy. Plus Freifunk is a project run by people in their free time & sometimes there is hardly any free time. Therefore: no automatic update yet (yes it's that simple).
• Harming the network by purpose would be a very stupid thing to proove your point. It would just make life harder for all the people putting all of their free time into the project. Thanks.
• You are, by purpose, ignoring certain parts of prior posts. See at least the one from @NeoRaider about the complexity of such things you are "requesting".

As @NeoRaider already mentioned: It is very, very simple. Get involved in your community. Everybody in this community wants a better Freifunk network, for sure. Lack of free time, lack of people hinders the improvement of the network. Just have a look and see when the community in Hamburg meets: https://hamburg.freifunk.net/kalender

Freifunk is not about "requesting" things or bitching about bad aspects, Freifunk is about doing things, getting involved.