I’m looking for some guidance / best practices regarding TR-069 usage on OpenWrt-based routers.
In RDK-based platforms, TR-069 (and now TR-369/USP) is commonly used for communication between the ISP and the device. However, OpenWrt seems to follow a different philosophy, relying mainly on UCI for configuration and ubus for runtime communication, with no TR-069 client enabled by default.
My questions are:
Is it considered best practice to use TR-069 on OpenWrt routers, or is it generally avoided?
If an ISP is deploying routers with OpenWrt, what is typically used instead of TR-069 for communication and management (e.g. provisioning, monitoring, firmware upgrades)?
Do ISPs usually rely on custom cloud solutions (HTTPS, MQTT, WebSocket, etc.), or do some still integrate a CWMP client like EasyCWMP?
From a scalability and maintenance perspective, is adding TR-069 to OpenWrt seen as unnecessary overhead compared to lighter approaches?
I’m trying to understand what is most commonly done in real ISP deployments, not just what is technically possible.
Any insights from people with production experience would be greatly appreciated.
There is no TR-069 on vanilla OpenWrt. Uci is not accessible on wan, the user is the arbiter of their configuration. The ISP's job is to document their access requirements - and to keep its grubby mittens away from the user's property (router/ private network).
We use TR-369 as much as possible and are struggling to get rid of the last traces of TR-069. Just keeping simple TR-069 firmware upgrade around until support for legacy equipment ends.
I don't think many larger ISPs use OpenWrt directly. They use vendor firmware, which of course is based on a SoC SDK originating from OpenWrt nowadays. But management services and such is a vendor specific layer on top of that. This will use TR-369, or optionally TR-069. I can't imagine anyone seeing that as unnecessary overhead.
You could of course easily do a simple UCI transport over MQTT in a home cooked solution. But the transport is not the hard part. Using UCI as a standardised config model might make some sense. But IMHO you'd still end up with lots of small differences between devices which would need to be handled. Different hardware require different config files, even if everything is running the same OpenWrt release
I am mostly interested if someone has experience with upgrading to a new version of openWRT from a standpoint of an ISP. So how would they go about sending and applying that picture from cloud?
ISPs would upgrade OpenWrt the same way they upgrade any other firmware. See:
The TR-369 service running on an OpenWrt CPE would most likely translate that into a standard sysupgrade command. That's what some vendor firmwares do too.
Having done custom images for various WISPs hotspot systems or for IOT-concentrators, up to few hundred devices, I never used TRx69, but custom procedures. Based on https, or, more often recently, based on VPN, having the advantage also to provide remote access, and securing RADIUS or MQTT or remotelogs automatically. Remote config changes (or complete firmware upgrades) done via http(s) or plain MQTT. Of course, only small amount of different devices, each to be handled individually.
If it is only standard OpenWrt you can try OpenWISP, Not an "industry standard" protocol, like you can not have tr69 relays in between but quite neat at campus scale over proprietary fleet management solutions that push "cloud" around every corner.