Re: [LEDE-DEV] ath10k firmware crashes in mesh mode on QCA9880

[Benjamin Morgan]

Applied the patch and tried with 10.2.4.70.54 firmware and it still crashes:

[  142.438377] ath10k_pci :01:00.0: firmware crashed! (uuid 
a5499582-e220-46d2-9359-0b44219f69ea)
[  142.447512] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub :
[  142.456879] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1 
tracing 0 dfs 1 testmode 1
[  142.469916] ath10k_pci :01:00.0: firmware ver 10.2.4.70.54 api 5 
features no-p2p,raw-mode,mfp crc32 9d340dd9
[  142.480295] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[  142.487717] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1

[  142.499361] ath10k_pci :01:00.0: firmware register dump:
[  142.505124] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 
0x009A4577 0x00955B31
[  142.513157] ath10k_pci :01:00.0: [04]: 0x009A4577 0x00060130 
0x0002 0x00439E98
[  142.521203] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[  142.529246] ath10k_pci :01:00.0: [12]: 0x0009 0x 
0x009A3518 0x009A3526
[  142.537285] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A3EA6 
0x 0x
[  142.545324] ath10k_pci :01:00.0: [20]: 0x409A4577 0x0040AAC4 
0x0040AC60 0x0040AC09
[  142.553356] ath10k_pci :01:00.0: [24]: 0x809A44BA 0x0040AB24 
0x0040 0xC09A4577
[  142.561400] ath10k_pci :01:00.0: [28]: 0x809A39DE 0x0040AB84 
0x0044110C 0x00442074
[  142.569444] ath10k_pci :01:00.0: [32]: 0x809A5FE2 0x0040ABB4 
0x0044110C 0x00407120
[  142.577483] ath10k_pci :01:00.0: [36]: 0x809A2E6C 0x0040ABF4 
0x0040AC14 0x1580
[  142.585522] ath10k_pci :01:00.0: [40]: 0x80990F6F 0x0040AD04 
0x009C643C 0x004436CC
[  142.593554] ath10k_pci :01:00.0: [44]: 0x80998510 0x0040AD64 
0x004208FC 0x00439E4C
[  142.601600] ath10k_pci :01:00.0: [48]: 0x8099AE95 0x0040AD84 
0x004208FC 0x0042638C
[  142.609642] ath10k_pci :01:00.0: [52]: 0x809BFC55 0x0040AEE4 
0x00424FE8 0x0002
[  142.617681] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14 
0x0004 0x004039D0

[  142.727220] ieee80211 phy0: Hardware restart was requested
[  142.732850] ath10k_pci :01:00.0: failed to synchronize monitor 
vdev 1 stop: -143

[  142.740739] ath10k_pci :01:00.0: failed to stop monitor vdev: -143


~Benjamin

On 12/03/2016 04:46 AM, Mohammed Shafi Shajakhan wrote:

https://patchwork.kernel.org/patch/9437519/
(sorry missed this in the previous thread)

On Sat, Dec 03, 2016 at 06:13:58PM +0530, Mohammed Shafi Shajakhan wrote:

Hi Benjamin,

On Fri, Dec 02, 2016 at 05:28:02PM -0800, Benjamin Morgan wrote:

Just tried 10.2.4.70.58 firmware that you linked to and it still crashes:

[  131.568989] ath10k_pci :01:00.0: firmware crashed! (uuid
1838347e-9380-4a26-ac9d-2963ee95968b)
[  131.578124] ath10k_pci :01:00.0: qca988x hw2.0 target
0x4100016c chip_id 0x043202ff sub :
[  131.587491] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
tracing 0 dfs 1 testmode 1
[  131.600521] ath10k_pci :01:00.0: firmware ver 10.2.4.70.58
api 5 features no-p2p,raw-mode,mfp crc32 e1af076f
[  131.610899] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[  131.618325] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op
2 cal file max-sta 128 raw 0 hwcrypto 1
[  131.629965] ath10k_pci :01:00.0: firmware register dump:
[  131.635728] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3
0x009A45AF 0x00955B31
[  131.643761] ath10k_pci :01:00.0: [04]: 0x009A45AF 0x00060130
0x0002 0x00439E98
[  131.651806] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074
0x00407120 0x004436CC
[  131.659852] ath10k_pci :01:00.0: [12]: 0x0009 0x
0x009A3550 0x009A355E
[  131.667892] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A31D6
0x 0x
[  131.675936] ath10k_pci :01:00.0: [20]: 0x409A45AF 0x0040AAC4
0x0040AC60 0x0040AC09
[  131.683968] ath10k_pci :01:00.0: [24]: 0x809A44F2 0x0040AB24
0x0040 0xC09A45AF
[  131.692013] ath10k_pci :01:00.0: [28]: 0x809A3A16 0x0040AB84
0x0044110C 0x00442074
[  131.700056] ath10k_pci :01:00.0: [32]: 0x809A601A 0x0040ABB4
0x0044110C 0x00407120
[  131.708100] ath10k_pci :01:00.0: [36]: 0x809A2EA4 0x0040ABF4
0x0040AC14 0x1580
[  131.716143] ath10k_pci :01:00.0: [40]: 0x80990F63 0x0040AD04
0x009C6458 0x004436CC
[  131.724175] ath10k_pci :01:00.0: [44]: 0x80998520 0x0040AD64
0x004208FC 0x00439E4C
[  131.732220] ath10k_pci :01:00.0: [48]: 0x8099AEA5 0x0040AD84
0x004208FC 0x00425874
[  131.740263] ath10k_pci :01:00.0: [52]: 0x809BFC39 0x0040AEE4
0x00424FE8 0x0002
[  131.748306] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14
0x0004 0x004039D0
[  131.857076] ieee80211 phy0: Hardware restart was requested
[  131.862705] ath10k_pci :01:00.0: failed to synchronize
monitor vdev 1 stop: -143
[  131.870594] ath10k_pci :01:00.0: failed to stop monitor vdev: -143

[shafi] request 

Re: [LEDE-DEV] [OpenWrt] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things

[Bill Moffitt]

On 12/5/2016 4:54 AM, Hauke Mehrtens wrote:

On 2016-12-05 11:57, Daniel Golle wrote:

Hi Felix,

On Thu, Dec 01, 2016 at 04:51:30PM +0100, Felix Fietkau wrote:

On 2016-12-01 16:38, Daniel Golle wrote:
> Hi Felix,
>
> On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:
>> On 2016-12-01 16:05, Daniel Golle wrote:
>> > I was following your posts and do believe there is quite some 
overlap.
>> > It would thus be feasible to generalize the common parts (ubus 
call
>> > proxy, ubus service proxy, ubus remote monitor) by agreeing on 
a shared
>> > interface the actual implementations shall use. In that way, 
people

>> > can choose whether they want WebSockets, TR-069 or a suitable P2P
>> > framework depending on their specific needs.
>> > Has anything of your current approach at IOPSYS been made 
available

>> > publicly (eg. on github?)
>> >
>> > From what I can tell there is also some overlap with Felix' 
proposed
>> > System Configuration Abstraction Layer, just that my envisioned 
use
>> > exceeds system configuration as it includes sensors, events and 
actors

>> > rather than just access to a configuration model.
>> If it makes sense, I'd be open to extending my abstraction layer 
to make

>> it suitable for your use case as well.
>> Feel free to propose changes to it if you like.
>
> Having a first deeper look at scal I believe that access to sensors
> and actors could be implemented inside scal similar to the existing
> shell and system backends. That would be nice, as then scal would
> make things available on ubus and provide the ACL mechanics.
Nice. Maybe we can reinterpret the acronym as "System Communication
Abstraction Layer". I'd be fine with renaming it to something else as
well, I just didn't find a better name for it yet.

I think a good approach would be to add a dlopen plugin API to the json
plugin itself, so you can use json files to parameterize access to
sensors and other devices.


To me the question remains whether access to devices should happen
directly inside those scal-json-plugins or if it'd be better to
expose a service on ubus ("urthings") handling them (which was my
original plan) and then have scal access them via ubus. The latter
would come with the advantage that other local services (think:
collectd) could also access them via that urthings service instead of
having to go through scal.


I would like to have an API which can be used locally easily not just 
from remote, I haven't found the time to look into scal .
Like a Luci web UI to switch on and off your lamps and also some API 
so that others can easily integrate own application running on the 
device which are managing and controlling the things. Probably people 
will also run applications to connect the devices to existing clouds 
with existing interfaces.



I'd be glad to here more opinions, because this obviously has to be
decided early in the design of the IoT integration approach. Find
me on IRC (dangole@freenode) in the next couple of hours, maybe we
can collect some ideas about the edges to be cut before the meeting
at 3pm CET.



Event handling could also be scripted through .json files using 
json_script.


I thought of it like that, similar to how procd's hotplug json_scripts
look like. In addition I thought about adding ubus input and output
support to collectd (so events can be triggered depending on conditions
defined over polled sensors), but maybe something much simpler and more
thightly designed for that specific job -- polling sensors, (maybe)
caching & monitoring/triggering events -- could also be sufficient.
However, I reckon this can be decided at a later stage, and as I'm
already quite familiar with collectd, I'd just go ahead and create
a ubus plugin there and who ever is unhappy with that may suggest
what ever else could be better.


I think we should focus on Phase 1 first to get these stuff properly 
into a generic API in LEDE and then use some generic interfaces to 
expose it to remote hosts.
I want to agree with this approach. There are some interesting issues in 
polling sensors that I'm not sure collectd would cover well (my 
experience here is in weather: you can sample temperature any time, but 
you have to "watch" a rain bucket continuously and make note of every 
time it tips), and it would be good to include the possibility of 
control outputs, as well (gpio or pwm). But it's good to start 
somewhere, IMHO.





Cheers


Daniel





> I'll have a deeper look and play with it to see whether that can
> work.
>
> Ideally, data collection (think: interface counters and such things
> which need to be polled) and triggering events (think: link status
> updates) should also be made accessible.
>
> A local database which exceeds UCI state as suggested by Luka could
> also be very useful, eg. for renewable energy or other applications
> where loss of connectivity should never imply loss of collected data.
Makes sense.

- Felix


___

Re: [LEDE-DEV] ath10k firmware crashes in mesh mode on QCA9880

[Nagarajan, Ashok Raj]

>> Applied the patch and tried with 10.2.4.70.54 firmware and it still crashes:

>> [  142.438377] ath10k_pci :01:00.0: firmware crashed! (uuid 
>> a5499582-e220-46d2-9359-0b44219f69ea)
>> [  142.447512] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c 
>> chip_id 0x043202ff sub :
>> [  142.456879] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1 
>> tracing 0 dfs 1 testmode 1
>> [  142.469916] ath10k_pci :01:00.0: firmware ver 10.2.4.70.54 api 5 
features no-p2p,raw-mode,mfp crc32 9d340dd9
>> [  142.480295] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A 
>> crc32 bebc7c08
>> [  142.487717] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
>> cal file max-sta 128 raw 0 hwcrypto 1
>> [  142.499361] ath10k_pci :01:00.0: firmware register dump:
>> [  142.505124] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 
0x009A4577 0x00955B31

Benjamin, Thanks for the logs.
Quick questions to further debug the issue here,

1. Is this issue seen every time you start sending data traffic?
2. Issue seen with older firmwares? (FYR, 
http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
3. Could you please share the dmesg from your device after enabling MAC and WMI 
logs in ath10k driver
To enable debug logs please see 
http://linuxwireless.org/en/users/Drivers/ath10k/debug/ 
4. Do you know what is the Number of Spatial Streams seen in mesh beacons and 
in mesh data packet?

Thanks,
Ashok
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH uclient v2] Fix unused results warnings

[Felix Fietkau]

On 2016-12-05 00:15, Florian Fainelli wrote:
> Fixes:
> 
> uclient-http.c:385:8: error: ignoring return value of 'fread', declared with 
> attribute warn_unused_result [-Werror=unused-result]
>fread(, sizeof(val), 1, f);
> ^
> 
> uclient-fetch.c: In function 'main':
> uclient-fetch.c:664:12: error: ignoring return value of 'asprintf', declared 
> with attribute warn_unused_result [-Werror=unused-result]
> asprintf(_str, "%s:%s", username, password);
> ^
> uclient-fetch.c: In function 'read_data_cb':
> uclient-fetch.c:269:9: error: ignoring return value of 'write', declared with 
> attribute warn_unused_result [-Werror=unused-result]
> write(output_fd, buf, len);
> 
> Signed-off-by: Florian Fainelli 
> ---
>  uclient-fetch.c | 16 +++-
>  uclient-http.c  |  5 -
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/uclient-fetch.c b/uclient-fetch.c
> index 4c603fbc1945..16fd3ca0c345 100644
> --- a/uclient-fetch.c
> +++ b/uclient-fetch.c
> @@ -254,6 +254,7 @@ static void header_done_cb(struct uclient *cl)
>  static void read_data_cb(struct uclient *cl)
>  {
>   char buf[256];
> + size_t n;
>   int len;
>  
>   if (!no_output && output_fd < 0)
> @@ -265,8 +266,11 @@ static void read_data_cb(struct uclient *cl)
>   return;
>  
>   out_bytes += len;
> - if (!no_output)
> - write(output_fd, buf, len);
> + if (!no_output) {
> + n = write(output_fd, buf, len);
> + if (n < 0)
With size_t, n < 0 is never true (leading to another warning with some
compilers). Please use ssize_t.

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things

[Daniel Golle]

Hi Felix,

On Thu, Dec 01, 2016 at 04:51:30PM +0100, Felix Fietkau wrote:
> On 2016-12-01 16:38, Daniel Golle wrote:
> > Hi Felix,
> > 
> > On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:
> >> On 2016-12-01 16:05, Daniel Golle wrote:
> >> > I was following your posts and do believe there is quite some overlap.
> >> > It would thus be feasible to generalize the common parts (ubus call
> >> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a shared
> >> > interface the actual implementations shall use. In that way, people
> >> > can choose whether they want WebSockets, TR-069 or a suitable P2P
> >> > framework depending on their specific needs.
> >> > Has anything of your current approach at IOPSYS been made available
> >> > publicly (eg. on github?)
> >> > 
> >> > From what I can tell there is also some overlap with Felix' proposed
> >> > System Configuration Abstraction Layer, just that my envisioned use
> >> > exceeds system configuration as it includes sensors, events and actors
> >> > rather than just access to a configuration model.
> >> If it makes sense, I'd be open to extending my abstraction layer to make
> >> it suitable for your use case as well.
> >> Feel free to propose changes to it if you like.
> > 
> > Having a first deeper look at scal I believe that access to sensors
> > and actors could be implemented inside scal similar to the existing
> > shell and system backends. That would be nice, as then scal would
> > make things available on ubus and provide the ACL mechanics.
> Nice. Maybe we can reinterpret the acronym as "System Communication
> Abstraction Layer". I'd be fine with renaming it to something else as
> well, I just didn't find a better name for it yet.
> 
> I think a good approach would be to add a dlopen plugin API to the json
> plugin itself, so you can use json files to parameterize access to
> sensors and other devices.

To me the question remains whether access to devices should happen
directly inside those scal-json-plugins or if it'd be better to
expose a service on ubus ("urthings") handling them (which was my
original plan) and then have scal access them via ubus. The latter
would come with the advantage that other local services (think:
collectd) could also access them via that urthings service instead of
having to go through scal.

I'd be glad to here more opinions, because this obviously has to be
decided early in the design of the IoT integration approach. Find
me on IRC (dangole@freenode) in the next couple of hours, maybe we
can collect some ideas about the edges to be cut before the meeting
at 3pm CET.

> 
> Event handling could also be scripted through .json files using json_script.

I thought of it like that, similar to how procd's hotplug json_scripts
look like. In addition I thought about adding ubus input and output
support to collectd (so events can be triggered depending on conditions
defined over polled sensors), but maybe something much simpler and more
thightly designed for that specific job -- polling sensors, (maybe)
caching & monitoring/triggering events -- could also be sufficient.
However, I reckon this can be decided at a later stage, and as I'm
already quite familiar with collectd, I'd just go ahead and create
a ubus plugin there and who ever is unhappy with that may suggest
what ever else could be better.


Cheers


Daniel



> 
> > I'll have a deeper look and play with it to see whether that can
> > work.
> > 
> > Ideally, data collection (think: interface counters and such things
> > which need to be polled) and triggering events (think: link status
> > updates) should also be made accessible.
> > 
> > A local database which exceeds UCI state as suggested by Luka could
> > also be very useful, eg. for renewable energy or other applications
> > where loss of connectivity should never imply loss of collected data.
> Makes sense.
> 
> - Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things

[Daniel Golle]

Hi Hauke,

On Mon, Dec 05, 2016 at 01:54:20PM +0100, Hauke Mehrtens wrote:
> On 2016-12-05 11:57, Daniel Golle wrote:
> > Hi Felix,
> > 
> > On Thu, Dec 01, 2016 at 04:51:30PM +0100, Felix Fietkau wrote:
> > > On 2016-12-01 16:38, Daniel Golle wrote:
> > > > Hi Felix,
> > > >
> > > > On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:
> > > >> On 2016-12-01 16:05, Daniel Golle wrote:
> > > >> > I was following your posts and do believe there is quite some 
> > > >> > overlap.
> > > >> > It would thus be feasible to generalize the common parts (ubus call
> > > >> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a 
> > > >> > shared
> > > >> > interface the actual implementations shall use. In that way, people
> > > >> > can choose whether they want WebSockets, TR-069 or a suitable P2P
> > > >> > framework depending on their specific needs.
> > > >> > Has anything of your current approach at IOPSYS been made available
> > > >> > publicly (eg. on github?)
> > > >> >
> > > >> > From what I can tell there is also some overlap with Felix' proposed
> > > >> > System Configuration Abstraction Layer, just that my envisioned use
> > > >> > exceeds system configuration as it includes sensors, events and 
> > > >> > actors
> > > >> > rather than just access to a configuration model.
> > > >> If it makes sense, I'd be open to extending my abstraction layer to 
> > > >> make
> > > >> it suitable for your use case as well.
> > > >> Feel free to propose changes to it if you like.
> > > >
> > > > Having a first deeper look at scal I believe that access to sensors
> > > > and actors could be implemented inside scal similar to the existing
> > > > shell and system backends. That would be nice, as then scal would
> > > > make things available on ubus and provide the ACL mechanics.
> > > Nice. Maybe we can reinterpret the acronym as "System Communication
> > > Abstraction Layer". I'd be fine with renaming it to something else as
> > > well, I just didn't find a better name for it yet.
> > > 
> > > I think a good approach would be to add a dlopen plugin API to the
> > > json
> > > plugin itself, so you can use json files to parameterize access to
> > > sensors and other devices.
> > 
> > To me the question remains whether access to devices should happen
> > directly inside those scal-json-plugins or if it'd be better to
> > expose a service on ubus ("urthings") handling them (which was my
> > original plan) and then have scal access them via ubus. The latter
> > would come with the advantage that other local services (think:
> > collectd) could also access them via that urthings service instead of
> > having to go through scal.
> 
> I would like to have an API which can be used locally easily not just from
> remote, I haven't found the time to look into scal .
> Like a Luci web UI to switch on and off your lamps and also some API so that
> others can easily integrate own application running on the device which are
> managing and controlling the things. Probably people will also run
> applications to connect the devices to existing clouds with existing
> interfaces.

I agree. Having a simple service on ubus allowing to expose sensors and
actors is still the best first-step which everything else can later on
build-upon. Using and, if necessary, extending SCAL to allow remote
access to specific objects exposed by that service shouldn't be too hard
either.

> 
> > I'd be glad to here more opinions, because this obviously has to be
> > decided early in the design of the IoT integration approach. Find
> > me on IRC (dangole@freenode) in the next couple of hours, maybe we
> > can collect some ideas about the edges to be cut before the meeting
> > at 3pm CET.
> > 
> > > 
> > > Event handling could also be scripted through .json files using
> > > json_script.
> > 
> > I thought of it like that, similar to how procd's hotplug json_scripts
> > look like. In addition I thought about adding ubus input and output
> > support to collectd (so events can be triggered depending on conditions
> > defined over polled sensors), but maybe something much simpler and more
> > thightly designed for that specific job -- polling sensors, (maybe)
> > caching & monitoring/triggering events -- could also be sufficient.
> > However, I reckon this can be decided at a later stage, and as I'm
> > already quite familiar with collectd, I'd just go ahead and create
> > a ubus plugin there and who ever is unhappy with that may suggest
> > what ever else could be better.
> 
> I think we should focus on Phase 1 first to get these stuff properly into a
> generic API in LEDE and then use some generic interfaces to expose it to
> remote hosts.

The above is more about whether polling/monitoring/caching/aggregating
should be taken care of by a to-be-created service or if implementing a
collectd input and output plugin for ubus would be agreable for
everyone...?


Cheers


Daniel

> 
> > 
> > 
> > Cheers
> > 
> > 
> > Daniel
> > 
> > 
> > 
> > 

Re: [LEDE-DEV] [OpenWrt] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things

[Hauke Mehrtens]

On 2016-12-05 11:57, Daniel Golle wrote:

Hi Felix,

On Thu, Dec 01, 2016 at 04:51:30PM +0100, Felix Fietkau wrote:

On 2016-12-01 16:38, Daniel Golle wrote:
> Hi Felix,
>
> On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:
>> On 2016-12-01 16:05, Daniel Golle wrote:
>> > I was following your posts and do believe there is quite some overlap.
>> > It would thus be feasible to generalize the common parts (ubus call
>> > proxy, ubus service proxy, ubus remote monitor) by agreeing on a shared
>> > interface the actual implementations shall use. In that way, people
>> > can choose whether they want WebSockets, TR-069 or a suitable P2P
>> > framework depending on their specific needs.
>> > Has anything of your current approach at IOPSYS been made available
>> > publicly (eg. on github?)
>> >
>> > From what I can tell there is also some overlap with Felix' proposed
>> > System Configuration Abstraction Layer, just that my envisioned use
>> > exceeds system configuration as it includes sensors, events and actors
>> > rather than just access to a configuration model.
>> If it makes sense, I'd be open to extending my abstraction layer to make
>> it suitable for your use case as well.
>> Feel free to propose changes to it if you like.
>
> Having a first deeper look at scal I believe that access to sensors
> and actors could be implemented inside scal similar to the existing
> shell and system backends. That would be nice, as then scal would
> make things available on ubus and provide the ACL mechanics.
Nice. Maybe we can reinterpret the acronym as "System Communication
Abstraction Layer". I'd be fine with renaming it to something else as
well, I just didn't find a better name for it yet.

I think a good approach would be to add a dlopen plugin API to the 
json

plugin itself, so you can use json files to parameterize access to
sensors and other devices.


To me the question remains whether access to devices should happen
directly inside those scal-json-plugins or if it'd be better to
expose a service on ubus ("urthings") handling them (which was my
original plan) and then have scal access them via ubus. The latter
would come with the advantage that other local services (think:
collectd) could also access them via that urthings service instead of
having to go through scal.


I would like to have an API which can be used locally easily not just 
from remote, I haven't found the time to look into scal .
Like a Luci web UI to switch on and off your lamps and also some API so 
that others can easily integrate own application running on the device 
which are managing and controlling the things. Probably people will also 
run applications to connect the devices to existing clouds with existing 
interfaces.



I'd be glad to here more opinions, because this obviously has to be
decided early in the design of the IoT integration approach. Find
me on IRC (dangole@freenode) in the next couple of hours, maybe we
can collect some ideas about the edges to be cut before the meeting
at 3pm CET.



Event handling could also be scripted through .json files using 
json_script.


I thought of it like that, similar to how procd's hotplug json_scripts
look like. In addition I thought about adding ubus input and output
support to collectd (so events can be triggered depending on conditions
defined over polled sensors), but maybe something much simpler and more
thightly designed for that specific job -- polling sensors, (maybe)
caching & monitoring/triggering events -- could also be sufficient.
However, I reckon this can be decided at a later stage, and as I'm
already quite familiar with collectd, I'd just go ahead and create
a ubus plugin there and who ever is unhappy with that may suggest
what ever else could be better.


I think we should focus on Phase 1 first to get these stuff properly 
into a generic API in LEDE and then use some generic interfaces to 
expose it to remote hosts.





Cheers


Daniel





> I'll have a deeper look and play with it to see whether that can
> work.
>
> Ideally, data collection (think: interface counters and such things
> which need to be polled) and triggering events (think: link status
> updates) should also be made accessible.
>
> A local database which exceeds UCI state as suggested by Luka could
> also be very useful, eg. for renewable energy or other applications
> where loss of connectivity should never imply loss of collected data.
Makes sense.

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] ramips: image validator and board variants

[Mathias Kresin]

Hey John, Hey Felix

I'm near to finished with porting the remaining ramips devices to the 
new image build code. While doing this, I might have spotted a ramips 
specific issue with the new image validation feature in regard of build 
variants of boards.


At the moment the build code of for example 4 MByte and 8 MByte flash 
variants of a single board uses the same SUPPORTED_DEVICES string, to 
match the name exported in /lib/ramips.sh. Albeit the situation is 
already way better than without any validation, it would allow to flash 
a 8 MByte image on a the board version with only 4 MByte flash.


I can only guess this solution/workaround/hack was chosen to avoid 
touching files which setup led related stuff. No idea why this 
limitation wasn't mentioned in the commit message.


To de-duplicate stuff on ramips, the LEDs are referenced as 
$board:color:name, where $board is the name exported by /lib/ramips.sh. 
In all cases, build variants of a board are sharing the device tree led 
node, which has the leds named like "asl26555:red:power" for the 
asl26555-8M and asl26555-16M.


My question is now, how to handle such cases?

a) use a shared SUPPORTED_DEVICES string and life with the 80% solution

b) add an exception for these boards and use the asl26555:color:name 
pattern instead of $board:color:name at the relevant places


c) there is another solution that I've missed

Mathias

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] odhcpd: Update to 2016-12-01 snapshot

[Karl Palsson]

John Crispin  wrote:
> Hi Karl,
> 
> this comment is completely devoid any usefulness. let me help
> by rephrasing it to make it useful.
> 
> "Hi community,
> 
> i have noticed that it is common practice to not annotate the
> upstream changes properly in commit bumping the git hash of
> packages. i feel that it would be much better if we used some
> common pattern, such as the "git log --online" output to make
> the changes more explicit. this would make the changelog of
> trunk more readable.
> 
> b/R"
> 
> let me know if this is what you actually wanted to say. because
> it think it would be a good idea and i would support such a new
> way of bumping packages.

Sounds lovely, I appreciate your rewording, it's much clearer and
to the point than my earlier complaints. Let's hope the community
agrees!

Cheers,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] libubox: allow reading out the remaining time of a uloop timer in Lua

[Stijn Cleynhens]

Add Lua method to the uloop wrapper to allow reading out the remaining time of 
a uloop timer

Signed-off-by: Stijn Cleynhens 
---
 lua/uloop.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lua/uloop.c b/lua/uloop.c
index c5dd12f..a78c2dc 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -94,6 +94,15 @@ static int ul_timer_set(lua_State *L)
return 1;
 }
 
+static int ul_timer_remaining(lua_State *L)
+{
+   struct lua_uloop_timeout *tout;
+
+   tout = lua_touserdata(L, 1);
+   lua_pushnumber(L, uloop_timeout_remaining(>t));
+   return 1;
+}
+
 static int ul_timer_free(lua_State *L)
 {
struct lua_uloop_timeout *tout = lua_touserdata(L, 1);
@@ -114,6 +123,7 @@ static int ul_timer_free(lua_State *L)
 
 static const luaL_Reg timer_m[] = {
{ "set", ul_timer_set },
+   { "remaining", ul_timer_remaining },
{ "cancel", ul_timer_free },
{ NULL, NULL }
 };
-- 
1.9.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev