TR-069 ACS

Apart from all the upgrades we are doing, I do have other work on as well, and one of the projects that is quite urgent is making a TR-069 server.

I am reading through the spec now - and it is going to be fun.

Of course, there are existing servers, well, at least one, open source, but I do like to re-invert the wheel if I can.

The main thing is that it will be completely in C so should be quite efficient.

Why? Well, for a start, we have these TG582n technicolor routers, and they (a) support TR-069, and (b) have a fairly crap web interface for config. So the plan is to make our control pages for DSL have a whole router config page that allows customers to config their routers centrally and it update the router via TR-069.

Apart from allowing us to make a web config page for the router, and perhaps other routers, it will also allow for replacement routers to have the exact same config, and even for routers to get the config if factory reset.

Obviously we are all about giving our end users choice, and this will be optional. However, even for our more techie customers, this is likely to appeal I expect.

So, the question is, do I make this TR-069 server open source? I may. It does mean writing it slightly differently. If it was only an in-house tool it would be integrated in to our databases and systems very tightly. But it may be more fun to make it a general purpose tool.

If any of you are interested in this, do let me know, and the main features you are looking for.

We are looking for (a) ability to send a new config to the router (b) ability to upgrade firmware on the router, and that is pretty much it!


  1. This would be quite a neat feature (although I don't think my current ZyXEL supports it) and I think there's a good business case for open source. You don't lose much (anything?) from going open source and you gain:

    1 - reputation/free advertising as "that competent, cool ISP" to a new audience
    2 - possibility of wider testing/support for obscure/"broken" (in the technical sense) devices
    3 - good will as the whole thing is verifyably non-evil

  2. Your aims are the same as my recent aims.. I have not had a chance to investigate coding or hacking around existing published source code.

    I would be seriously happy if you did publish yours ;)

  3. Sounds neat.

    I'd add:

    c) Pull configuration from routers for the purpose of backing up and also logging changes

  4. >We are looking for
    >(a) ability to send a new config to the router
    >(b) ability to upgrade firmware on the router

    Sounds cool, I have a TG582n. However, not sure I like the idea that a third party (A&A) can send a new config. to my router, after all how do you know what config. options I want? Note that I had to do some extensive reconfiguration to get the thing to work in the first place.

    Another possible problem with the firmware upgrade is that although it would be good to get these (I've still no idea how to get updated TG582n firmware) I suspect the router will need a reboot following the upgrade. One problem I've noticed with the TG582n is that the firewall port forwarding rules are lost after a reboot. Hence someone (me) would have to manually enter these.

    Having said all this it would be nice to have my router config held centrally, this router has already had one "glitch" in its operation since it was installed three weeks ago. I did look for an option to save the config. to file but haven't found it yet.

  5. How about also having it able to deploy VoIP config to TR-069 capable phones?

  6. Context Switch wrote "I did look for an option to save the config. to file but haven't found it yet."

    It's pretty easy. From the web interface select: 'Technicolor Gateway' then 'Configuration' then at the bottom of that page 'Save or Restore Configuration' and finally the big friendly button labelled 'Backup Configuration Now'

  7. @Ian Mitchell:
    Thanks! Don't know how I missed that one :)


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

ISO8601 is wasted

Why did we even bother? Why create ISO8601? A new API, new this year, as an industry standard, has JSON fields like this "nextAccessTim...