27 May
2013
27 May
'13
7 p.m.
In eigennet firmware we really didn't have a build system, so have an autconfig
script inside the device make a lot of sense, but in libre-mesh we have lime-
build and chef, so were we put the limit between autobuild and autoconfig ?
Autoconfig works well on simple devices like picostation or nanostation, but on
more complex setup like the black tplink is not the good approach, so i was
thinking about completely moving to a build + profile system without or with
minimal autoconfig script on the device
what do you think about that ?
27 May
27 May
8:07 p.m.
On 05/27/2013 04:00 PM, Gioacchino Mazzurco wrote:
In eigennet firmware we really didn't have a
build system, so have an autconfig
script inside the device make a lot of sense, but in libre-mesh we have lime-
build and chef, so were we put the limit between autobuild and autoconfig ?
Autoconfig works well on simple devices like picostation or nanostation, but on
more complex setup like the black tplink is not the good approach, so i was
thinking about completely moving to a build + profile system without or with
minimal autoconfig script on the device
what do you think about that ?
We actually use a complete auto-config system for the different router
models we use.
The chef is used to customize the final firmware if you need to, but if
you just use a basic AlterMesh firmware without customizaton it will
"just work".
I believe auto-configuration is one of the important aspects of all this
project. Maybe we can look a bit more into the auto-config approaches in
the three existing firmwares and get ideas from all.
AlterMesh auto configuration is this package:
https://colectivo.altermundi.net/projects/altermesh-packages/repository/sho…
And the auto-gw-mode:
https://colectivo.altermundi.net/projects/altermesh-packages/repository/sho…
(guido did you push your last changes to the repo?)
I believe that in our roadmap we should first check that the
configuration for both network models (batman+bmx everywhere & bmx on
border nodes) are known and tested, and then adapt our auto-config
systems to create those configurations automatically.
Is the work done by gui and gio on the manual config (done in Berlin)
available somewhere?
8:20 p.m.
I agree, the system should be 100% auto-configurable. So the user can
download a generic image, install it and enjoy it. This is the same
approach we are following in qMp.
I think, to achieve that, we should start defining a list of heuristics
to use, for instance:
- WiFi channel
- WiFi model
- IPv6/IPv4 addressing
Cheers
On 27/05/13 22:07, NicoEchániz wrote:
On 05/27/2013 04:00 PM, Gioacchino Mazzurco wrote:
--
./p4u
In eigennet firmware we really didn't have a
build system, so have an autconfig
script inside the device make a lot of sense, but in libre-mesh we have lime-
build and chef, so were we put the limit between autobuild and autoconfig ?
Autoconfig works well on simple devices like picostation or nanostation, but on
more complex setup like the black tplink is not the good approach, so i was
thinking about completely moving to a build + profile system without or with
minimal autoconfig script on the device
what do you think about that ?
We actually use a complete auto-config system for
the different router
models we use.
The chef is used to customize the final firmware if you need to, but if
you just use a basic AlterMesh firmware without customizaton it will
"just work".
I believe auto-configuration is one of the important aspects of all this
project. Maybe we can look a bit more into the auto-config approaches in
the three existing firmwares and get ideas from all.
AlterMesh auto configuration is this package:
https://colectivo.altermundi.net/projects/altermesh-packages/repository/sho…
And the auto-gw-mode:
https://colectivo.altermundi.net/projects/altermesh-packages/repository/sho…
(guido did you push your last changes to the repo?)
I believe that in our roadmap we should first check that the
configuration for both network models (batman+bmx everywhere & bmx on
border nodes) are known and tested, and then adapt our auto-config
systems to create those configurations automatically.
Is the work done by gui and gio on the manual config (done in Berlin)
available somewhere?
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
8:30 p.m.
On Monday 27 May 2013 22:20:38 Pau wrote:
I agree, the system should be 100% auto-configurable.
So the user can
download a generic image, install it and enjoy it. This is the same
approach we are following in qMp.
So the 3 previous firmware from us ( also eigennet was completely autconf )
followed the same approach, but how to solve problem bounded to specific models
like black tplink ? ( on those devices it is a little trinky to make work vlan
on the switch because the eth0 and eth1 are not existent but are created
trought utagged vlan moreover the hardware switch has some limitation with
tagged vlan )
8:39 p.m.
On Monday 27 May 2013 22:30:49 Gioacchino Mazzurco wrote:
So the 3 previous firmware from us ( also eigennet was
completely autconf )
followed the same approach, but how to solve problem bounded to specific
models like black tplink ? ( on those devices it is a little trinky to make
work vlan on the switch because the eth0 and eth1 are not existent but are
created trought utagged vlan moreover the hardware switch has some
limitation with tagged vlan )
Maybe erasing totally the virtal eth0 ad eth1 and treating the switch as a
single interface ( at hw level it is just an interface ) would solve those
corner case as normal case too
8:43 p.m.
I think, if the heuristics to make the decisions are enough good, they
should work for all (or most) of the hardware devices.
For this cases, where the specific hardware have some strange stuff
(like tplink wdr4X00) maybe the best choice is to have a module named
(for example) addons.lua which have some specific functions to configure
some specific hardware. The HW model can be taken from /proc/cpuinfo.
By the way, if I'm not wrong there is a way to use the tplink switch
with Kernel VLANs, the trick is use the tag 0 (in the switch conf) for
the ports you want to use it. I should ask the gay who is dealing with
it in qMp.
On 27/05/13 22:30, Gioacchino Mazzurco wrote:
On Monday 27 May 2013 22:20:38 Pau wrote:
--
./p4u
I agree, the system should be 100%
auto-configurable. So the user can
download a generic image, install it and enjoy it. This is the same
approach we are following in qMp.
So the 3 previous firmware from us ( also
eigennet was completely autconf )
followed the same approach, but how to solve problem bounded to specific models
like black tplink ? ( on those devices it is a little trinky to make work vlan
on the switch because the eth0 and eth1 are not existent but are created
trought utagged vlan moreover the hardware switch has some limitation with
tagged vlan )
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
4168
days inactive
4168
days old
5 comments
3 participants
participants (3)
-
Gioacchino Mazzurco -
NicoEchániz -
Pau