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

[Eric Schultz]

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.senli at 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 at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>



-- 
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschultz at prplfoundation.org
cell: 920-539-0404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20161005/4627c9e9/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel