Hi from Barcelona Hacklab.
In order to mount new nodes with Libremesh in places where exist
networks with qMp and Libremesh we tested with two Nanostation M5 with
same revision of BMX6:
BMX6-0.1-alpha comPatibility=16
revision=2a87b770d3f9c254e3927dc159e2f425f2e0e83a
this is the default BMX6 in each stable release (Libremesh stable and
qMp Clereance 3.2.1)
For replicate the issue:
Working on same test channel (48) with same VLAN (default qMp 12) we got
good link and we can see BMX6 routes from each other, but we can't ping
each other.
Any ideas?
Thanks!
Let's organize a couple of meetings for getting this 17.02 release done!
I suggest to meet one weekend as soon as possible and another one in April.
Here you are the website for expressing your availability (this time the
results will be hidden, for the sake of participants' privacy):
https://framadate.org/LiMeCat2017q1q2
The venue will be in Valldoreix (Bcn), not yet exactly defined.
See you!
Ilario
2017-02-24 12:08 GMT+01:00 Juergen Kimmel <juergenkimmel(a)gmail.com>:
> So I started as well compiling for ZBT APE522ii using menuconfig which
> failed.
>
> At the very beginning I noticed:
> "Adding profile packages: lime-full cp: Aufruf von stat für
> 'targets/ar71xx.kernel' nicht möglich: Datei oder Verzeichnis nicht gefunden
This is normal (maybe there should be a check and not an error? Should
be easy to fix, anyone?) in English (for pasting output for debug
please use English, prepend "LANG=C " at the beginning of the command
line for changing language) I get:
cp: cannot stat 'targets/ar71xx.kernel': No such file or directory
this means that the profile you're using doesn't have any specific
configuration for kernel.
For example ar71xx-mini does have one.
> Then I tried:
> osboxes@osboxes:~/lime-build-17.02$ make T=mt7620 P=ape522ii UPDATE=1 J=1
> Profile of APE522ii is missing?
There's no such profile I think... You can use
make info
for listing the profiles, you may use the profile "generic".
The image for APE522ii should be built for the target you selected.
> So why branch=develop?
Uh! There's no branch "17.02" in lime-packages, at a certain point
(now?) we will need to create that first (devs...?) and then change
this line:
https://github.com/libremesh/lime-build/blob/17.02/config.mk#L7
Now we can start working on LibreMesh 17.03 :D
From: Jo-Philipp Wich <jo(a)mein.io>
To: LEDE Development List <lede-dev(a)lists.infradead.org>
Subject: [LEDE-DEV] LEDE v17.01.0 final
Hi,
The LEDE Community is proud to announce the first stable version of the
LEDE 17.01 version series.
LEDE 17.01.0 "Reboot" incorporates thousands of commits over the last
nine months of effort. With this release, the LEDE development team
closes out an intense effort to modernize many parts of OpenWrt and
incorporate many new modules, packages, and technologies.
---
Some selected highlights of this release are:
* Linux kernel updated to version 4.4.50 (from 3.18 in Chaos Calmer)
* Update of essential software:
* dnsmasq updated to 2.76 (from 2.73 in Chaos Calmer)
* busybox updated to 1.25.1 (from 1.23.2 in Chaos Calmer)
* mbedtls version 2.4.0 (from polarssl 1.3.14 in Chaos Calmer)
* openssl updated to 1.0.2k
* Improved Security Features
* Use SHA256 instead of MD5 to validate source code for packages
* mbedtls: disable SSLv3 support
* OpenSSL: disable support for compression, heartbeats, NPN,
Whirlpool, and J-PAKE
* Memory Corruption Mitigation Methods
* gcc -Wformat -Wformat-security
* User space Stack-Smashing Protection (Regular)
* Kernel space Stack-Smashing Protection (Regular)
* buffer-overflows detection (FORTIFY_SOURCE) (Conservative)
* RELRO protection (Full)
* Improved Networking Support
* Smart Queue Management (SQM) minimizes bufferbloat by using the
cake and fq_codel qdisc's.
* Improvements to the WiFi stack eliminating bufferbloat on ath9k,
mt76 and some ath10k chipsets
* Airtime fairness scheduler for ath9k to prevent slow stations
from hogging too much airtime
* Various stability and regression fixes to the Linux wireless
stack and ath9k in particular
* Provide alternative Candela-Tech ath10k-ct driver
* IPv6 hardening
* Updated toolchain
* musl 1.1.16
* gcc 5.4.0
* binutils 2.25.1
* Platform and Driver Support
* Lantiq
* Added redistributable DSL firmware
* Updated DSL phy drivers
* Added new targets:
* apm821xx (AppliedMicro APM821xx)
* arc770 (Synopsys DesignWare ARC 770D)
* archs38 (Synopsys DesignWare ARC HS38)
* armvirt (QEMU ARM Virtual Machine)
* ipq806x (Qualcomm Atheros IPQ806X)
* layerscape (NXP Layerscape)
* zynq (Xilinx Zynq 7000 SoCs)
* Reorganized x86 target:
* Drop dedicated Xen DomU target, merged with x86/generic
* Enable AES-NI support
* Removed targets:
* realview, replaced by armvirt
* ppc44x, disabled due to code brokeness
* netlogic, dropped due to no available hardware
* Build system improvements
* Separation of base system and community feeds to simplify
distribution of binary package updates
* Fixes and enhancements in package dependency handling, better
support for virtual provides
* Per-device rootfs images to better tune package selection to each
individual device profile
* New image build code improving compilation times and simplifying
device profile declarations
* New package/.../check make target to run a series of standard
diagnostics on Makefiles
* Support for fetching sources using Curl
* Generate reproducible source tarballs when packing SCM checkouts
* Image Builder / SDK
* Rework library bundling to allow for better portability between
different Linux distributions
* Add support for building kernel modules using the SDK
* Added support for a many new routers and boards
For a detailed list of changes since 17.01.0-rc2 refer to
https://lede-project.org/releases/17.01/changelog-17.01.0-final
For a complete list of changes since the start of the LEDE project, see
https://lede-project.org/releases/17.01/changelog-17.01.0
---
Known issues:
* Available space on devices with only 4MB flash is very low,
users requiring extra packages might want to consider using the
image builder to repack custom images
* The available memory on devices with 32MB RAM might be too low to
reliably run opkg or sysupgrade operations, especially in
conjunction with LuCI
* Any outstanding issues reported at https://bugs.lede-project.org/
---
For latest information about the 17.01 series, refer to the wiki at:
https://lede-project.org/releases/17.01/
To download the v17.01.0 images, navigate to:
https://downloads.lede-project.org/releases/17.01.0/
---
A big thank you goes to all our active package maintainers, testers,
documenters and supporters.
Have fun!
The LEDE Community
Hi devs!
In lime-users mailing list Nicolas asked how to change the IPv4 DHCP
server range in LiMe.
I realized that there's no way to do it. Anygw configures dnsmasq to
use the whole broadcast domain as DHCP range.
Here is where this happens:
https://github.com/libremesh/lime-packages/commit/3a6596d50b3c0446b988f84d3…
In theory there should be no problem as there should be a check for
the availability of the IP (by the DHCP server or client?), anyway I
think we should fix this.
Should we add a new option in /etc/config/lime?
Or use the values from /etc/config/dhcp?
2017-02-14 1:43 GMT+01:00 Ilario <iochesonome(a)gmail.com>:
>> We give APs static addresses of 10.13.64.1, 2, 3, and so on. They must all
>> be different. Try and stay out of the DHCP range which starts at 100 I
>> think.
>
> A very interesting question. There's no option for DHCP range in
> /etc/config/lime* files (and this is ok).
> But I supposed that the range was defined in /etc/config/dhcp, which
> on LibreMesh is identical than on OpenWrt/LEDE and contains:
> # cat /etc/config/dhcp
> [...]
> config dhcp 'lan'
> option interface 'lan'
> option start '100'
> option limit '150'
> option leasetime '1h'
>
> But trying to ask for a DHCP lease I received an IPv4 out of the
> 10.x.x.100-250 range, looking around I found that the DHCP range for
> anygw is hardcoded:
> https://github.com/libremesh/lime-packages/commit/3a6596d50b3c0446b988f84d3…
> resulting in the whole subnet... No good. @devs?
I thin the LiMe network architecture is a topic that may fit into a research paper. Maybe this workshop would be a nice place to send it.
Is there someone here able working on the academa and able to participate on this? I might participate but not as a first author.
Cheers.
-------- Missatge Original --------
De: Leonardo Maccari <mail(a)leonardo.ma>
Enviat: 14 de febrer de 2017 15:53:22 GMT-03:00
A: battlemesh <battlemesh(a)ml.ninux.org>
Assumpte: [Battlemesh] A call for papers on DIY networking
Hi battlemeshers,
for those of you that work in (conjunction with) the academia,
but also for those that can afford a scientific conference, there
is this nice workshop we are setting up, the week right after
the battlemesh.
http://diynetworking.net/ifipnetworking2017/
The theme of the workshop is exactly what we do in community networks,
so, along technical papers we also welcome non strictly technical
contributions to understand what is needed to empower people
to make "the Internet": experiences, architectures, incentives, governance,
success or failure cases are very useful, because normally these things
remain under the surface.
The full CFP is below, and the website of the main conference is here
with all the details: http://networking.ifip.org/2017/
I hope to see papers coming from some of the people of the BM community.
leonardo.
CFP: IFIP Networking 2017 - Interdisciplinary Workshop on DIY and
Community Networking, Stockholm, Sweeden
---------------------------------------------------------------------------
Our apologies if you received multiple copies of this CFP
---------------------------------------------------------------------------
CALL FOR PAPERS
IFIP Networking 2017 Interdisciplinary Workshop on DIY and Community
Networking
Place: Stockholm, Sweden
Date: June 12, 2017
http://diynetworking.net/ifipnetworking2017/
Important Dates
Abstract submission: March 20, 2017
Full paper: March 30, 2017
Notification of acceptance: April 10, 2017
Camera-ready papers due: April 27, 2017
DIY networking Workshop: June 12, 2017
Submission guidelines
http://diynetworking.net/ifipnetworking2017/submission.php
---------
Scope:
This workshop is a joint venture of three EU Horizon2020 projects, MAZI,
netCommons, and RIFE, in an effort to join forces around the design and
use of DIY and community networking technologies for the common good,
using a highly interdisciplinary and transdisciplinary approach. With
DIY and community networking we refer to a diverse set of networking
technologies that range from large-scale community networks to small
scale wireless installations supporting local applications accessible
only to those residing in the coverage area of the network. DIY and
community networking represent two frontier research themes that can
open new and exciting research and application areas. On the one hand,
the locality of DIY networks enables the design of hybrid spaces and
places for social sustainability, collective awareness, and
conviviality. On the other hand, community networking is one of the most
promising approach to overcome digital divide.
What bridges these two themes is the idea that networks are not only a
way to "access the Internet", but they are a way to connect people, and
people make "the Internet". This workshop will contribute to investigate
the way that local applications can influence the creation and the
governance of community networks, and how community networks can
stimulate the creation of novel local applications.
DIY and community networks are embedded with the local social
environment where they grow, so their study cannot be separated from the
understanding of their societal stimuli and societal impact. For this
reason the workshop will be highly interdisciplinary aiming to bridge
the communication gap between those that build the technology (computer
scientists, engineers, and hackers) and those that understand better the
complex urban environment where this technology will be deployed (social
and political scientists, urban planners, and designers). More
specifically, people working on applications and uses of ICT are not
always aware of the capabilities of technology for building local
communication networks, on the other hand, scientists in the field of
networking are often indifferent on the actual use and social
implications of the technical solutions they design. We believe that we
are currently in a moment in history when it is particularly important
to bridge this gap between engineering and social sciences, to create an
alternative to the current trend of centralization of resources and
control that is taking place at a global scale on the Internet.
Some of the themes that we want to be central in the workshop are:
- Technical contributions that render DIY networking technology easier
to understand and use by for less technically savvy people
- Theoretical contributions that can facilitate the understanding of the
various inherent trade-offs in the design of DIY networks and the
translation of engineering decisions to constraints and requirements for
applications developers and vice versa.
- The integration of community networking with DIY applications, models
of deployment, experiences of success and failure for this combination.
- The exploration of the trade-off between Internet access networks and
local networks for experimenters, hackers and citizens.
- The way DIY and community networks can be placed in the frame of other
horizontal and bottom-up experiences, such as Peer Production movements.
- The links and interrelations between DIY and community networking in
the frame of the models for alternative Internets, such as peer-to-peer
networking, overlay networks, blockchain technologies etc.
- Revisit key engineering questions, such as routing protocols, energy
consumption, automation, resiliency in light of the possible practical
uses of DIY networking technologies.
For the special interdisciplinary session we welcome the following types
of contributions:
- Demos of working prototypes of DIY networking applications or systems
- Posters or design mock-ups of imaginary applications
- Short tutorials on important concepts that can facilitate
interdisciplinary collaborations
- Other alternative formats like interviews, testimonies, artistic
treatments
-----
Organizing Committee:
Chairs
Panayotis Antoniadis (NetHood, CH)
Leonardo Maccari (University of Trento, IT)
Jörg Ott (Technical University of Munich, DE)
Arjuna Sathiaseelan (University of Cambridge, UK)
Programme Committee
Ileana Apostol (NetHood Zurich, CH)
Roger Baig (Guifi.net Foundation, ES)
Bart Braem (University of Antwerp, BE)
Dimitris Boucas (University of Westminster, UK)
Roberto Caso (University of Trento, IT)
Renato Lo Cigno (University of Trento, IT)
Manos Dimogerontakis (UPC, ES)
Melanie Dulong de Rosnay (CNRS, FR)
Felix Freitag (UPC, ES)
Mark Gaved (The Open University - Milton Keynes, UK)
Federica Giovanella (University of Trento, IT)
Christian Fuchs (University of Westminster, UK)
Ingi Helgason (Edinburgh Napier University, UK)
Karin Anna Hummel (Johannes Kepler University Linz, AU)
George Iosifidis (Trinity College Dublin, IR)
Jussi Kangasharju (University of Helsinki, FI)
Merkourios Karaliopoulos (Athens University of Economics and Business, GR)
Thanasis Korakis (University of Thessaly, GR)
Matthias Korn (University of Siegen, DE)
Iordanis Koutsopoulos (Athens University of Economics and Business, GR)
William Lieu (Auckland University of Technology, NZ)
Anders Lindgren (Swedish Institute of Computer Science Kista, SE)
Maria Michalis (University of Westminster, UK)
Leandro Navarro (Universitat Politècnica de Catalunya, ES)
Andrea Passarella (CNR - Pisa, IT)
Claudio Pisa (CNIT - Roma, IT)
Amalia Sabiescu (Loughborough University London, UK)
Douglas Schuler (Evergreen State College - Olympia, US)
Michael Smyth (Edinburgh Napier University, UK)
Felix Treguer (CNRS, FR)
Andreas Unteidig (UdK Berlin, DE)
_______________________________________________
Battlemesh mailing list
Battlemesh(a)ml.ninux.org
http://ml.ninux.org/mailman/listinfo/battlemesh
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
