I have a test-network running with a bunch of ac/an Adapters.
I got connections up to 866MBits between the adapters (5Ghz mesh) but even
with this fast connection I only got 40Mbit up/down Speed in direction to
the internet.
Only on the one Adapter connected directly to the Internet i got the full
speed (250/40).
I also played around with distance parameters with no measurable impact.
Are there other possibilities to speed up the mesh?
Thanks in advance,
Andy
Great news:
SAn TAGGED A RELEASE CANDIDATE FOR THE LIBREMESH 20.09 RELEASE!!
Even if the LibreMesh development never stopped, it was since the 17.06
"Dayboot Rely" release that we didn't have an _official_ release.
The goal is to have the **final release at the beginning of November**.
This means that the release candidate needs testing, bug fixing and
loads of community love before the end of October, so that we can have
an amazing release that can actually ease the creation of community
networks everywhere :)
We can coordinate the efforts on this mailing list and on the
IRC/Element chatroom (Element is the new name of Riot chat):
https://libremesh.org/communication.html
Seems that the next release will be (at least initially) source-only,
which means that you will have to compile it yourself on top of OpenWrt
18.06.8 or 19.07.4. Right now there's no way to download the
pre-compiled binary, but I hope this will be available at some point.
In order to compile the release candidate follow the instructions from
the Development page:
https://libremesh.org/development.html
As you can see in the compiling instructions, both OpenWrt 18.06.8 or
19.07.4 can be used as a base, but I think we should have more testing
on the newest 19.07.4 (until now the testing has been focussed mostly on
18.06.8).
There's no need to select the release candidate branch for the
compilation, seems that the master branch will be used also for the
testing and the relevant commits will be cherry-picked in November (SAn,
please correct if I'm wrong).
You can see the known issues on the tickets list:
https://github.com/libremesh/lime-packages/issues
And if you want to take care of an issue (thanks!!!), please have a look
at these lists where you can find some indication of the priority:
https://github.com/orgs/libremesh/projects/2
A last thing:
do we need a codename for the release or "20.09" is enough?
Propose your favourite name, starting with the "E" letter if possible,
on the chatroom and then we'll organise a poll :)
Thanks!!!
Ilario
--
Ilario
iochesonome(a)gmail.com
ilario(a)sindominio.net
>From https://libremesh.org/docs/en_config.html
*The idea behind this structure is that the user only modifies
/etc/config/lime but /etc/config/lime-defaults always keeps the original
configuration.*
There is no /etc/config/lime anymore
--
Regards
Jürgen
Recorded with *Nat.app* <http://Nat.app>
My mesh consists of 3 Picostations and 4 Ape522II, all of them are
configured as originators.
1 Picostation and 2 Ape522II are connected to two different ISP routers.
Should they be configured as gateways? And if so how to do it?
Regards
Jürgen
Some more info:
The device with firmware: LiMe master development (master rev. 0e6dbe1f
20201019_1851) / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01 shows
the errors mentioned
The device with firmware: LiMe master development (master rev. 2c4b783
20201001_1200) / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01 shows
no error at all
Regards
Jürgen
Am Mi., 28. Okt. 2020 um 10:08 Uhr schrieb Juergen Kimmel <
juergenkimmel(a)gmail.com>:
> When I'm connected to this device "thisnode.info" doesn't work
> Regards
> Jürgen
>
> Am Mi., 28. Okt. 2020 um 10:03 Uhr schrieb Juergen Kimmel <
> juergenkimmel(a)gmail.com>:
>
>> Here are some excerpts from syslog which look suspicious to me:
>> Tue Oct 27 22:03:09 2020 daemon.err babeld[1491]: Warning: keyword
>> "wired" is deprecated -- please use "type" instead.
>> Tue Oct 27 22:03:09 2020 daemon.err babeld[1491]: Warning: keyword
>> "wired" is deprecated -- please use "type" instead.
>> Tue Oct 27 22:03:09 2020 daemon.err babeld[1491]: Warning: couldn't
>> determine channel of interface eth0-1_17.
>> Tue Oct 27 22:03:09 2020 user.notice mac80211: Failed command: iw phy
>> phy1 set antenna 0xffffffff 0xffffffff
>> Tue Oct 27 22:03:09 2020 daemon.notice netifd: radio1 (1153): command
>> failed: Not supported (-122)
>> Tue Oct 27 22:03:10 2020 user.notice mac80211: Failed command: iw phy
>> phy1 set distance 100
>>
>> Tue Oct 27 22:03:15 2020 user.notice ucitrack: Setting up
>> /etc/config/firewall reload dependency on /etc/config/miniupnpd
>> Tue Oct 27 22:03:15 2020 daemon.crit dnsmasq[2005]: directory
>> /tmp/resolv.conf.d/resolv.conf.auto for resolv-file is missing, cannot poll
>> Tue Oct 27 22:03:15 2020 daemon.crit dnsmasq[2005]: FAILED to start up
>> Tue Oct 27 22:03:15 2020 daemon.info procd: Instance dnsmasq::cfg01411c
>> s in a crash loop 6 crashes, 0 seconds since last crash
>>
>> Tue Oct 27 22:03:20 2020 daemon.notice procd: /etc/rc.d/S90batmand: uci:
>> Entry not found
>>
>> Tue Oct 27 22:03:21 2020 daemon.err hostapd: Using interface wlan0-ap
>> with hwaddr 7a:a3:51:16:da:89 and ssid "MarinaMalgrats"
>>
>> Tue Oct 27 22:03:22 2020 kern.warn kernel: [ 45.557225] ieee80211 phy1:
>> rt2800_config_channel: Warning - Using incomplete support for external PA
>>
>> Tue Oct 27 22:03:25 2020 daemon.err babeld[1491]: Warning: couldn't
>> determine channel of interface wlan0-mesh_17.
>>
>>
>> Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: Warning: couldn't
>> determine channel of interface wlan1-mesh_17.
>> Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: send: Address not
>> available
>> Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: send: Address not
>> available
>> Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: send: Operation not
>> permitted
>>
>> Wed Oct 28 08:32:56 2020 daemon.crit dnsmasq[3050]: directory
>> /tmp/resolv.conf.d/resolv.conf.auto for resolv-file is missing, cannot poll
>> Wed Oct 28 08:32:56 2020 daemon.crit dnsmasq[3050]: FAILED to start up
>>
>> Regards
>> Jürgen
>>
>>
>> Am Mi., 28. Okt. 2020 um 09:49 Uhr schrieb Juergen Kimmel <
>> juergenkimmel(a)gmail.com>:
>>
>>> *Juergen do you have the lime-proto-wan selected *
>>> Yes
>>>
>>> Am Di., 27. Okt. 2020 um 21:44 Uhr schrieb Daniel Golle <
>>> daniel(a)makrotopia.org>:
>>>
>>>> On Tue, Oct 27, 2020 at 05:25:32PM -0300, SAn via lime-users wrote:
>>>> > Hi!
>>>> >
>>>> > On 10/27/20 5:14 PM, Daniel Golle wrote:
>>>> > > On Mon, Oct 26, 2020 at 12:07:24PM +0100, Juergen Kimmel wrote:
>>>> > >> I learned from the config.buildinfo that firewall has not been
>>>> selected
>>>> > >> The settings of the switches are identical.
>>>> > >> May disabling the firewall have been the culprit?
>>>> > >> I flashed the same device again there is no error and client has
>>>> internet.
>>>> > >
>>>> > > Ah, of course, without any firewall installed there is also no
>>>> > > NAT / masquerading happening, so if you want that, you do need
>>>> > > something to configure that (such as OpenWrt's 'firewall' package').
>>>> >
>>>> > AFAIK we recommend in the docs to use the package
>>>> lime-hwd-openwrt-wan that selects lime-proto-wan.
>>>> > This package provides the NATing rules without the need of the
>>>> firewall package.
>>>>
>>>> It never matched my requirements and I never saw a reason not to use
>>>> OpenWrt's firewall package. I've heard some vague myths about OpenWrt's
>>>> firewall not working well with some of the routing protocols used in
>>>> libremesh, but all attempts to reproduce that or inquire what the
>>>> problem was or is remained without substancial results.
>>>> I guess there are some historic reasons for some people to still
>>>> hestitate using OpenWrt's firewall (ie. fw3 nowadays), maybe some bug
>>>> which has long been resolved or simply not (auto-)adding the rules
>>>> needed to also run routing protocols on the WAN interface (which I've
>>>> fixed some years ago).
>>>>
>>>> >
>>>> > Daniel maybe you are not using lime-proto-wan in your deploys?
>>>> Juergen do you have the lime-proto-wan selected?
>>>> > Maybe the automatic selection that is donde by lime-hwd-openwrt-wan
>>>> is not working in this device?
>>>> >
>>>> > Best!
>>>> > SAn
>>>> > _______________________________________________
>>>> > lime-users mailing list
>>>> > lime-users(a)lists.libremesh.org
>>>> > https://lists.libremesh.org/mailman/listinfo/lime-users
>>>> _______________________________________________
>>>> lime-users mailing list
>>>> lime-users(a)lists.libremesh.org
>>>> https://lists.libremesh.org/mailman/listinfo/lime-users
>>>
>>>
Hi SAn,
sounds ok for me ;-)
I am using Netgear ex6120 and ex6130 Adapters. they seem to be technically
the same but the 30er has in addition an power Outlet/throughput.
How is this backport fork working? Thank you!
Regards,
Andy
Am Mo., 26. Okt. 2020 um 15:06 Uhr schrieb SAn <spiccinini(a)altermundi.net>:
> Hi Andy!
>
> On 10/26/20 10:57 AM, Andy Schopf wrote:
> > Thanks for your feedback Ilario :-)
> > I think some new branch would be great, as the problem exist in a future
> openwrt release (not the actual 19.xx).
> > So it should only be corrected for the next release I think.
>
> I think that the policy should be that we always add support to
> openwrt/master (snapshots) in a backward compatible way when possible. If
> it is not possible then we ask ourselves what to do depending on the case,
> I mean, how much it will brake in each case.
>
> After the 20.09 release I think we can drop OpenWrt 18.x support and focus
> on 19.x and snapshot but prioritizing 19.x over openwrt/master (the
> rationale is to deliver the a stable experience).
>
> Andy, what device do you need that it is only in master? Some can be
> easily backported to 19.x in a local fork of openwrt. I know this have its
> pros/cons but relying in snapshots is also very unstable and time consuming.
>
>
> Best!
> SAn
>
Model ZBT-APE522II
Architecture MediaTek MT7620A ver:2 eco:6
Firmware Version LiMe master development (master rev. 0e6dbe1f
20201019_1851) / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01
Kernel Version 4.14.195
The device is connected to the ISP router and gets IP via DHCP
Ping of the network diagnostic is successful
No internet for clients
Where to look at?
--
Regards
Jürgen
