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 <[email protected]>: > 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 > [email protected] > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > -- Ronaldo Afonso 11 9 5252 0484 www.ronaldoafonso.com.br
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
