On Sat, May 28, 2016 at 5:34 AM, Hauke Mehrtens <ha...@hauke-m.de> wrote: > On 05/27/2016 12:43 PM, David Lang wrote: >> On Thu, 26 May 2016, Delbar Jos wrote: >> >>> We are conscious of the fact that together with the proposals made by >>> Felix, Luka and Wojtek we are now looking at many "competing" >>> proposals. As a next step, we recommend to organize a workshop, at a >>> practical location and time, where we put everything on the table and >>> define the most appropriate path forward to the benefit of OpenWrt as >>> a whole. >> >> nothing wrong with supporting many different remote management daemons. >> >>> TR-069 is a complicated remote management system and in order to make >>> this initiative a success, we must ensure that the complexity is >>> handled in an elegant way and with respect for OpenWrt's core >>> architecture. More than on the protocol itself, we believe that we >>> should focus on the architectural enhancements required to support >>> remote management in general. >> >> What is it that you think is needed to "support remote management in >> general"?
I am curious if TR-069 has any ability to set parameters for upload and download speeds, so they could be leveraged by sqm-scripts to manage the bufferbloat that DSL modems and dslams have? Also: I have been hoping for nearly 4 years now that we'd see *someone* actually produce a BQL enabled dsl driver for their modem interface so advanced QoS techniques wouldn't be needed on outbound, where we could just enable fq-codel on top of a tightly written driver and be done with it. 100 million modems, all exhibiting 100s of ms of extra, unneeded latency, under load: http://www.dslreports.com/speedtest/results/bufferbloat?up=1 sadly, aside from the freebox revolution v6, I'm not aware of anyone actually doing dsl more right yet. (?) >> It's worth pointing out that many people are remotely managing OpenWRT >> devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job. >> >> now, those are all tools aimed at managing Linux Servers, not networking >> gear, but OpenWRT is a server. >> >> So I'd suggest starting off by creating a daemon that talks <your >> protocol> and just stores the stuff it's sent in some simple files so >> that it can return the info when queried. >> >> Once you have something that talks the network protocol correctly, >> modifying it to change the real files, make uci calls, etc for different >> distros is much easier (just write your daemon with the expectation that >> the input and output details are going to change, so don't get fancy >> with them). >> >> David Lang > > The TR-069 family is currently wildly used by ISPs controlling the (DSL) > CPE devices of their customers. There are probably more than 100 million > device controlled by standards from the TR-069 family out there. When > you get a DSL router from your ISP or buy one in the retail store it is > very likely it supports the standards from the TR-069 family, as a > vendor in this area you basically need support for this to sell your > devices. > > In other technologies you have different protocols to manage your > devices, like cable often uses something different and EPON and GPON > even have all their own management standards. Then there are also some > technology independent standards and so on. It makes sense to build such > a solution in a way to make it easily to expendable for new protocols. > > Hauke > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
