19 Mar
2017
19 Mar
'17
11:38 a.m.
Hi Pau,
On Sat, Mar 18, 2017 at 07:30:51PM +0100, Pau wrote:
I've tried LEDE-17 snapshot (with kernel 4.4.52)
which will be the basis
for the next LEDE revision release. On this case netifd does not set up
correctly the ieee80211s interfaces. Adding a workaround to the netifd
scripts, it creates correctly the interface but then it starts crashing
again:
Please post that netifd patch or send it to me, so it can be added to
the 17.01.1 queue.
Now the magic question: Is that a build you compiled yourself or is
that the official 17.01.0 binary kernel crashing there?
Because to decypher those hex-numbers in the call trace we need the
debugging symbols...
Dammit...
Good that we try. Without users and people who regularly perform tests
things cannot improve. Now we crashed it, so let's find out why and fix
it.
Cheers
Daniel
On 18/03/17 00:33, Pau wrote:
On 18/03/17 00:28, Pau wrote:
--
./p4u
For the moment this is what happens when enabling
802.11s on a Tplink
WDR3500 (ath9k) and LEDE release 17.01.0
http://pastebin.ca/3782030
It looks quite horrible... I'm not sure if we can use it for the next
release. If anybody has some data regarding this, please share.
Cheers.
Without the AP interfaces, 802.11s interfaces do not crash. So it is
something related with the combination AP + ieee80211s.
On 14/03/17 10:04, Gio wrote:
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
On Tuesday 14 March 2017 02:25:02 Pau wrote:
> From long time ago LibreMesh supports 802.11s as link layer protocol for
> the WiFi/mesh connections (with deactivated HWMP, the routing layer).
> Traditionally we have been using Ad-Hoc (IBSS) for linking the nodes but
> it is old and broken on most of the current WiFi drivers.
>
> 802.11s has some advantages like:
>
> * easy setup (just mode=mesh)
> * several 802.11s virtual devices supported in a single WiFi interface
> * supports encryption
> * it has power saving support, so better for mobile devices
> * better and more driver support
>
> So as already discussed on some other mailing thread, I propose to use
> it by default instead of IBSS on the next LibreMesh release.
>
> Of course it will break the compatibility with older releases. But IMHO
> it is better now than in the future, in any case we will probably have
> to do it soon or later. In addition anyone who want can use IBSS
> instead, can use Chef or lime-build to generate an image firmware. It is
> as easy as adding "list proto adhoc" into /etc/config/lime-defaults.
>
> Please, speak up. Silent will be considered acceptance :)
Some LimeCat ago ( there was at least Pau, Gui, me, Ilario, Al and some more i
don't remember ) we agreed on switching to 802.11s instead of adhoc for next
release, so IMHO we just need to test it a lot before releasing and we are
done with this, moreover i would like to ear from qmp people because if we
switch together we could keep interoperating and this would be a plus
Cheers!
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev