-------- Forwarded Message --------
Subject: [Battlemesh] GSoC 2019 announced (Battlemesh Digest, Vol 104,
Issue 7)
Date: Thu, 15 Nov 2018 16:16:35 +0100
From: Andreas Br?u <ab(a)andi95.de>
Reply-To: battlemesh(a)ml.ninux.org
To: Battle of the Mesh Mailing List <battlemesh(a)ml.ninux.org>
Hi there,
on Tuesday Google announce GSoC 2019. Org applications will start on
January 15 2019. Until then we have time to update the projects page at
https://projects.freifunk.net/#/projects
Please add new ideas to the page, update the existing or delete the
obsolete ones. Changes to the projects can be made at
https://github.com/freifunk/projects.freifunk.net-contents
You can find the timeline at
https://developers.google.com/open-source/gsoc/timeline
If you have any questions, please get in touch with me or write an email
to gsoc-org-admins(a)freifunk.net
Best regards,
Andi
Il 2018-12-12 16:45 bruno vianna ha scritto:
> The old version of chef is very good in this sense. The community
> would write a name in the web form and it would generate a default
> firmware with the name as SSID. After creating it, you could edit
> individual files in the firmware using other web forms.
>
> https://chef.altermundi.net/network/create/
>
> It was very friendly for the communities we worked with.
I have to say that is true. Probably the networkprofile add other
features, but is missing a part to manage it easily for comunity or to
introduce how to do starting by the skills needed in the other version .
So for my esperience was easy to use the first version.
because for example I create our network when exist the old verion of
the chef: with ESSID name fermenti.bo.ninux
And wheh I went to add other nodes.. a year ago..I discovered in that
moment that was no more possible use the chef in the same way.. so now
we have two islands of our network.
We are not so much that we manage the network and the most are rural
people that are ok to flash antennas (the doc is translated:) but not to
write configuration without a documentation. So I tryed starting from
this https://github.com/libremesh/network-profiles/tree/master/libremesh
and as written in the readme the stuff broke.. .and I postponed to do
and fix until forget.
humm so at least I never yet create a networkprofile :) I could be a
good tester.
and I'm a frontend dev if you need help in web interface I can help.
there will be a meeting in CCC?
ciao
ignifugo
>
> On Wed, Dec 12, 2018 at 2:39 PM Paul Spooren <mail(a)aparcar.org> wrote:
>
>> Hey all,
>>
>> as mentioned in my previous mail, Chef should work again. However,
>> editing network-profiles aka lime-defaults is not the easiest thing
>> to
>> do (as it introduces git, GitHub, uci, more?). My idea would be to
>> setup a simple web page that generates the lime-defaults file and
>> automatically creates a network-profile packages.
>>
>> Please let me know what values you'd like to change and what you
>> think
>> of this idea in general. My primary focus is to allow users a dead
>> simple way to get their own mesh up and running.
>>
>> Best,
>> Paul
>>
>> _______________________________________________
>> lime-users mailing list
>> lime-users(a)lists.libremesh.org
>> https://lists.libremesh.org/mailman/listinfo/lime-users
>
> --
>
> bruno(a)pobox.com ▀─█▄██▄▀▄
> http://brunovianna.net [1] ─█▄██▄▀█▀█▄
> skype:
> randomico▀─█▄██▄▀█▀█▄▌██─█▌█▌
>
>
>
> Links:
> ------
> [1] http://brunovianna.net/
> _______________________________________________
> lime-users mailing list
> lime-users(a)lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users
Hey all,
as mentioned in my previous mail, Chef should work again. However,
editing network-profiles aka lime-defaults is not the easiest thing to
do (as it introduces git, GitHub, uci, more?). My idea would be to
setup a simple web page that generates the lime-defaults file and
automatically creates a network-profile packages.
Please let me know what values you'd like to change and what you think
of this idea in general. My primary focus is to allow users a dead
simple way to get their own mesh up and running.
Best,
Paul
Hey all,
after various long (and fun) discussions on how to handle network-
profiles, we solved it for now by introducing a third file. However
cares for the details, check this out[0].
Good thing is, chef.libremesh.org not only moved to a faster server,
but also supports these network profiles again. Therefore, push
something to libremesh/network-profiles, wait some 15 minutes and it
will be available as a network profile in Chef.
As this is a feature of the 18.06.1-dev branch, I removed the broken
ones.
Please feel free test this and complain in case of troubles. As always,
best by opening issues on GitHub!
Sunshine,
Paul
[0]:
https://github.com/libremesh/lime-packages/commit/4948f17340e0e3f097530f16b…
[please someone accept my request from nz(a)os.vuas i’ve had to reconfigure my old account just to participate in the ml, thanks in advance ;]
@pau:
Either here: https://it.gearbest.com/wireless-routers/pp_642436.html?wid=1433363whereit often goes on sale for about 30/32€, or here: https://it.aliexpress.com/item/Originale-Xiaomi-WiFi-3g-Router-Extender-Rip…
Also, not tested, but interesting: https://m.intl.taobao.com/detail/detail.html?id=567548306041&abtest=9&rn=c1…
@patricio
As far as i know the 3G is the only one supported by openwrt but if anyone wants to try out the others that would be of great help to the community, although beware of the limitations of the others.
Keep in mind xiaomi has done a great job of making it a pain to flash this router in software [without taking them apart] so you need to physically register every device on their website and download an SSH package to flash on the devices. The SSH package is actually seemingly universal, however the password generation is still algorithmic and we don't know how they're generated. If anyone finds a solution, no registration would be needed, simply:
1] flash dev firmware on device
2] flash ssh package on device [one package works for all, you can use mine if you'd like, we can make it available online as well]
3] enter ssh shell via device-specific password [to be generated via as-of-yet-unknown algo]
4] flash owrt / lime
If anyone out there tries them out please report back here: https://forum.openwrt.org/t/status-updates-on-xiaomi-router-3g-mi-r3g/25883
@dan i know right! I'm so excited!
I just tested these out the other day but i plan to put them to work real soon.
The antennas don't seem to be removable, but I'll have our hardware guy take a look at them!
On 3 Dec 2018, 21:07 +0100, norðurljósahviða <nk(a)os.vu>, wrote:
>
> [please someone accept my request from nz(a)os.vu as i’ve had to reconfigure my old account just to participate in the ml, thanks in advance ;]
>
> @pau:
>
> Either here: https://it.gearbest.com/wireless-routers/pp_642436.html?wid=1433363where it often goes on sale for about 30/32€, or here: https://it.aliexpress.com/item/Originale-Xiaomi-WiFi-3g-Router-Extender-Rip…
> Also, not tested, but interesting: https://m.intl.taobao.com/detail/detail.html?id=567548306041&abtest=9&rn=c1…https://market.m.taobao.com/app/idleFish-F2e/widle-taobao-rax/page-detail?w…
>
> @patricio
>
> As far as i know the 3G is the only one supported by openwrt but if anyone wants to try out the others that would be of great help to the community, although beware of the limitations of the others.
>
> Keep in mind xiaomi has done a great job of making it a pain to flash this router in software [without taking them apart] so you need to physically register every device on their website and download an SSH package to flash on the devices. The SSH package is actually seemingly universal, however the password generation is still algorithmic and we don't know how they're generated. If anyone finds a solution, no registration would be needed, simply:
>
> 1] flash dev firmware on device
> 2] flash ssh package on device [one package works for all, you can use mine if you'd like, we can make it available online as well]
> 3] enter ssh shell via device-specific password [to be generated via as-of-yet-unknown algo]
> 4] flash owrt / lime
>
> If anyone out there tries them out please report back here: https://forum.openwrt.org/t/status-updates-on-xiaomi-router-3g-mi-r3g/25883
>
> @dan i know right! I'm so excited!
>
> I just tested these out the other day but i plan to put them to work real soon.
>
> The antennas don't seem to be removable, but I'll have our hardware guy take a look at them!
After about a year of hoping, waiting, testing, and so on, and thanks to Ilario and Nicopace’s help, I can finally confirm that the Xiaomi Router 3G [MI R3G] is a dream router.
I am still very excited about the LibreRouter, and that’s a project I had been considering starting myself in the past before I ran into it, but this router is 30€ and - after 4 years of work in this field - has finally rebooted my hope into mesh networks, sustaining a 135mbps mesh over 5GHz AC WiFi, with 1ms latencies between nodes under ideal conditions.
I’ve learned that several other people - with actual technical expertise [as opposed to mine] - are looking into this router also because of its mt7621 chip, which I hear seems to work much better than ath10k. It can also apparently sustain a gigabit hardware NAT [I seem to have understood from rumors].
I’ve run several iperfs and I keep getting results over 100mbps up and down and sometimes even peaking at 140mbps. The latency between nodes is a steady 1ms.
root@OPNT-d04123:~# ping6 fd66:66:66:7:4231:3cff:fed0:41a4
PING fd66:66:66:7:4231:3cff:fed0:41a4(fd66:66:66:7:4231:3cff:fed0:41a4) 56 data bytes
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=1 ttl=64 time=1.69 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=2 ttl=64 time=1.04 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=3 ttl=64 time=1.04 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=4 ttl=64 time=1.11 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=5 ttl=64 time=1.11 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=6 ttl=64 time=0.875 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=7 ttl=64 time=0.992 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=8 ttl=64 time=1.43 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=9 ttl=64 time=1.18 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=10 ttl=64 time=1.07 ms
64 bytes from fd66:66:66:7:4231:3cff:fed0:41a4: icmp_seq=11 ttl=64 time=0.752 ms
^C
--- fd66:66:66:7:4231:3cff:fed0:41a4 ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 10098ms
rtt min/avg/max/mdev = 0.752/1.120/1.698/0.248 ms
localhost:~ at$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=3.857 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=3.906 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=120 time=10.015 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=120 time=3.843 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 4 packets received, 20.0% packet loss
round-trip min/avg/max/stddev = 3.843/5.405/10.015/2.662 ms
localhost:~ at$ speedtest
Retrieving speedtest.net configuration...
Testing from Fastweb (xxx.xxx.xxx.xxx)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Fastweb SpA (Milan) [0.17 km]: 6.045 ms
Testing download speed................................................................................
Download: 111.09 Mbit/s
Testing upload speed................................................................................................
Upload: 135.79 Mbit/s
localhost:~ at$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 10.42.65.35 (10.42.65.35) 0.855 ms 0.415 ms 0.306 ms
2 10.42.65.163 (10.42.65.163) 1.361 ms 1.332 ms 0.945 ms
3 192.168.11.1 (192.168.11.1) 1.307 ms 1.431 ms 1.148 ms
I’m trying it out on 18.06 on develop branch. If anyone wants to install the profile check out the network-profile “openNET.io/Mi-R3G”.
This is how I’m cooking it as per the openNET.io-cooker script [which can also be found inside our net-profile]
./cooker --flavor=lime_default --remote \
--community=openNET.io/Mi-R3G -c ramips/mt7621 --profile=mir3g
I’ve tried disabling the 5GHz interface to see how it performs on 2.4 but even after reboot it doesn’t seem to be able to route to the other node. I’ll post back with more details over time if anyone’s interested.
Nz
In Ecuador we're starting to convene a coalition of communities and organizations interested in creating community network or already doing so, and we're also talking with the state about how to makes regulations and laws more supportive of community networks.
A friend who went to the Latin American Community Networks Summit in September told me, "I felt deja vu, that I was in 2008, ten years ago, having the same conversations about community FM radio stations." So I asked, How can we think ten years ahead, and include our vision of the future in the changes we make today to laws and regulations and our own internal organization methods and technical planning?
In Ecuador there has been a lot of fiber optic cable installed in the last ten years, and we missed out on the opportunity described in the 2018 GISWatch in B4RN and Guifi.net that obliged private companies laying fiber across public land to designate fibers for open access networks. Maybe we still can benefit from that, and I also want to look for other techniques and ideas.
What will we want in community networks in ten years? What can we do today to move in that direction, or open those doors?
I think that for Ecuador, where we're just beginning the community network movement, we could benefit a lot by including fiber optic in our networks and plans now, not just thinking in terms of WiFi. So I'm curious about the LibreFibre process that NV mentioned in another email, and any other relevant experiences.
Patricio
I’ve been following the expansion of our network-profiles repo and I keep growing a stronger and stronger idea that it’s becoming harder and harder to understand which of the various configs works best.
LiMe has the amazing goal to help automate and standardize all of the best-practices for mesh networking out of the box, and yet the defaults don’t seem to work at their best. The default network-profiles/libremesh/default profile still uses adhoc, the ath10k workarounds still need to be stolen from the quintanalibre profile, and I only learned about the babel flavor from the MieresLliure profile.
Furthermore I still believe that running a diff of the entire lime-defaults file between profiles is cumbersome, and I believe one should be able to override a single setting [like the wpa2-psk setting for the APNAME network] without needing to copy-paste the entire lime-defaults file, and changing that single setting, especially so that in the future, when the default lime-defaults gets better, all profiles inherit the new changes while only maintaining the specific overrides they have applied. Also sometimes I see settings applied in uci-defaults rather than in lime-defaults, and that too is confusing.
This is in addition to the fact that there are of course several dev branches on the lime-sdk repo, which further complicates things, but it is necessary as we all know to make things move forward.
I think we should be adopting a “master profile” approach where the default is the best option out there. Say MieresLliure tries out babel and that works out better than bmx6, we implement that into default, and everyone can benefit, making that the new default. Say instead that an A/B test reveals bmx7 works better, we pull that and make that the default. We’ve made 802.11s the new default some time back, but still loads of profiles out there use adhoc.
I’m saying that too much of the config is profile-specific, whereby I think a profile should literally only have customizations inside, like the name of the community or of the public network name. And yes of course we should still be able to force bmx7 the default, but only for dev purposes, run a public test [A/B or whatever], gather data in a scientific way, and determine publicly which of the results should be pulled and made the default, thereby pushing the new config to all existing profiles [because - for example - the openNET.io profile won’t have a long lime-defaults file specifying bmx6 or babel, it’ll simply say “make the public network called openNET.io and password Aurora42+”, and nothing else, unless explicitly specified].
This would allow for a much lower fragmentation [think of it kind of like project treble in the android world].
I love LiMe and strongly believe that a highly consistent and lightweight customization will avoid the apparently inevitable fragmented and confusing future several open projects out there suffer from.
Let me know what you think
Nz