David Lang <da...@lang.hm> wrote: > I wasn't questioning why it's useful to support TR-069. The only part I was > questioning was the statement that OpenWRT needed work to make it > support remote management. > > There are already many tools to remotely manage/monitor OpenWRT > > But that's why I'm saying that it seems like most of the work is in the > protocol > interface. If there is already a daemon that does the network protocol > properly, that should make things very easy. If such a daemon needs to be > written, that would be the place I would suggest that they focus. There are a > lot of people who can do the plumbing work to make the daemon do the > right thing on the system, who are not in a position to work on the network > protocol side and make sure that it works properly with the management > software.
Listing some of the things that come to mind: * Data models. The language that TR-069 uses to describe a certain feature or function is not the same language that OpenWrt uses. The translation is often not straightforward. * Events/notifications. This boils down to the TR-069 protocol agent notifying the ACS when something on the CPE changes. Now imagine that a change occurs to a configuration parameter in UCI, like the wireless SSID. How to address this? * Commit and apply. When the ACS changes the configuration of the CPE, it also expects this configuration to be applied soon after. Updating the configuration in UCI is not enough. * Transactional behavior. A set of TR-069 configuration changes is either applied successfully or not at all. UCI has a commit function but how to check if a configuration change in UCI will also be successfully applied by the system? Now one can debate what "successful" means but you get the point. * Persistent indices. TR-069 expects that a certain object in an array, like "the second network interface", retains its index "the second" during the lifetime of the CPE (barring a factory reset) even if "the first network interface" is deleted. The way that lists work in UCI doesn't make this trivial. Using named instances or aliases are possible ways out. We've attempted to overcome these challenges in our TR-069 solution within the confines of OpenWrt. I'm sure that other management systems (local ones like LuCi or remote ones) are solving similar problems in different ways. Instead of doing all the heavy lifting on the protocol side, I'm hopeful that we can carve out a common subset of requirements that apply to management systems in general and come to better and more reusable frameworks. Jos _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
