Re: [OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT

[Sukru Senli]

Hi Lada,

Thank you for your feedback.

The initial goal of this proposal is presenting the idea of adopting a data 
model structure which addresses the issue 1 given in the proposal and then 
defining data models based on this structure which addresses issue 2 given in 
the proposal.

The JSON example given in the proposal was just to demonstrate an example how 
configuration properties and methods of an entity could be hosted in a single 
structure and how that structure could be used to generate UBUS objects.

If the idea is embraced by the community, the next step would be diving into 
the technical details such as should an OpenWrt specific data model structure 
be designed or should it be based on an existing data model language e.g YANG.

Looking forward to your further feedback as the topic moves forwards.

Regards,
Sukru


From: openwrt-devel [openwrt-devel-boun...@lists.openwrt.org] on behalf of 
Ladislav Lhotka [lho...@nic.cz]
Sent: Monday, January 9, 2017 5:14 PM
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] Data_Model_Structure_Proposal_for_OpenWRT

Hi,

I agree with you analysis and, moreover, I believe that network
management community has gone a long way to provide tools for both areas
that you mention:

* RESTCONF protocol:
  https://tools.ietf.org/html/draft-ietf-netconf-restconf
* YANG data modelling language:
  https://tools.ietf.org/html/rfc7950

RESTCONF (that should become an RFC soon) could be the integrating layer
for configuration and state data, but also for RPCs and asynchronous
notifications.

YANG is not exactly JSON but close, and it is IMO quite a poweful
language for this domain.

In the long run, it might also help in implementing standard data models
in OpenWRT. These models are currently being developed not only in IETF
but also in IEEE, BroadBand Forum, and elsewhere.

I will be happy to help with this stuff.

Cheers, Lada

 Forwarded Message 
Subject: [OpenWrt] Data_Model_Structure_Proposal_for_OpenWRT
Date: Mon, 9 Jan 2017 11:22:45 +
From: Sukru Senli <sukru.se...@inteno.se>
To: open...@lists.prplfoundation.org <open...@lists.prplfoundation.org>
CC: openwrt-devel@lists.openwrt.org <openwrt-devel@lists.openwrt.org>

Dear OpenWrt community,

As we know OpenWrt is gaining popularity among industry players,
especially in residential gateway world. Being one of these industry
player who has been developing OpenWrt based software for over five
years now and being a devoted user of the two core components, UBUS and
UCI, as Inteno, we see two obstacles in OpenWRT on its’ way to be the
undisputed choice for the majority of the gateway vendors:

Configuration of an entity and data collection from the same entity
cannot be achieved via single object:
-
For any on-top applications Inteno or third party developers build
(WebGUI, remote applications etc.) we have to interact with both UBUS
and UCI (libuci or uci object on ubus) to be able to control a single
entity. This makes it more difficult for developers as they have to know
not only what ubus objects but also what uci files and sections they
must interact with, and interacting with two components increases the
number of the code they have to write. It also makes it quite
complicated in terms of access control towards an entity of the software.

There are no ubus data models defined for controlling the entities:

If there were data models defined for how to configure/control the
different entities of the software (network, wireless. voice etc.), any
application built on top of this data model would seamlessly work across
different platforms and OpenWRT based systems as long as the
applications controlling these entities were following the data model.
Moreover, a defined data model for ubus based on a data model structure
which addresses the first problem, UCI would no longer be mandatory
which makes OpenWRT much easier to adapt to for many vendors out there.

We believe the solution to these problems would be developing a data
model structure towards OpenWRT's ubus with features such as:
- JSON based, well formatted, easy to use/understand
- supports auto code and document generation
- contains version, properties (configuration), methods, valid data
types/ranges, error codes per object
- allows configuration, data collection and actions within the same
object as opposed to OpenWRT today where ubus methods + UCI (using ubus
uci object or libuci or /sbin/uci directly) are used.

Supporting such a data model structure, the ultimate goal would be to
create an OpenWrt data model to be standardized (ubus objects for
controlling network, wireless, voice etc.) in order to achieve
compatibility across diffe

Re: [OpenWrt-Devel] 回复： [OpenWrt-Users] Is there anybody can find /var/log/dmesg inOpenWRT ?

[Sukru Senli]

Hi,

Would one of the below help you?

cat /proc/kmsg
or 
cat /dev/kmsg

/Sukru

From: openwrt-devel [openwrt-devel-boun...@lists.openwrt.org] on behalf of 
Tymon [banglang.hu...@foxmail.com]
Sent: Thursday, December 29, 2016 9:17 AM
To: openwrt-users
Cc: openwrt-devel
Subject: [OpenWrt-Devel] 回复： [OpenWrt-Users] Is there anybody can find 
/var/log/dmesg inOpenWRT ?

Thank you for your answer, but I only want to display the kernel message.
I expect to use 'tail -f /var/log/dmesg' to read the kernel debug message on my 
device that without
serial console.

--
Regards,

banglang huang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



-- 原始邮件 --
发件人: "camden lindsay";;
发送时间: 2016年12月29日(星期四) 下午2:57
收件人: "OpenWrt User List";
抄送: "openwrt-devel";
主题: Re: [OpenWrt-Users] Is there anybody can find /var/log/dmesg inOpenWRT ?

I believe you have to use logread-

https://wiki.openwrt.org/doc/howto/log.essentials

On Wed, Dec 28, 2016 at 10:53 PM, Tymon  wrote:
> Hi all,
>
>Why can't I find the /var/log/dmesg file under openwrt (the busybox
> built-in tool 'dmesg' is work fine)  ???
>
>Any hint will be appreciated!
>
> --
> Regards,
>
> banglang huang
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
> ___
> openwrt-users mailing list
> openwrt-us...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
>
___
openwrt-users mailing list
openwrt-us...@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

[Sukru Senli]

Hi Daniel,

Regarding (Phase 2 - ubus rpc proxy), I had opened a thread in October: 
https://lists.openwrt.org/pipermail/openwrt-devel/2016-October/042252.html

Currently we are working on a solution where multiple OpenWrt devices share a 
common ubus which allows us to control all devices from a single point.

Our initial development is based on websockets (we have replaced uhttpd with 
our websocket solution). ACL is still handled by rpcd.

Once we are done with the initial development, we are planning to share the 
code with the community so that anyone who is interested can try it out and 
provide feedback and/or contribute.

As the next step we were planning to investigate another approach where 
websockets are not used for proxying but instead a lower level ubus proxying, 
ubus monitor, and ubus ACLs (instead of rpcd) are used.

If you agree that we are trying to achieve the same goal here, maybe we should 
see how we can cooperate.

Regards,
Sukru


From: openwrt-devel [openwrt-devel-boun...@lists.openwrt.org] on behalf of 
Daniel Golle [dan...@makrotopia.org]
Sent: Thursday, November 17, 2016 12:39 PM
To: open...@lists.prplfoundation.org; lede-...@lists.infradead.org; 
openwrt-devel@lists.openwrt.org; gnunet-develop...@gnu.org
Cc: Kathy Giori
Subject: [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things

Hi!

I want to suggest a project to be (partially) funded by prpl's OpenWrt
project grant.

Abstract:
Implement a secure autotonomous IoT hub using OpenWrt/LEDE's ubus
service and the GNUnet P2P framework.

Introduction:
Despite the ongoing hype about the so-called Internet of Things, the
current practise is rather chaotic and severe structural flaws of IoT
devices became a common occurance, including easy-to-remote-exploit
vulnerabilities and brain-dead mistakes such as a hard-coded DNS server
address rendering thousands of IoT connected devices unusable now that
the server is no longer being operated.
Given the continous history of quite predictable security and
privacy-related catastrophies in the still quite infantile IoT-sphere,
taking a step back, a radical shift of praradigms, away from the
patterns of Web/Cloud-based infrastrucure will help providing a much
more secure and reliable user experience and thereby increase trust in
future networked applications.

Recent examples of typical problems related to the missing security
model and centralized control servers:
http://metropolitan.fi/entry/ddos-attack-halts-heating-in-finland-amidst-winter

Or hard-coded server addresses:
http://www.out-law.com/en/articles/2016/october/singapore-telco-visits-customers-homes-to-secure-devices-after-cyberattack/

Or missing security by default:
http://www.bbc.com/news/technology-37750798

From a coders point of view, the lack of a vendor-neutral abstraction
of low-bandwidth peripherals makes it hard to develop general purpose
applications which do not depend on a specific hardware or middleware.

This projects suggest a from bottom-to-top redesign addressing the
diversity of components and local access methods (ranging from
in-kernel-only drivers to almost pure userland implementations),
connectivity (NAT traversal, discovery, ...) as well as security and
privacy-related concerns. As a first measure, a generic integration of
low-bandwidth peripherals such as simple sensors and actors using the
OpenWrt/LEDE core infrastructure will provide a great improvement to
access and manage local IoT features. This may then be used by
various higher level applications, such as data-logging/monitoring,
WebUI or machine-to-machine communication.

As dependence on centralized services providing remote access has
shown to be problematic in terms of security and privacy as well as
reliability, direct connectivity or application-agnostic indirect
routing using well-known P2P techniques can bring about more
interoperatibility and sustainability. GNUnet provides (among with
many other things) a modular toolkit for P2P, ranging from a
NAT-aware multi-transport, cryptographically addressed general purpose
overlay network to pub/sub, filesharing and real-time conversation
services. In a second phase of the project, this core infrastructure
is going to be used to provide secure, reliable and privacy-aware
remote access to IoT features on typical OpenWrt/LEDE target hardware.
Using GNUnet implies inheriting all the advantages of a secure P2P
infrastructure which has seen  12 years of intense research and
several iterations of architectural revolutions within that long time.
Having a remote-access method for ubus which already provides it's
own set tools to work in a wide range of environments (think: behind
NAT, using low-level transports such as UDP, TCP, HTTP and proper
HTTPS over IPv4/v6 as well as raw bluetooth and wifi injection sockets
for local area coverage) and got it's own built-in security mechanisms
as well as management structures (think: a distributed personal PKI)

Re: [OpenWrt-Devel] ubus: extending ubus over network to allow devices in the same network to exchange messages on a single common bus

[Sukru Senli]

Hi Ronaldo,

Thank you for your interest and willingness to contribute.
As usual, the best way to start contributing would be providing feedback 
positive or negative once we provide more details on how we plan to achieve 
this work technically.

After that, as a community, we can discuss how we can collaborate and drive 
this work.

/Sukru

From: Ronaldo Afonso [rona...@ronaldoafonso.com.br]
Sent: Wednesday, October 5, 2016 7:14 PM
To: Sukru Senli
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] ubus: extending ubus over network to allow devices 
in the same network to exchange messages on a single common bus

  Hi Sukru,

  It seems very interesting 

  I have some C programming experience and I would like to contribute/help.

  So, how can I help?


2016-10-05 10:57 GMT-03:00 Sukru Senli 
<sukru.se...@inteno.se<mailto:sukru.se...@inteno.se>>:
Dear OpenWrt developers,

We, developers of IOPSYS (an OpenWrt based platform for residential gateways) 
at Inteno, believe that extending ubus over network so that multiple devices 
which are on the same network and running OpenWrt could communicate, expose 
objects and exchange messages on a common bus would be a very useful and 
worthwhile enhancement.

For example, in a network scenario where multiple REPEATERs are connected to a 
MASTER gateway, REPEATERs could create objects, create events and 
listen/subscribe to events on the ubus which is exposed to network by MASTER, 
and that would facilitate:
- keeping configuration synced between the devices
- exchaning information about clients between the devices
- devices notifying each other about specific actions, and so on

So far we have envisioned the networked ubus system having the following 
components and properties:

1) Advertisement + Discovery: The devices on the same network become aware of 
each other and acknowledge that they support ubus. Here we believe a multicast 
solution is feasible.

2) Authentication + Connection: The devices choose to connect after verifying 
each other:
Trust can be originated from a trusted third party such as a cloud service, or 
there can be a manual secure pairing method. Another option could be using 
TR069 and pushing keys down to devices to be used in verifying each other.

3) Networked ubus communication: ubus clients access remote or local ubus 
objects in a similar fashion:
The intention is to either not change ubus API at all, or to change it as 
little as possible. However we see changing the ubus API as a better approach 
than changing ubusd daemon or message format significantly.
In our initial design idea, a proxy component would take care of the 
communication and connection setup.

4) Centralized ubus on MASTER:
We believe it is appropriate to centralize control, so, for example, REPEATERs 
would expose (a subset of) their own ubus objects on MASTER's ubus.

Developing an access control mechanism that operates on ubus directly in order 
to limit both local and remote access using the same method would be a good 
idea. ACL could be based on different parameters such as user/group, 
application, IP address etc.

We will be moving forward with the design and implementation of a networked 
ubus, and we take this opportunity to invite participation and discussion so 
that a better solution where more OpenWrt developers/users benefit from can be 
developed.

Regards,
Sukru Senli
Inteno Broadband Technology AB
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org<mailto:openwrt-devel@lists.openwrt.org>
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



--
Ronaldo Afonso
11 9 5252 0484
www.ronaldoafonso.com.br<http://www.ronaldoafonso.com.br>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ubus: extending ubus over network to allow devices in the same network to exchange messages on a single common bus

[Sukru Senli]

Hi Toke,

Thank you for your attention and comments.

We actually did quite a bit investigation and research before choosing this 
path.
We did some PoC projects using different technologies.

For us none of them was as good fit as networked ubus was.
As we use ubus heavily and almost all our applications create objects on ubus 
and use ubus to communicate with each other, extending ubus over network was 
the most straightforward way to create a common environment for our devices on 
the same network to communicate.

Once our technical design proposal is ready, it might give you a better 
understanding why we chose this path, and help you see the benefit on enhancing 
ubus rather than using another technology.
We are looking forward to your further feedback and comments after sharing our 
technical design proposal.

/Sukru

From: t...@toke.dk [t...@toke.dk]
Sent: Wednesday, October 5, 2016 10:11 PM
To: Sukru Senli
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: ubus: extending ubus over network to allow devices in the same 
network to exchange messages on a single common bus

Sukru Senli <sukru.se...@inteno.se> writes:

> Dear OpenWrt developers,
>
> We, developers of IOPSYS (an OpenWrt based platform for residential gateways) 
> at
> Inteno, believe that extending ubus over network so that multiple devices 
> which
> are on the same network and running OpenWrt could communicate, expose objects
> and exchange messages on a common bus would be a very useful and worthwhile
> enhancement.
>
> For example, in a network scenario where multiple REPEATERs are
> connected to a MASTER gateway, REPEATERs could create objects, create
> events and listen/subscribe to events on the ubus which is exposed to
> network by MASTER, and that would facilitate:

> - keeping configuration synced between the devices
> - exchaning information about clients between the devices
> - devices notifying each other about specific actions, and so on
>
> So far we have envisioned the networked ubus system having the
> following components and properties:
>
> 1) Advertisement + Discovery: The devices on the same network become
> aware of each other and acknowledge that they support ubus. Here we
> believe a multicast solution is feasible.
>
> 2) Authentication + Connection: The devices choose to connect after
> verifying each other: Trust can be originated from a trusted third
> party such as a cloud service, or there can be a manual secure pairing
> method. Another option could be using TR069 and pushing keys down to
> devices to be used in verifying each other.
>
> 3) Networked ubus communication: ubus clients access remote or local
> ubus objects in a similar fashion: The intention is to either not
> change ubus API at all, or to change it as little as possible. However
> we see changing the ubus API as a better approach than changing ubusd
> daemon or message format significantly. In our initial design idea, a
> proxy component would take care of the communication and connection
> setup.
>
> 4) Centralized ubus on MASTER: We believe it is appropriate to
> centralize control, so, for example, REPEATERs would expose (a subset
> of) their own ubus objects on MASTER's ubus.
>
> Developing an access control mechanism that operates on ubus directly
> in order to limit both local and remote access using the same method
> would be a good idea. ACL could be based on different parameters such
> as user/group, application, IP address etc.
>
> We will be moving forward with the design and implementation of a
>networked ubus, and we take this opportunity to invite participation
>and discussion so that a better solution where more OpenWrt
>developers/users benefit from can be developed.

>From your description it seems there is quite a bit of overlap between
this and the HNCP protocol defined by the IETF Homenet working group.
The reference implementation of this already runs on openwrt, so I'd
suggest you look into this before you go out and reinvent the wheel. :)

Being an IETF protocol it also has the advantage of interoperability
outside of *wrt (in theory, at least...).

See http://homewrt.org/ and RFC7788 (https://tools.ietf.org/html/rfc7788).

I'll add that the Homenet working group is still quite active and a lot
of things are still in active development. So affecting the process is
very possible :)

https://datatracker.ietf.org/wg/homenet/charter/ - also has a link to
the mailing list.

-Toke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ubus: extending ubus over network to allow devices in the same network to exchange messages on a single common bus

[Sukru Senli]

Hi Felix,

Thank you for your interest and nice feedback on centralization.
We are working on preparing a  detailed design proposal which we will share 
once ready.
That should be a good start point to get into more technical discussions.

/Sukru


From: Felix Fietkau [n...@nbd.name]
Sent: Wednesday, October 5, 2016 7:14 PM
To: Sukru Senli; openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] ubus: extending ubus over network to allow devices 
in the same network to exchange messages on a single common bus

Hi,

On 2016-10-05 15:57, Sukru Senli wrote:
> Dear OpenWrt developers,
>
> We, developers of IOPSYS (an OpenWrt based platform for residential
> gateways) at Inteno, believe that extending ubus over network so that
> multiple devices which are on the same network and running OpenWrt
> could communicate, expose objects and exchange messages on a common
> bus would be a very useful and worthwhile enhancement.
>
> For example, in a network scenario where multiple REPEATERs are
> connected to a MASTER gateway, REPEATERs could create objects, create
> events and listen/subscribe to events on the ubus which is exposed to
> network by MASTER, and that would facilitate: - keeping configuration
> synced between the devices - exchaning information about clients
> between the devices - devices notifying each other about specific
> actions, and so on
Interesting idea.

> So far we have envisioned the networked ubus system having the
> following components and properties:
>
> 1) Advertisement + Discovery: The devices on the same network become
> aware of each other and acknowledge that they support ubus. Here we
> believe a multicast solution is feasible.
>
> 2) Authentication + Connection: The devices choose to connect after
> verifying each other: Trust can be originated from a trusted third
> party such as a cloud service, or there can be a manual secure
> pairing method. Another option could be using TR069 and pushing keys
> down to devices to be used in verifying each other.
>
> 3) Networked ubus communication: ubus clients access remote or local
> ubus objects in a similar fashion: The intention is to either not
> change ubus API at all, or to change it as little as possible.
> However we see changing the ubus API as a better approach than
> changing ubusd daemon or message format significantly. In our initial
> design idea, a proxy component would take care of the communication
> and connection setup.
What kind of API changes do you envision?

> 4) Centralized ubus on MASTER: We believe it is appropriate to
> centralize control, so, for example, REPEATERs would expose (a subset
> of) their own ubus objects on MASTER's ubus.
I don't think you need to explicitly enshrine centralization into the
design. If you simply support a way of defining via policy what ubus
objects a device should be allowed to accept from or expose to other
networked devices, the policy and config files can be used to choose
whether it's a master/slave type of setup or something more distributed
with fine grained control over which objects gets exposed to which device.

> Developing an access control mechanism that operates on ubus directly
> in order to limit both local and remote access using the same method
> would be a good idea. ACL could be based on different parameters such
> as user/group, application, IP address etc.
>
> We will be moving forward with the design and implementation of a
> networked ubus, and we take this opportunity to invite participation
> and discussion so that a better solution where more OpenWrt
> developers/users benefit from can be developed.
I'm looking forward to receiving more information about your design
proposal and working with you in the future.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ubus: extending ubus over network to allow devices in the same network to exchange messages on a single common bus

[Sukru Senli]

Hi Eric,

Thank you for your attention.
We are looking forward to your feedback on prpl Members' interest in the 
project.

/Sukru

From: Eric Schultz [eschu...@prplfoundation.org]
Sent: Wednesday, October 5, 2016 6:57 PM
To: Sukru Senli
Cc: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] ubus: extending ubus over network to allow devices 
in the same network to exchange messages on a single common bus

Sukru,

I think this is very interesting work. I suspect there are multiple prpl 
Members who would be interested in working with Inteno and the rest of the 
community on this topic. I'll mention this at the prplwrt meeting this week 
(which anyone is welcome to join) as well as share it with members.

Eric



On Wed, Oct 5, 2016 at 8:57 AM, Sukru Senli 
<sukru.se...@inteno.se<mailto:sukru.se...@inteno.se>> wrote:
Dear OpenWrt developers,

We, developers of IOPSYS (an OpenWrt based platform for residential gateways) 
at Inteno, believe that extending ubus over network so that multiple devices 
which are on the same network and running OpenWrt could communicate, expose 
objects and exchange messages on a common bus would be a very useful and 
worthwhile enhancement.

For example, in a network scenario where multiple REPEATERs are connected to a 
MASTER gateway, REPEATERs could create objects, create events and 
listen/subscribe to events on the ubus which is exposed to network by MASTER, 
and that would facilitate:
- keeping configuration synced between the devices
- exchaning information about clients between the devices
- devices notifying each other about specific actions, and so on

So far we have envisioned the networked ubus system having the following 
components and properties:

1) Advertisement + Discovery: The devices on the same network become aware of 
each other and acknowledge that they support ubus. Here we believe a multicast 
solution is feasible.

2) Authentication + Connection: The devices choose to connect after verifying 
each other:
Trust can be originated from a trusted third party such as a cloud service, or 
there can be a manual secure pairing method. Another option could be using 
TR069 and pushing keys down to devices to be used in verifying each other.

3) Networked ubus communication: ubus clients access remote or local ubus 
objects in a similar fashion:
The intention is to either not change ubus API at all, or to change it as 
little as possible. However we see changing the ubus API as a better approach 
than changing ubusd daemon or message format significantly.
In our initial design idea, a proxy component would take care of the 
communication and connection setup.

4) Centralized ubus on MASTER:
We believe it is appropriate to centralize control, so, for example, REPEATERs 
would expose (a subset of) their own ubus objects on MASTER's ubus.

Developing an access control mechanism that operates on ubus directly in order 
to limit both local and remote access using the same method would be a good 
idea. ACL could be based on different parameters such as user/group, 
application, IP address etc.

We will be moving forward with the design and implementation of a networked 
ubus, and we take this opportunity to invite participation and discussion so 
that a better solution where more OpenWrt developers/users benefit from can be 
developed.

Regards,
Sukru Senli
Inteno Broadband Technology AB
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org<mailto:openwrt-devel@lists.openwrt.org>
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



--
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschu...@prplfoundation.org<mailto:eschu...@prplfoundation.org>
cell: 920-539-0404
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ubus: extending ubus over network to allow devices in the same network to exchange messages on a single common bus

[Sukru Senli]

Dear OpenWrt developers,

We, developers of IOPSYS (an OpenWrt based platform for residential gateways) 
at Inteno, believe that extending ubus over network so that multiple devices 
which are on the same network and running OpenWrt could communicate, expose 
objects and exchange messages on a common bus would be a very useful and 
worthwhile enhancement.

For example, in a network scenario where multiple REPEATERs are connected to a 
MASTER gateway, REPEATERs could create objects, create events and 
listen/subscribe to events on the ubus which is exposed to network by MASTER, 
and that would facilitate:
- keeping configuration synced between the devices
- exchaning information about clients between the devices
- devices notifying each other about specific actions, and so on

So far we have envisioned the networked ubus system having the following 
components and properties:

1) Advertisement + Discovery: The devices on the same network become aware of 
each other and acknowledge that they support ubus. Here we believe a multicast 
solution is feasible.

2) Authentication + Connection: The devices choose to connect after verifying 
each other:
Trust can be originated from a trusted third party such as a cloud service, or 
there can be a manual secure pairing method. Another option could be using 
TR069 and pushing keys down to devices to be used in verifying each other. 

3) Networked ubus communication: ubus clients access remote or local ubus 
objects in a similar fashion: 
The intention is to either not change ubus API at all, or to change it as 
little as possible. However we see changing the ubus API as a better approach 
than changing ubusd daemon or message format significantly. 
In our initial design idea, a proxy component would take care of the 
communication and connection setup.

4) Centralized ubus on MASTER:
We believe it is appropriate to centralize control, so, for example, REPEATERs 
would expose (a subset of) their own ubus objects on MASTER's ubus.

Developing an access control mechanism that operates on ubus directly in order 
to limit both local and remote access using the same method would be a good 
idea. ACL could be based on different parameters such as user/group, 
application, IP address etc.

We will be moving forward with the design and implementation of a networked 
ubus, and we take this opportunity to invite participation and discussion so 
that a better solution where more OpenWrt developers/users benefit from can be 
developed.

Regards,
Sukru Senli
Inteno Broadband Technology AB
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel