Files included by chef not part of lime-build process about lime-packages HOT 17 CLOSED

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)

from lime-packages.

@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.

from lime-packages.

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

from lime-packages.

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

from lime-packages.

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.

from lime-packages.

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...

from lime-packages.

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.

from lime-packages.

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.

from lime-packages.

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.

from lime-packages.

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
#50 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACr1I5ygTiV4p6gPuh1rDdmJPPCrU8Xyks5qZUoWgaJpZM4JI5So.

from lime-packages.

On July 25, 2016 9:08:22 PM GMT-03:00, Daniel Golle [email protected] 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.

from lime-packages.

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
#50 (comment),
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:
#50 (comment)

from lime-packages.

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!

from lime-packages.

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!

from lime-packages.

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).

from lime-packages.

The named ap interface has been implemented in a17e617.

from lime-packages.

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

from lime-packages.