Files included by chef not part of lime-build process

marvinmarnold commented 8 years ago

As pointed out in the LiMeCat notes, Chef adds to Libre-Mesh a few scripts. Some of these are needed for Chef to customize the build, some others should be included in lime-packages if we want lime-build to produce images as good as the ones from chef.

For example: /etc/uci-defaults/95_add-sshkeys /etc/config/lime-defaults /etc/chef_version are needed for some of the customization features of chef (but the lime-defaults file should be up to date with the one in lime-packages)

These files should be moved into lime-packages.

FreifunkUFO commented 7 years ago

a there it is.... i just was looking for 95_reboot-daily and couldnt found it. the reboot command has to be discussed. i think you need at least "reboot -f", to avoid the problems with "unregister_netdevice: waiting for wlan0-adhoc_262 to become free. Usage count = 1" (problems only on openwrt-cc)

dangowrt commented 7 years ago

@FreifunkUFO @p4u i think most of those work-arounds are obsolete and no longer needed. at least in the environments i've seen and setup for now, we are fine without them.

ilario commented 7 years ago

Looking at the files and using common sense I see the following interesting points:

lime-defaults file has a few differences with the one from lime-packages
93_ugly-fixes file adds an ap interface with the hostname as essid, this is useful for maintenance (you know exactly which node you're connecting to) and should be included in lime-system IMO
95_snmpd file should be included in lime-system
95_reboot-daily should be included in lime-system but I would rather switch to reboot weekly or monthly, daily is too often
reset_deaf_phys.sh checks if an interface is doing traffic and if not does a scan, does it really work? If yes we could include it in lime-system

ilario commented 7 years ago

Reading #61 seems that a daily reboot -f is needed for the coming release, maybe in the next ones monthly will be enough.

p4u commented 7 years ago

Once in a month is not helping if the issue happens once in a day or even more often.

It looks like the problem is related to some atheros chips. So I would prefer to not include a reboot by default in all nodes. It will only hidde this problem and probably some more that we don't know yet.

First of all we should try to reproduce and identify the problem. @FreifunkUFO can you post which kind of WiFi chip are you using in your deployment?

If this problem is fixed on LEDE (kernel 4.4) I think we should try to base the release on it instead of CC.

ilario commented 7 years ago

Once in a month is not helping if the issue happens once in a day or even more often.

Sure, I was assuming that the subsequent release will be based on LEDE and won't have #61.

If this problem is fixed on LEDE (kernel 4.4) I think we should try to base the release on it instead of CC.

LEDE doesn't have a stable release yet...

dangowrt commented 7 years ago

To make things clear: I'm not against having those options, but they really shouldn't all be enabled by default. Example: One might choose to have an additional named AP interface, if your client OS doesn't allow you to specify a BSSID. However, everything Linux-based does that (via wpa_supplicant.conf), so this is only for specific debugging needs of people using the stock-Wifi tools of Mac or Windows, right? I think this should all be dropped or only be available for expert-builds. The only exception is that deaf-interface work-around, it's specific and well-documented and might potentially even provide a hint to tackle down the actual bug.

dangowrt commented 7 years ago

A stable release of LEDE will certainly be there in time. Given that it took more than a year to make a lime-release based on the previous stable CC release it might even be a good idea to start migrating the code earlier (in the develop branch, obviously) to be more aligned to future LEDE/OpenWrt releases.

p4u commented 7 years ago

I created a lime-build branch for compiling current LEDE.

https://github.com/libre-mesh/lime-build/tree/develop-lede

So we can start testing it. If LEDE project is gonna make a release soon (might be in some months) it would make sense for me to base the libre-mesh 2016 release on it.

altergui commented 7 years ago

On 26/07/16 01:43, Daniel Golle wrote:

To make things clear: I'm not against /having/ those options, but they really shouldn't all be enabled by default. Example: One might choose to have an additional named AP interface, if your client OS doesn't allow you to specify a BSSID. However, everything Linux-based does that (via wpa_supplicant.conf), so this is only for specific debugging needs of people using the stock-Wifi tools of Mac or Windows, right?

uhm... and 90% of end-user devices nowadays (i.e. smartphones) :(

the situation was quite different when we started our community networks in 2012 (10% of devices were smartphones) but shifted dramatically up to a 90%+ today

and it's only going to get worse

the "named AP" thing is also useful to get a quick glimpse of what nodes are online around you, and what RSSI you're getting, looking at the wifi list on any android phone.

I think this should all be dropped or only be available for expert-builds. The only exception is that deaf-interface work-around, it's specific and well-documented and might potentially even provide a hint to tackle down the actual bug.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/libre-mesh/lime-packages/issues/50#issuecomment-235120053, or mute the thread https://github.com/notifications/unsubscribe-auth/ACr1I5ygTiV4p6gPuh1rDdmJPPCrU8Xyks5qZUoWgaJpZM4JI5So.

nicoechaniz commented 7 years ago

On July 25, 2016 9:08:22 PM GMT-03:00, Daniel Golle notifications@github.com wrote:

Maybe there should then be a group of lime-tweak-XXX packages for each of those files in lime-packages? They could then be individually selected for each build (both, chef and lime-build). I'm just against unconditional inclusion in lime-system

I agree named AP and periodic reboot should be optional; the deaf interface problem has been present for a long time. If it's fixed now we will only know after some real world deployments. This error can be frequent or not and we don't really know what causes it. Gio proposed this fix should be link to the specific hardware where we observed it. I agree.

dangowrt commented 7 years ago

On Tue, Jul 26, 2016 at 09:02:25AM -0700, Gui wrote:

On 26/07/16 01:43, Daniel Golle wrote:

To make things clear: I'm not against /having/ those options, but they really shouldn't all be enabled by default. Example: One might choose to have an additional named AP interface, if your client OS doesn't allow you to specify a BSSID. However, everything Linux-based does that (via wpa_supplicant.conf), so this is only for specific debugging needs of people using the stock-Wifi tools of Mac or Windows, right?

uhm... and 90% of end-user devices nowadays (i.e. smartphones) :(

Why should they care about which specific AP they are connected to? I reckon that's really only needed for debugging. If not, then isn't that more like a work-around compensating for missing band-steering which could be achieved using IAPP (802.11F) and having hostapd act according to information gathered from other APs via IAPP? Or is it about having APs with different priorities depending on how well-connected they are? I guess I just don't get the use-case...

the situation was quite different when we started our community networks in 2012 (10% of devices were smartphones) but shifted dramatically up to a 90%+ today

and it's only going to get worse

the "named AP" thing is also useful to get a quick glimpse of what nodes are online around you, and what RSSI you're getting, looking at the wifi list on any android phone.

There are also other apps allowing to see e.g. MAC addresses and BSSIDs of the scanned networks on Android. For someone who wants to debug the network (rather than just using it) I believe it's ok to recommend some WiFi radar App to get the whole picture without polluting everybodies network list. I generally observed that the more SSIDs are around, the more confused people get. Imho the current default of having a single (roaming) AP is ideal. Again, this could still be an additional lime-tweak-namedap package which communities or individuals may include in their builds.

I think this should all be dropped or only be available for expert-builds. The only exception is that deaf-interface work-around, it's specific and well-documented and might potentially even provide a hint to tackle down the actual bug.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/libre-mesh/lime-packages/issues/50#issuecomment-235120053, or mute the thread https://github.com/notifications/unsubscribe-auth/ACr1I5ygTiV4p6gPuh1rDdmJPPCrU8Xyks5qZUoWgaJpZM4JI5So.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/libre-mesh/lime-packages/issues/50#issuecomment-235316370

G10h4ck commented 7 years ago

For hardware specific stuff we already have hardware detection module that is mean also to take care of hardware glitches/tweaks, lime-system should reamin as pure as possible so any pull request about this kind of stuff should come packaged as lime-hwd-*

Cheers!

FreifunkUFO commented 7 years ago

different names for the APs instead of having the same name sometimes would be nice (to have connection to a specific node instead of guessing.) so clients could choose their AP and give better feedback to the crowd.

but its a very specific feature. also the different ssid-names for ad-hoc interface should be the same on default.

Daniel thought about "client OS ... allow you to specify a BSSID", but i never saw a client/person which is doing that. Alterguis idea to use it to "get a quick glimpse" is nice, but using a nice smartphone-app should be nicer for this.

unfortunately ticket #61 was closed, but not solved. it seems to be a show-stopper for a new libremesh on that old openwrt-cc!

p4u commented 7 years ago

Why should they care about which specific AP they are connected to? I reckon that's really only needed for debugging. If not, then isn't that more like a work-around compensating for missing band-steering which could be achieved using IAPP (802.11F) and having hostapd act according to information gathered from other APs via IAPP? Or is it about having APs with different priorities depending on how well-connected they are? I guess I just don't get the use-case...

Roaming sometimes works as shit, it might be because of the client WiFi driver/firmware implementation or because of the WiFi network itself. For instance, you might be placed in a spot where the node next to you has a very weak connection to the mesh network, but another node a bit far away has much better connection. So in this case user would like have the option to choose connect to a specific node (to one a bit far away).

ilario commented 7 years ago

The named ap interface has been implemented in a17e617.

ilario commented 7 years ago

We can close this issue: nowadays Chef still adds some files but all their content is commented out.

libremesh / lime-packages

Files included by chef not part of lime-build process #50