[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: toke at toke.dk [toke at toke.dk]
Sent: Wednesday, October 5, 2016 10:11 PM
To: Sukru Senli
Cc: openwrt-devel at 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.senli at 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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel