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

Ronaldo Afonso ronaldo at ronaldoafonso.com.br
Wed Oct 5 13:14:38 EDT 2016

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

Ronaldo Afonso
11 9 5252 0484
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20161005/2d3489ce/attachment.htm>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list