14 Mar
2017
14 Mar
'17
1:25 a.m.
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 :)
Cheers.
--
./p4u
14 Mar
14 Mar
9:04 a.m.
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!
17 Mar
17 Mar
11:28 p.m.
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.
On 14/03/17 10:04, Gio wrote:
On Tuesday 14 March 2017 02:25:02 Pau wrote:
--
./p4u
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
11:33 p.m.
On 18/03/17 00:28, Pau wrote:
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:
--
./p4u
On Tuesday 14 March 2017 02:25:02 Pau wrote:
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
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
18 Mar
18 Mar
6:30 p.m.
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:
http://pastebin.ca/3782639
Dammit...
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:
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
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
19 Mar
19 Mar
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
7 p.m.
On 14/03/17 10:04, Gio wrote:
On Tuesday 14 March 2017 02:25:02 Pau wrote:
Yeah, will we great if qMp move to 802.11s together. Pau, you answered
me in qMp mailing list[1], so I understand that we can find the best
moment to change together.
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!
[1] https://mail.dabax.net/pipermail/qmp-users/2017-March/000999.html
2619
days inactive
2624
days old
6 comments
4 participants
participants (4)
-
al -
Daniel Golle -
Gio -
Pau