Hi!
I finally got to the point to test the results of running 802.11s on
plain LEDE and want to switch to the upcoming LiMe release and help
testing. As most of the folders on the release download server are
still empty I liberated enough free space on my SSD to build the SDK
and IB from scratch myself. The good part: Congratulations for
switching to the IB+SDK and starting a more productive colaboration
with the upstream projects! It's great to see that the Libremesh
fishtank has finally poured into the open sea :)
In the next week I'll be working on a test-deployment which will be
based on the upcoming LiMe release and hence LEDE-17.01.2(-pre) on a
Lantiq XRX200 device providing a VDSL gateway plus a bunch of ar71xx
devices providing the mesh+APs. I hope that we can then annouce to have
sucessfully overcome the boundaries of only using only one hardware
platform. And make the switch to 11s (which I'll be using there as
well)
The rather sad part of the tour through the upcoming release was to
find 'libusys' which was apparently pulled in by 'organge-rpc':
Please take a look the code at
https://github.com/mkschreder/libusys/tree/master/src
Did you notice that this is someone trying to recycle Felix code' from
5 years ago? And never send a single message to the upstream mailing
lists or ever tried to contribute just one line?
Besides that, it's also sad in terms of making best use of our scarse
flash and memory resources, because we already got everything which is
there (uloop, ulog, ...) and need it anyway for procd, netifd, ...
Now have a look and compare with the above:
https://git.lede-project.org/?p=project/libubox.githttps://git.lede-project.org/?p=project/ubox.githttps://git.lede-project.org/?p=project/ustream-ssl.git
(and some more)
Why on earth include it again, in an outdated version?!
To me it was quite shocking to see that you are using weird outdated
stuff which is featured by an isolated one-man-show rather than
participating in the much wider and public collaboration. If you really
need websockets, why not attach them to uhttpd (I didn't quite
understand why you need them in that context I must admit)?
If you want a JSON-RPC, why not use uhttpd-mod-ubus?
Anyway. It somehow happened. What's the plan and how to proceed with
the lime-ui story? Maybe I'm just lacking information...
Cheers
Daniel
(Braindumping here, sorry for the lack of context)
made two one-way tunnels:
packets put into torreunc "foo" will be captured at nicojesigioia "fool"
and viceversa, nicojesigioia "foo" -> torreunc "fool"
but foo doesnt need any "fake" source address,
the key is that "fool" is constructed using "remote ::", and it catches
packets with destination equal to the "local 2001:db8::" address, but
regardless of the source address
i.e.
ip -6 tun add fool local fd66:66:66:15:c24a:ff:fefc:6567
### torreunc
root@torreunc:~# ip a s foo
13076: foo@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue
state UNKNOWN group default qlen 1
link/tunnel6 2801:1e8::827a:4a00 peer fd66:66:66:13:c24a:ff:fefc:6566
inet6 fe80::fc21:acff:fe96:f61f/64 scope link
valid_lft forever preferred_lft forever
root@torreunc:~# ip a s fool
13281: fool@NONE: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state
UNKNOWN group default qlen 1
link/tunnel6 fd66:66:66:8:62e3:27ff:fe4a:7a82 brd ::
inet6 fe80::d893:19ff:fec4:3163/64 scope link
valid_lft forever preferred_lft forever
root@torreunc:~# ip r get 2801:1e8::827a:4a00
local 2801:1e8::827a:4a00 from :: dev lo table local proto none src
2801:1e8::827a:4a00 metric 0 pref medium
### nicojesigioia
root@nicojesigioia:~# ip a s foo
2207: foo@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1350 qdisc noqueue
state UNKNOWN group default qlen 1
link/tunnel6 2801:1e8:2::6565:fc00 peer fd66:66:66:8:62e3:27ff:fe4a:7a82
inet6 fe80::ec05:abff:fefe:54c9/64 scope link
valid_lft forever preferred_lft forever
root@nicojesigioia:~# ip a s fool
2380: fool@NONE: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state
UNKNOWN group default qlen 1
link/tunnel6 fd66:66:66:13:c24a:ff:fefc:6566 brd ::
inet6 fe80::b853:54ff:fe4a:3de5/64 scope link
valid_lft forever preferred_lft forever
root@nicojesigioia:~# ip r get 2801:1e8:2::6565:fc00
local 2801:1e8:2::6565:fc00 from :: dev lo table local proto none src
2801:1e8:2::6565:fc00 metric 0 pref medium
This works, and I propose bmx6/7 sets up tunnels like this, without
specifying a "peer" on the "receiving" tunnels, so that "sending"
tunnels can use real ipv6 source addresses and ICMPv6 errors messages
can be sent back successfully and not break PMTUD in case of MTU size
changes
as a reference, here's how current bmx6 sets up the equivalent of the
"fool" interface, but specifying a "remote" (innecesarily)
root@torreunc:~# ip a s bmxmain
16: bmxmain@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1460 qdisc noqueue
state UNKNOWN group default qlen 1
link/tunnel6 fd66:66:66:8:62e3:27ff:fe4a:7a82 peer
fd66:66:66:ff00:62e3:27ff:fe4a:7a82
inet 10.5.24.12/32 scope global bmxmain
valid_lft forever preferred_lft forever
inet6 2801:1e8::827a:4a00/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::ce:9cff:fe25:2c92/64 scope link
valid_lft forever preferred_lft forever
root@nicojesigioia:~# ip a s bmxmain
16: bmxmain@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue
state UNKNOWN group default qlen 1
link/tunnel6 fd66:66:66:a:c24a:ff:fefc:6565 peer
fd66:66:66:ff00:c24a:ff:fefc:6565
inet 10.5.0.6/32 scope global bmxmain
valid_lft forever preferred_lft forever
inet6 2801:1e8:2::6565:fc00/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::f87c:4ff:fe19:ebde/64 scope link
valid_lft forever preferred_lft forever
and a corresponding equivalent 'foo' tunnel
root@nicojesigioia:~# ip a s bmxOut_torreun
2391: bmxOut_torreun@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1358
qdisc noqueue state UNKNOWN group default qlen 1
link/tunnel6 fd66:66:66:ff00:62e3:27ff:fe4a:7a82 peer
fd66:66:66:8:62e3:27ff:fe4a:7a82
inet 10.5.0.6/32 scope global bmxOut_torreun
valid_lft forever preferred_lft forever
inet6 2801:1e8:2::6565:fc00/128 scope global
valid_lft forever preferred_lft forever
inet6 fd66:66:66:ff00:62e3:27ff:fe4a:7a82/128 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 fe80::f005:3cff:fe4a:26d/64 scope link
valid_lft forever preferred_lft forever
I am Mubarak Dada, a computer programmer with more than 7 years experience
coding and also a Bachelors of Engineering. I was fortunate to know about
different Libre community products at the just concluded Africa Internet
Summit and i will love to be join the development team. I code in C, C++,
Python, Fortran and C#, i recently started learning lua. I have done
several projects and worked on big data and artificial intelligence. I hope
in making the lime associated components more intelligent and geek free if
i am given the chance to work with the team. Thank you
Kind Regards
I am Mubarak Dada, a computer programmer with more than 7 years experience
coding. I was fortunate to know about different Libre community products at
the just concluded Africa Internet Summit and i will love to be join the
development team. I code in C, C++, Python, Fortran and C#, i recently
started learning lua. I have done several projects and worked on big data
and artificial intelligence. I hope in making the libre router and it's
associated components more intelligent and geek free if i am given the
chance to work with the team. Thank you
Kind Regards
Mubarak
Dear all,
I'm Paul Spooren and applied for this years GSoC. My project is to build
an attended sysupgrade to easily reflash routers on new releases.
For more information please read my blog post here:
https://blog.freifunk.net/2017/05/30/gsoc-2017-attended-sysupgrade/
Thanks in advance for all kind of feedback!
Best, Paul Spooren
Hi Jo,
On Wed, May 24, 2017 at 10:34:20PM +0200, Jo-Philipp Wich wrote:
> Hi,
>
> I'd like to start preparing the v17.01.2 release during the upcoming
> weekend with the goal to release final binaries within the next week
> (~May 29th till June 3rd).
>
> Changes that shall be part of 17.01.2 should be merged until Sunday, the
> 28th.
>
> You can find the current list of changes since v17.01.1 at
> https://lede-project.org/releases/17.01/changelog-17.01.2
>
> The most notable change is a security fix affecting the builtin dropbear
> SSH server. While the default configuration does not appear to be
> vulnerable, we still should provide updated images as soon as possible.
>
>
> If you want specific fixes cherry-picked/backported to lede-17.01,
> please mention them in a reply to this mail.
I'd like to see
commit ed62d91f4b5296a4aa883ce975d76f590ef4e910
from Nick Lowe
hostapd: add legacy_rates option to disable 802.11b data rates
commit 1a16cb9c67f0d2c530914aec31c721b75f03a908
from Matthias Schiffer
mac80211, hostapd: always explicitly set beacon interval
included as that fixes co-existence of AP+mesh interface combination
which was previously broken.
Cheers
Daniel
Hello everyone,
I'm Paul Spooren and I'll work on attended auto upgrades for LibreMesh (and Lede) this GSoC.
Some personal information, I'm 24 years old and study computer science at the University of Leipzig.
First I applied to work on captive portal login but after some discussion with my mentor(s) we decided to create an semi auto upgrade via the luci(-ng) fronted.
The shortcomings of captive portals will be covered in my first blogpost.
Once finished, the web interface will notify on new upgrades and the (to be created) update server will auto generate an image with all installed packages. This will simplify the update routine for all users, even with special setups where packages are required for Internet connection.
The "image as a service" approach could also optimize the current chef.altermundi.net setup.
What I've done last week:
* setup the build environment and get to know the build process
* "design" a requests model for the "image as a service" process
What I plan to do next week:
* setup a cache mechanism in the build scrips
* check luci(-ng) sysupgrade process
* write the blog post and create a timeline
Regards,
Paul Spooren
This is what we did so far (mostly during the hackaton, and a few things
before and after)
Changelog Dayboot Rely 17.04 (since 16.07)
• based on LEDE 17.01.1
• build everything using LEDE SDK, via new lime-cooker (instead of
lime-build)
• lime-system: fix ieee80211s proto, correctly construct ifnames
• lime-system: sanitize hostname (transform everything into alphanumeric
and dash)
• lime-system: new proto static
• lime-system: set dnsmasq force=1 to ensure dnsmasq never bails out
• lime-webui: enable i18n, finally webinterface is available in Spanish
• lime-webui: Major rework by NicoPace, thanks!
∘ bmx6 node graph now uses colors in a clever way
∘ simple way to add "system notes" that are shown along with
/etc/banner and webui
∘ luci-app-lime-location: fix google maps api key
∘ new read-only view: switch ports status
∘ alert luci-mod-admin users that their changes might get overwritten
by lime-config
∘ fix batman-adv status webui
• new package available to install lighttpd instead of uhttpd (needed
for an upcoming android app)
• added a lime-sysupgrade command: does a sysupgrade but only preserving
libremesh configuration file
• added a lime-apply command: basically calls reload_config, but also
applies hostname system-wide without rebooting
• lime-proto-anygw: unique mac based on ap_ssid (using %N1, %N2)
• lime-proto-anygw: integrate better into /etc/config/dhcp instead of
/etc/dnsmasq.d/
• lime-proto-batadv: set batadv gw_mode=client by default to counteract
rogue DHCP servers
• lime-proto-bmx6: introduce bmx6_pref_gw option, adds priority (x10) to
a specific bmx6 gateway
• bmx6: doesn't flood log with some spurious warnings anymore (syslog=0)
• bmx6: sms plugin now enabled by default
• bmx6: daemon is now supervised by procd, so it is restarted in case of
crashes
• bmx6: doesn't "configSync" by default anymore (no more "uci pending
changes" because of auto-gw-mode)
• new bmx6hosts tool: maintain an /etc/hosts that resolves fd66: <->
hostnames.mesh
• safe-reboot: fix, use /overlay/upper instead of /overlay
• safe-reboot: add "discard" action
• ath9k: debugged some hangs (interface is deaf) and workaround it
• alfred: fix bat-hosts facter, check for errors and don't nuke
/etc/bat-hosts in case of failure
• various Makefile dependency problems fixed
pending for confirmation: (already done but waiting merge or testing)
• don't tag bmx6 packets over ethernet and so use at least mtu=1500
everywhere
• make 80211s work correctly
hi!
p4u mentioned that there is interest in a hackathon for the next
libremesh release. at first i was sceptical whether this would be a
good idea (because i just came back to leipzig myself and things
weren't as comfortable as i was hoping). however i can now officially
invite you because everybody here likes the idea. you will have choice
between spaces with all sorts of possible test-deployments which will
be thankful. one new and pretty large trailerspace now got VDSL with
50MBit/s and they need to distribute the available bandwidth in a
quite large space and among quite a number of people. they also got
a building on the which can host all of us and provide useful working
space (electricity and, as i mentioned, bandwidth :)
anyway: if this is desired, i'll need to know the exact timeframe and
number of people to expect asap to go to the affected assemblies and
reserve the space for us. it'd also be nice to put a mixed agenda
which would also involve some talks and workshop with a general
audience (think: people who might have heard about freifunk but have no
idea about the details as well as folks interested in deployment skills
and maybe even developers, but that'd definitely be a minority).
and a decent release party :)
let me know what you think!
cheers
daniel
