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
