Hi!
Yesterday I flashed a router with the MAC like xx:xx:xx:xx:xx:00 which
resulted in a 10.13.y.0/16 IPv4 (where y is different from 0, in this
/16 network the network identifier is 10.13.0.0).
It looks strange, ending with zero, but is valid right?
Thanks and sorry for the n00b question,
Ilario
Hi,
As my friend -in the cc field- is not in the developers mailing
list, please do not just reply to the list, please remember to cc him
in the case you want to reply through the list.
I am going to tell you about an event in Spanish with Spanish-speaking
people, so let me please change to Spanish... Apologies to non-Spanish
speakers.
Hola,
Hace dos semanas hicimos una pequeña presentación del proyecto de red en
malla en el barrio. Allí hablamos de Libremesh y a un amigo -en copia-
le moló el asunto. Me comentó la posibilidad de que LibreMesh estuviera
de alguna forma en la expo colectiva Rehogar [1] de Makea [2]. Él es
parte de Makea. Yo le comenté que conocía a algunes de les
desarrolladoreas de Libremesh y me ofrecí a poneros en contacto, por si
surgía la posibilidad de hacer un taller, una presentación o lo que sea...
Lo consultó con más gente de Makea [3] y le contestaron positivamente, o
sea que se podría hacer algo con LibreMesh allí.
Así es que creo que yo ya he cumplido mi misión de poneros en contacto.
Si queréis continuar la comunicación mediante esta lista, acordaos de
ponerle en copia en las contestaciones, ya que él no está sucrito a esta
lista.
¡Gracias!
[1] http://www.makeatuvida.net/?p=11723
[2] www.makeatuvida.net
[3] hola(a)makeatuvida.net
Most users expect to connect to 192.168.1.1 for the first login, as
defaults in OpenWrt and LEDE.
This should be the default also for LibreMesh in my opinion.
Can be done setting the main_ipv4_address parameter in lime-defaults
[1] to 192.168.1.1/24 instead of what we have now (10.%N1.0.0/16 where
%N1 depends on the chosen name of the AP interface and the last two
fields are chosen depending on the device mac address [2]).
Are there other ways?
Do you think that keeping the auto IPv4 assignment enabled by default
is worth the trouble?
Bye!
Ilario
[1] https://github.com/libremesh/lime-packages/blob/develop/packages/lime-syste…
[2] /16 seems good enough for avoiding collisions, checking the
birthday paradox [3] against a /16 range results that 300 hosts are
needed for having a 50 % probability of a collision. Neither the
possible collisions coming from the fallback mechanism for invalid
addresses [4] seem to be a problem.
[3] https://en.wikipedia.org/wiki/Birthday_problem
[4] https://github.com/libremesh/lime-packages/blob/develop/packages/lime-syste…
Thanks to everyone involved, finally we have an official release!
* generic binaries, meant for testing or setting up temporary networks
(i.e. when having the default AP SSID = LibreMesh.org is fine)
http://downloads.libremesh.org/community_chaos/16.07/
* customized binaries with chef, meant for stable community networks
(basically, you can preset a specific AP SSID and other settings
common to the whole network, and then flash many routers in a row)
can be generated at:
http://chef.libremesh.org/
Changelog since "BiggestBang" 15.09:
• Now based on OpenWrt Chaos Calmer 15.05.1
• Removed "firewall" package (which is included by default in vanilla
OpenWrt/LEDE), since it's not really being used in LibreMesh setup. It
can always be installed on a case-by-case basis using opkg.
∘ there's a new minimal system that runs /etc/firewall.lime on boot
(if "firewall" is not installed)
• Removed "odhcpd" since we're not using it at the moment (we use dnsmasq)
• Removed "odhcp6c" since we're not using it at the moment (we still
haven't solved how to deal with native IPv6 coming over WAN, i.e.
propagate a delegated prefix over the mesh in a reasonable way)
• New default packages: "lime-hwd-openwrt-wan" and "lime-proto-wan".
This checks if there's a WAN port, and automatically configures as "wan"
proto (lime-proto-wan). The "wan" proto let's you assign in
/etc/config/lime, for example, 802.1ad VLANs over the WAN port.
• New default package: "lime-hwd-ground-routing". Allows you to
configure 802.1q VLANs on embedded switches, so that you can separate
specific ports and put
• New default package: "bmx6-auto-gw-mode", so that when a node detects
(with watchping) it can ping 8.8.8.8 over WAN port, a bmx6 tunIn is
created on-the-fly, and Internet is shared to the rest of the clouds.
• Workaround for an spurious log message caused by BATMAN-Adv ("br-lan:
received packet on bat0 with own address as source address"): a "dummy0"
interface is created and added to bat0, with a slightly different MAC
address
∘ https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-March/011839.html
• New available packages: "lime-proto-bgp", allows to do BGP with bird
daemon; and "lime-proto-olsr", "-olsr2" and "-olsr6", which add support
for all versions of OLSR.
• Some new settings possible in /etc/config/lime-defaults
∘ wireless.htmode lets you preset the htmode for any wireless radio
(or htmode_2ghz and htmode_5ghz for specific bands)
∘ wireless.distance is the equivalent, for setting distance (and
distance_2ghz / _5ghz)
∘ system.domain for setting a cloud-wide domain name
• New "named AP" interface by default: in addition to the shared SSID
(where clients roam between nodes), there's a new AP with a different,
unique SSID (it includes the node hostname). This lets people easily
check with any stock smartphone (not only Android with a special app)
which nodes are online, nearby, and their respective signal strength.
Most importantly, it lets them connect to a specific AP and prevent
roaming, when they need it. Roaming is a nuisance if you're in the
middle of two nodes, with similar RSSI, but different performance
(bandwidth to Internet). Finally, it gives users a very easy way to
reliably access a specific (nearby) node webinterface, simply
associating to a specific AP and browsing to http://thisnode.info/
• Fixed all alfred facters (bat-hosts, dnsmasq-distributed-hosts,
dnsmasq-lease-share), so that they retry the "alfred -r" when it fails
(i.e. in slave mode)
• LiMe web interface received love:
∘ luci-app-lime-location (Simple Config -> Location) now works
∘ Simple Config -> Advanced
Thank you Gui and everyone involved for your work! The real chaos is starting!!
On 13 de setembre de 2016 21:06:35 CEST, bruno vianna <bruno(a)pobox.com> wrote:
>congrats!
>
>On Tue, Sep 13, 2016 at 11:44 AM, Gui Iribarren <gui(a)altermundi.net>
>wrote:
>
>> Thanks to everyone involved, finally we have an official release!
>>
>> * generic binaries, meant for testing or setting up temporary
>networks
>> (i.e. when having the default AP SSID = LibreMesh.org is fine)
>>
>> http://downloads.libremesh.org/community_chaos/16.07/
>>
>> * customized binaries with chef, meant for stable community networks
>> (basically, you can preset a specific AP SSID and other settings
>> common to the whole network, and then flash many routers in a row)
>> can be generated at:
>>
>> http://chef.libremesh.org/
>>
>> Changelog since "BiggestBang" 15.09:
>>
>> • Now based on OpenWrt Chaos Calmer 15.05.1
>> • Removed "firewall" package (which is included by default in vanilla
>> OpenWrt/LEDE), since it's not really being used in LibreMesh setup.
>It
>> can always be installed on a case-by-case basis using opkg.
>> ∘ there's a new minimal system that runs /etc/firewall.lime on boot
>> (if "firewall" is not installed)
>> • Removed "odhcpd" since we're not using it at the moment (we use
>dnsmasq)
>> • Removed "odhcp6c" since we're not using it at the moment (we still
>> haven't solved how to deal with native IPv6 coming over WAN, i.e.
>> propagate a delegated prefix over the mesh in a reasonable way)
>> • New default packages: "lime-hwd-openwrt-wan" and "lime-proto-wan".
>> This checks if there's a WAN port, and automatically configures as
>"wan"
>> proto (lime-proto-wan). The "wan" proto let's you assign in
>> /etc/config/lime, for example, 802.1ad VLANs over the WAN port.
>> • New default package: "lime-hwd-ground-routing". Allows you to
>> configure 802.1q VLANs on embedded switches, so that you can separate
>> specific ports and put
>> • New default package: "bmx6-auto-gw-mode", so that when a node
>detects
>> (with watchping) it can ping 8.8.8.8 over WAN port, a bmx6 tunIn is
>> created on-the-fly, and Internet is shared to the rest of the clouds.
>> • Workaround for an spurious log message caused by BATMAN-Adv
>("br-lan:
>> received packet on bat0 with own address as source address"): a
>"dummy0"
>> interface is created and added to bat0, with a slightly different MAC
>> address
>> ∘ https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-
>> March/011839.html
>> • New available packages: "lime-proto-bgp", allows to do BGP with
>bird
>> daemon; and "lime-proto-olsr", "-olsr2" and "-olsr6", which add
>support
>> for all versions of OLSR.
>> • Some new settings possible in /etc/config/lime-defaults
>> ∘ wireless.htmode lets you preset the htmode for any wireless radio
>> (or htmode_2ghz and htmode_5ghz for specific bands)
>> ∘ wireless.distance is the equivalent, for setting distance (and
>> distance_2ghz / _5ghz)
>> ∘ system.domain for setting a cloud-wide domain name
>> • New "named AP" interface by default: in addition to the shared SSID
>> (where clients roam between nodes), there's a new AP with a
>different,
>> unique SSID (it includes the node hostname). This lets people easily
>> check with any stock smartphone (not only Android with a special app)
>> which nodes are online, nearby, and their respective signal strength.
>> Most importantly, it lets them connect to a specific AP and prevent
>> roaming, when they need it. Roaming is a nuisance if you're in the
>> middle of two nodes, with similar RSSI, but different performance
>> (bandwidth to Internet). Finally, it gives users a very easy way to
>> reliably access a specific (nearby) node webinterface, simply
>> associating to a specific AP and browsing to http://thisnode.info/
>> • Fixed all alfred facters (bat-hosts, dnsmasq-distributed-hosts,
>> dnsmasq-lease-share), so that they retry the "alfred -r" when it
>fails
>> (i.e. in slave mode)
>> • LiMe web interface received love:
>> ∘ luci-app-lime-location (Simple Config -> Location) now works
>> ∘ Simple Config -> Advanced
>>
>>
>>
>> _______________________________________________
>> 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 ─█▄██▄▀█▀█▄
>skype: randomico▀─█▄██▄▀█▀█▄▌██─█▌█▌
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>lime-users mailing list
>lime-users(a)lists.libremesh.org
>https://lists.libremesh.org/mailman/listinfo/lime-users
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hello people,
back in sep/2014, Ilario suggested to register libremesh.org:
http://lists.libre-mesh.org/pipermail/dev/2014-September/000458.html
we did, and after a looong transition, we're finally finishing all the
renamings, right on time before the new release (so we're taking the
opportunity to launch 16.07 with the new name)
back in march, we took the decision to migrate everything, then at the
last meeting consensus was *against* migration (among concerns, was
breaking github urls, and such); but recently found out about github
retrocompatibility features, and finally reached consensus approving the
migration.
Affected:
* IRC: channel #libre-mesh is deprecated, join #libremesh from now on
* GitHub repos: all the legacy urls continue to work (but deprecated)
example:
git clone https://github.com/libre-mesh/lime-packages.git
still works, but you should clone from now on:
git clone https://github.com/libremesh/lime-packages.git
so all the existing lime-builds out there will continue to work,
pointing to the legacy URLs, pulling changes without problem
but if you're reading this, and have already existing repos in your
computers, please change remote's URLs, like so:
https://help.github.com/articles/changing-a-remote-s-url/
The only thing that will not work anymore is the old's organization
"homepage" in github, i.e. the list of repos
https://github.com/libre-mesh/
doesn't work anymore. use https://github.com/libremesh/ instead.
This caveat is mentioned in
https://help.github.com/articles/renaming-an-organization/
* Repo contents: everything was renamed in 1 commit to each repo branch:
https://github.com/libremesh/lime-build/commit/071a90b85https://github.com/libremesh/lime-build/commit/dde93693ahttps://github.com/libremesh/lime-packages/commit/4c0bd49e70https://github.com/libremesh/lime-packages/commit/7f18ad3597https://github.com/libremesh/lime-web/commit/b78a0d57c
* Chef: All the mentions about Libre-Mesh were replaced to LibreMesh
back in march/april already.
* Mailing lists: they'll be transparently renamed to
lime-*(a)lists.libremesh.org (pipermail archives, subscribers, etc)
and the @lists.libre-mesh.org will be deprecated (mail sent to the
deprecated address will be held, and senders notified the new addr)
this will also involve moving to a better maintained mailman server
This last step (mailing lists) is not done yet, to allow people to get
this notice first, and update their email filters / etc. Please do so,
since this email is the last one you'll get from *(a)lists.libre-mesh.org.
You'll soon get a "Welcome" message from lime-*(a)lists.libremesh.org
cheers! and see you on the other side of the mirror, with a freshly
cooked release.
2016-07-11 20:49 GMT+02:00 p4u <pau(a)dabax.net>:
> From the README: Or to use your own LiMe packages git repository and/or
> OpenWRT/LEDE (must be executed the first time make is invoked or after
> clean).
>
> make LIME_GIT="http://foo.git" <http://foo.git> T=ar71xx P=generic
> OWRT_GIT="http://foo.git" <http://foo.git>
>
I tried to compile LiMe on LEDE using lime-build develop, I simply issued:
make T=ar71xx P=generic OWRT_GIT="
https://git.lede-project.org/source.git"
but I noticed that there are lines in the feeds.conf file [1] included in
lime-build which are pointing to our static OpenWrt repos.
So, what is a good procedure to build LiMe on LEDE using lime-build?
Is it enough to remove those lines in the feeds.conf file and specify the
OWRT_GIT parameter pointing to LEDE source?
Thanks,
Ilario
[1] https://github.com/libre-mesh/lime-build/blob/develop/feeds.conf
Hi.
I was talking with Gui and we both agree on repointing
downloads.libre-mesh.org to builds.libre-mesh.org where there are
automatic builds (using lime-build) of develop and the current release
CommunityChaos 16.07 together with the package repositories for opkg. I
think that is the best option for stock/generic official firmwares. Then
Chef can be used for customizing those communities who need
customization. If someone does not agree we can open a discussion.
However after building the binaries, something took my attention. Now
the generated images are much smaller than before. The ar71xx-mini
target takes only 2.5M and the ar71xx with lime-full profile fits in a
4MB device. My first thinking was that the compilation was wrong but I
tested and everything is fine.
I know we clean up a bit the default packages list of lime-build and
also removed some of them which were not strictly necessary. But I was
not expecting such big difference on output firmware size. That is
actually great!
Cheers.
--
./p4u
Hi!
I saw Gui merged las fixes in 16.07 toniight, so i consider 16.07 is the
latest LiMe release I have just switched the default branch of lime build from
testin/16.07 to 16.07 so now it will build by default latest stable release :)
Congrats!
