25 Jul
2016
25 Jul
'16
11 a.m.
I agree that this is a way better approach: to make new profiles rather
than using targets.
Also a profile with no access point interface would be useful.
I think that the only problem here is to split lime-system (from
lime-system to lime-system + lime-mode-ap + lime-mode-adhoc +
lime-mode-ieee80211s) without triggering new bugs.
What do you think about this risk?
Just moving the /usr/lib/lua/lime/mode/* files to new packages could be
enough?
Is it safe to do?
If it is, should we work for including it in the coming release?
Ciao!
Ilario
2016-07-21 17:53 GMT+02:00 p4u <pau(a)dabax.net>et>:
I would not use lime-build directly for this. Instead
I would create
packages with different set of targets, for instance lime-full-11s or
lime-full-adhoc. Then lime-build can have a Profile which selects the
corresponding package.
On 21/07/16 16:45, Ilario wrote:
2016-07-13 15:39 GMT+02:00 p4u <pau(a)dabax.net>et>:
Good point is that now we have many more targets
(routers) available.
I've even tested different architectures such as x86 (which works fine)
and RAMIPS (which does not work fine in Ad-Hoc but it does in 802.11s
mode).
So, from my understanding there are architectures where trying to set both
ad-hoc and ap modes is not going to work, or it would be better to set
802.11s and ap instead (as Pau told for ramips), right?
In my opinion (ap + ad-hoc | just ap | ap + 802.11s) selection could be
made by lime-build depending of the selected target architecture.
lime-build could do this setting different lime-defaults depending on the
target (not implemented yet).
Otherwise I suspect that we should move some files [1] from lime-system to
new packages lime-mode-adhoc and lime-mode-ieee80211s (and stop using
lime-full), then specifying the wanted packages in the targets files [2].
Byyye,
Ilario
[1] at least these
https://github.com/libre-mesh/lime-packages/tree/develop/packages/lime-syst…
[2] https://github.com/libre-mesh/lime-build/tree/develop/targets