Hello meshies
I know everybody is having fun at Battle Mesh, but if someone could take a
look at this I' d really appreciate.
I really have my eyes on the C50, as it seems to be the cheapest dual-band
on the market now. I can get on in Brazil for less than 40 USD! Last week I
bought one which I later found out to be an unsupported V2. But now I got a
V1, and it almost works. If it works, I'll the buy about 10 for an
installation in two weeks.
The problem seems to be with 802.11. The 2.4Ghz radio does not work in
ad-hoc mode - although the 5Ghz radio does. Then I don't know if it's
related, but when it meshes with a WDR3500, the Internet is painfully
slow, with some ping times about 1000-2000 milliseconds. Pinging from the
LiMe gateway at the same time gives me a steady 57ms. Perhaps a different
driver should be used?
Attached is a file with information gathered from the router.
A few other oddities (not as important as the issue above):
- Could not flash from stock directly with the compiled LiMe. I had to
first use this openwrt [1], then LiMe
- When I flash from the firmware above with the LiMe I compiled or the
download Lede, I get the message:
" It appears that you try to flash an image that does not fit into the
flash memory, please verify the image file!
Size: 7.63 MB (7.62 MB available)"
It works fine, tough.
- The firmware I cooked with my community settings (using cooker) won't go
through to the Internet, and gives this ESSID instead of my
community's:{{NETWORK_NAME}} (although it meshes with the LiMe gateway)
- The firmware I cooked without community settings connects to the Internet
through the LiMe gateway with the sluggish times above.
Thanks!
[1]
http://dl.eko.one.pl/luci/chaos_calmer/ramips/luci-15.05-ramips-mt7620-Arch…
--
bruno(a)pobox.com ▀─█▄██▄▀▄
http://brunovianna.net ─█▄██▄▀█▀█▄
skype: randomico▀─█▄██▄▀█▀█▄▌██─█▌█▌
Hey sisters,
Let me share some good news for community networks -and bad ones for ISPs:
0.- Bitmessage has been working on LAN peer auto-discovery. It is
already in v0.6 branch, we tested it and it works.
1.- Retroshare will finally have asynchronous messaging working
(Retroshare already has LAN peer auto-discovery).
2.- Impressive ZeroNet is aware of the importance of LAN peer
auto-discovery and they are going to add this feature.
Hi,
Sometimes I explain what this community network thing is to someone in
my district. They likes the idea and they has an ISP router. Then I ask
them if they would like to share their Internet connection and they says
"yes, why not?". But then they asks if users in the community network
could have access to their private home network. I answer they could,
but it can be avoided in different ways -create different VLANs in the
ISP router, configure a firewall, closing ports in the computers...
Then they stops liking this community network thing.
It is frustrating, because many people do not share their Internet
connection because of this, and so we lose the resources we need.
I was wondering if there would be a way that LiMe could come
preconfigured in such a way that, when an Internet gateway is added, it
could only communicate to that ISP router, and no other host in that
private network. I mean to automatically create the proper firewall
rules so that the LiMe network could not access hosts in private networks.
That would not be real security, as that configuration could be removed
by any administrator in the community network, but we would be able to
start our answer saying "by default LiMe cannot enter into your private
network", and then explain what they could do to improve their security.
What do you think of it?
Have you found this obstacle?
What would you reply to that person?
Is my proposal doable?
If so, should I open a Github issue? Where? In lime-packages?
I just cooked a firmware with the cooker for the tp-link cpe-510. It is
similar to the nano loco m5 - 45 degrees horizontal angle, 13dbi, and 5ghz
only in this case. Costs around USD 65 here.
Everything seems to be fine. It uses adhoc mode by default, so it connected
immediately to a wdr3500 with lime 1605 from another network which I had
lying around.
The reason I'm flashing these is that we installed a small network in a
favela here last week, and the wdr3500 didn't have enough reach. Not only
the nearest nods were far (anything from 200m to 2km), but also all the
interference we had (it's a really dense neighborhood) made any link with
more than 100m very poor. The plan now is to connect the most important
nodes with those.
Abraços
Bruno
--
bruno(a)pobox.com ▀─█▄██▄▀▄
http://brunovianna.net ─█▄██▄▀█▀█▄
skype: randomico▀─█▄██▄▀█▀█▄▌██─█▌█▌
Hi guys, apologize for reorganizing this conversation again. I think it
is better for it to have its own thread.
So, to recap, the conversation comes from the thread "Recommended
devices?":
Patricio Gibbs on 07/27/2017
The conversation in this thread has documented some useful knowledge.
Is there a place to compile this information in a list of
compatible devices?
I see the mostly empty list at:
http://libremesh.org/docs/hardware/
Such a list could be part of a guide about how to choose a device,
or how to guess whether a device might work or is definitely
unsupported.
Bruno Vianna on 07/29/2017
I like the idea too, but it would be much easier if it were a wiki or
some kind of editable page.
I contribute to openwrt's wiki every time when I find out info on a new
device.
I understand the content from libremesh is in github, but it is a lot
more bureaucratic to edit the html, push it, wait for merge...
So, dear libremesh site managers, do you think we can have a wiki or
some open content solution?
We talked with Gui/Gio/Pau/NicoE about this and think that would like
to make a decision that reinforces the community, so instead of pushing
a specific implementation, it is better to share our perspectives on
the subject and consider experimenting something a bit in the way to
the "advice process" http://www.reinventingorganizationswiki.com/Decisi
on_Making, which we are implementing as:
someone who is in a good/the best place to make this decision (can mean
many things but let's consider responsible for implementing and
maintaining, and accountable for the results... who would be me so far)
will lead an "advice process" which means receiving advice from all
those who can have relevant contributions and/on will be affected by
it, meaning you.
So this is a brief of the points of that group, which I'll share since
I consider valuable for all to know them:
Pro "current state"
We left RedMine because it was not working, people was not contributing
and the info was not being updated. Now that it is more code-related
the info is kept in a more coherent way.
On GitHub there is the "Edit" button.
It is not necessarilly bad to have to wait for a Pull Request to be
accepted.
Pro "Wiki"
Now we are a bigger communitty, how do we enhance involvement?
We can make a monthly test with the GitHub wiki with the unnoficial
info like "experiences with hw", "specific tutorials", "cases" and so.
The downside of the github wiki is that it can only be editted by
collaborators of the repository.
So based on this information, which key points would be relevant to
consider to move forwards?
Please share your points of view so we move on to have a definition.
As said, it is an experiment of using a decision making method which
seemed to us can be a good one for the kind of community we work to
build. Please then shared also your feedback about this.
Part of this process has been promoted by a relative new member of the
community (5 months or so), Rodrigo Monelos, who has been mainly acting
as facilitator and Agile coach on the LibreRouter project, so he will
be helping also with the coordination of it.
I hope he can introduce himself to come out of the shadows :)
Regards,
Sorry for the spam, but I thought it would be interesting for someone,
it's just the motherboard without antennas nor chassis of a TP-Link
WDR4300 for 23 € on aliexpress
---------- Messaggio inoltrato ----------
Da: Leonardo Maccari <mail(a)leonardo.ma>
Date: 28 giugno 2017 14:41
Oggetto: [Ninux-Wireless] tp-link 4310 refurbished
A: wireless(a)ml.ninux.org
Ciao,
long story short: Dopo il BM qualcuno mi ha chiesto di contattare
Panayotis (un ricercatore che conosco) per sapere dove ha preso le
device che hanno usato per uno workshop ad Atene. Ecco la risposta:
https://www.aliexpress.com/item/openwrt-firmware-5g-wifi-2-port-usb-router-…
ciao,
leonardo.
_______________________________________________
Wireless mailing list
Wireless(a)ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
You must have heard about hurricane that destroyed north carribean islands this month. I am organizing a mission to send to Dominica a bunch of router to help country to recover Internet coverage.
https://www.google.fr/search?q=maria+dominica&client=firefox-b&dcr=0&prmd=i…
I am conducting donation events in France and Internet to send first help.
I am contacting libre mesh group for getting support and help about disaster Internet solution we could provide.
Thanks everyone
Fred. http://madeinzion.org
Hello,
I found the qmp.cat project and it looks to me like a similar user scope.
Do they have very different approaches?
Would a merge be possible (looks like some devs are already in both
projects).
Best regards,
Paul
So, this release was meant to be announced many months ago (as the
numbering suggests) but lack of coordination (me, gio, pau) delayed it.
In the meantime, some more fixes and improvements were introduced, and
most importantly, several (unpublished) intermediate "release
candidates" have been running for months now, in different community
networks (QuintanaLibre mainly, thanks to persevering NicoEchaniz, and
other smaller deployments)
Highlights are that ieee80211s is used by default (instead of adhoc)
which breaks "backward" connectivity with previous releases,
as well as changes in vlan tagging policy of bmx6 and batadv (which also
are not backwards compatible by default)
most notably, this vlan change fixes a hard-to-debug mtu shrinking bug
that pestered all releases so far (symptoms were varied and bizarre,
like having timeouts when trying to browse certain https sites,
sometimes, on random devices)
the biggest highlight on the dev side, is that we now use upstream SDK
(thanks to dangowrt for pushing this, and pau for implementing it!)
which brings us much closer to LEDE/OpenWrt and allows reporting
upstream ath9k bugs or such, among other benefits
* 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/dayboot_rely/17.06/targets/
(build is running right now, binaries should be ready tomorrow for sure)
* for custom builds, the recommended tool at this point is lime-sdk
http://libremesh.org/getit.html#cook_your_own_firmware_using_lime_sdkhttps://github.com/libremesh/lime-sdk
* chef builds are not available at this point. there are plans to
integrate this release into chef in the future, but no ETA :(
###
Most of the following changelog was accomplished during the 2017/03
hackaton (https://www.youtube.com/watch?v=5UX1FwhIKGY)
Changelog Dayboot Rely 17.06 (since 16.07)
* based on LEDE 17.01.2
* build everything using LEDE SDK, via new lime-sdk cooker (instead of
lime-build)
* use ieee80211s instead of adhoc
* reintroduced "firewall" package (to keep closer to upstream)
* 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: new wifi mode client
* lime-system: set dnsmasq force=1 to ensure dnsmasq never bails out
* lime-system: explicitly populate /etc/config/lime with calculated values
* 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-hwd-ground-routing: ground routing now supports untagged ports too
* 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-wan: allow link-local traffic over wan (useful for local
ping6 and ssh, without global exposure)
* 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
* lime-proto-bmx6: don't tag bmx6 packets over ethernet and so use at
least mtu=1500 everywhere
* lime-proto-bmx6: avoid autodetected wan interface use vlan for bmx6
* 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
* watchping: convert to procd and add reload triggers
* safe-reboot: fix, use /overlay/upper instead of /overlay
* safe-reboot: add "discard" action
* ath9k: debugged some hangs (interface is deaf) and workaround it,
with new package "smonit"
* set wifi default "distance" parameter to 1000 metres and make it
configurable through webui
* alfred: fix bat-hosts facter, check for errors and don't nuke
/etc/bat-hosts in case of failure
* introduce new lime-basic-noui metapackage
* new packages separated: lime-docs and lime-docs-minimal
* various Makefile dependency problems fixed
known bugs:
* safe-reboot: newly introduced "discard" action is half-baked, avoid
usage until next release:
It doesn't check whether there's a backup to restore or not -
https://github.com/libremesh/lime-packages/issues/203
so executing "safe-reboot discard" without having done "safe-reboot"
first, will brick the router.
(unbricking is possible via failsafe boot, and doing "mount_root &&
firstboot")
In the commit log authors you can see the usual suspects ;)
but happily many new names!
https://github.com/libremesh/lime-packages/graphs/contributors?from=2016-09…
and remember it's not only code/commits what matters, so big thanks as
well to everyone participating in mailing lists, maintaining website,
documentation (spread around the web, in many languages!)
