Hi guys,
We are here with George from Sarantaporo testing this UniFi AC Mesh
devices.
We successfuly flashed two of them that are meshing with each other and
with other devices through 2.4ghz and 5ghz with AC.
The problem is that the throughput is not very good.
Doing a netperf, we get (on the AC link):
root@LiMe-3c5540:~# netperf -H fe80::f29f:c2ff:fe3e:5435%wlan0-mesh
netperf -cCD1 -t tcp_maerts -l30MIGRATED TCP STREAM TEST from ::0 (::)
port 0 AF_INET6 to fe80::f29f:c2ff:fe3e:5435%wlan0-mesh () port 0
AF_INET6 : demoRecv Send Send Socket
Socket Message Elapsed Size Size Size Time
Throughput bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.06 55.41
and on the 802.11g link:
root@LiMe-3c5540:~# netperf -H fe80::f29f:c2ff:fe3d:5435%wlan1-mesh
netperf -cCD1 -t tcp_maerts -l30
MIGRATED TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to
fe80::f29f:c2ff:fe3d:5435%wlan1-mesh () port 0 AF_INET6 : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 11.88 1.19
So... pretty crappy, isn't it? (the devices are 30cm away from each
other, and no wireless traffic is around but those.
Also, another thing called my atention.
These are the luci wireless outputs for both of the devices.
Isn't it strange that both of them have high reception speed and super
slow transmission speed with each other?
We have already tried changing the channels.
Also tried to avoid 11s/adhoc and connect as client/master.
The outcome is the same:
root@LiMe-3c5540:~# netperf -H fe80::f29f:c2ff:fe3c:5435%wlan0-1
netperf -cCD1 -t tcp_maerts -l30MIGRATED TCP STREAM TEST from ::0 (::)
port 0 AF_INET6 to fe80::f29f:c2ff:fe3c:5435%wlan0-1 () port 0 AF_INET6
: demoRecv Send Send Socket
Socket Message Elapsed Size Size Size Time
Throughput bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.01 62.59
I haven't tried all this configs yet: https://wiki.openwrt.org/doc/uci/
wireless#ac_capabilities
But maybe there is some knowlege in the group that can help on this.
What do you think about this?
Regards,
Hi guys,
George from Sarantoporo and I are trying to give support to a new
device (yes, couldn't we start from something easier, right?).
Could you give us some guidance on supporting a new device that
apparently has only changed the Storage structure from the previous
version.
Unsupported new version: Xiaomi Mi Router 3:
https://wiki.openwrt.org/toh/xiaomi/mir3#mtd_output_from_stock_firmware
Supported old version: Xiaomi Mi Router Mini:
https://wiki.openwrt.org/toh/xiaomi/mini#mtd_partitioning
We have already collected all the relevant information in the Wiki
What users in the forum were saying is that the 'only thing' that needs
to change is the MTD definition, but I don't know how to do it. Any
guidance? I have the devices in front of me and I'm open to brick them
(they have a recovery partition method embedded so it is not a problem
apparently)
The problem is that there is no developer with one of them at hand...
and I have it in front of me ... so why don't we try and have it
supported? It is a very neat device (28 euros for a dual band, ufl-
attached 3 antenna router with 128 storage, 64 ram, usb...)
Any suggestion?
Regards,
Hi all,
currently images with different flavors look the same.
---/lime_mini/lede-17.01.2-libremesh-ar71xx-generic-tl-wdr3600-v1-squashfs-factory.bin
/lime_default/lede-17.01.2-libremesh-ar71xx-generic-tl-wdr3600-v1-squashfs-factory.bin
Would it be possible to use the EXTRA_IMAGE_NAME (already used to add
"libremesh") to add the flavor as well?
lede-17.01.2-libremesh-lime_default-ar71xx-generic-tl-wdr3600-v1-squashfs-factory.bin
I think it wouldn't cause any split("-") troubles in scripts as the -v1-
is already individual per profile.
Best,
Paul
Hi Libremesh Dev Team,
I am Senthilkumar from India. This year Battlemesh V10 event. I heard about
the Libremesh firmware and how it makes easy to create a mesh network on
single flash.
I really like the implementation and want to flash the Libremesh firmware
in my existing community wireless nodes.
I am using GL-INET AR150 routers for all my existing nodes. But I couldn't
able to find the correct firmware for the
https://wiki.openwrt.org/toh/gl-inet/gl-ar150 router.
Can you please help me on finding the right firmware for this router.
Looking forward to hear from you.
--
Thanks and Regards,
* • **Senthilkumar M*
* • **Community Manager,*
* • **Google Developer Group Madurai**,*
*• **Mentor, Metoomentor.org*
* • **Senior Research Engineer, Qualcomm. *
* • allaboutsenthil.in <http://allaboutsenthil.in>*
• +91 8095207092
I tested the proposed approach and below patch again after updating my
machine to ubuntu 16.04 with 4.8.0 kernel and there ip4-in-ip6 and
ip6-in-6ip all just works out of the box. No need to configure ip6tnl0
tunnel in any mode. It seems enough that bmx6 already configures the
bmxdefault tunnel device in any/ipv6 mode with a :: remote address.
First packet of an icmp request sequence at the receiving side always
pops out of the bmxdefault tunnel. Then, its reply triggers the creation
of a dedicated bidirectional tunnel also at the receiving side which is
used for following request and reply icmp packets. No fake ipv6 tunnel
addresses are used anymore!
To ensure backwards compatibility it should be checked how kernels in
already deployed openwrt and Lede based lime version behave.
cu
/axel
On 14.06.2017 07:30, Henning Rogge wrote:
> On Wed, Jun 14, 2017 at 7:18 AM, Axel Neumann <neumann(a)cgws.de> wrote:
>> I put a patch for bmx6 in this branch
>> https://github.com/axn/bmx6/commits/master.NonFakeTunAddresses
>> https://github.com/axn/bmx6/commit/5dc6678cf9c2887ca5e32c8d7527c5f660ddb7e9
>>
>> But due to the current kernel behavior it does not acceppt ip4-in-ipv6
>> tunnelled packets if the remote tunnel address is not explicitly
>> specified and matching with the incoming tunnel packet. For ip6-in-ip6
>> it works.
>>
>> The problem is addressed by below linked patches. But none of them seems
>> to have been applied to current kernels. If somebody known or finds out
>> an alternative solution would be great.
>>
>> /axel
>>
>> http://lists.openwall.net/netdev/2014/10/29/20
>> http://archive.linuxvirtualserver.org/cgi-bin/mesg.cgi?a=lvs-devel&i=53D75B…
>
> Maybe we should ask about these patches again on netdev?
>
> Current behavior is a bit inconsistent and stupid.
>
> Henning
>
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
