Can any support TR-069 management CPE Broadband on ROS v6?

I need it very much!

i am wondering how powerful and popular this is. And will it be better than The Dude and scripting/API

I think it would be a wonderful addition to Scripting/Dude.
Just imagine - shipping a stock RB750 to a customer without opening the box at all.
Only note the MAC Address, and create a configuration file, while the RB is shipping.
After the customer receives the RB, he can follow the on-box instructions (plug WAN into Ether1),
the RB will automatically receive a DHCP lease with an Option giving it a TR-069/CWMP URL.

Then, via TR-069 a .rsc file is pushed to the RB, which loads it and is ready to go!

I think it would be a wonderful addition to Scripting/Dude.
Just imagine - shipping a stock RB750 to a customer without opening the box at all.
Only note the MAC Address, and create a configuration file, while the RB is shipping.
After the customer receives the RB, he can follow the on-box instructions (plug WAN into Ether1),
the RB will automatically receive a DHCP lease with an Option giving it a TR-069/CWMP URL.

Then, via TR-069 a .rsc file is pushed to the RB, which loads it and is ready to go!

You're right - it will be really a wonderful addition. But still we have to wait for it to be released. I vote for this addition too!

Can any support TR-069 management CPE Broadband on ROS v6?

+1

+1 !!!

Our ISP is using this, so it could be useful.

Nick.

Could you please clarify, isn't this basically the same as sending a "auto.rsc" file to the device with FTP ?

Could you please clarify, isn't this basically the same as sending a "auto.rsc" file to the device with FTP ?

Yes but, TR-069 it's a standard already used by us

+1 for implementing TR-069 (CWMP) on ROS!

+100 for implementing TR-069 (CWMP) on ROS!

+1 as well

+1

...

+100500

Normis, fine. You're an ISP's admin, I'm the customer.

I've got my brand new shiny unopened RB from your employer (ISP). I've plugged cable from ISP to ether1. Now send the auto.rsc. Go.

Normis, fine. You're an ISP's admin, I'm the customer.

I've got my brand new shiny unopened RB from your employer (ISP). I've plugged cable from ISP to ether1. Now send the auto.rsc. Go.

ISP should be the one giving out the routers But I see your point

Anyway, this feature would require us to open up the firewall, and if we are doing that, I can also upload the .auto.rsc (because ISP sees what you plugged in there)

One seemingly secure solution would be passing only mac-telnet and ip traffic from the gateway on ether1, which restricts "hacking" only to ISP. Unhappy owner of routerboard may always reset the device to defaults after changing ISPs or whatever. Implementing TR-069 would bring happiness into lives of ISPs, that already have deployed compatible management software, but at this moment self-deployment by the end-user is rather complicated by any means and reliable automatisation is difficult. Go with the easy change first

Scenario of "buy yourself a routerboard and plug our cable in port 1 to enjoy Internet on ports 2-3 and wifi, voip on port 4 and TV on port 5" is impossible without prior manual intervention of an administrator, or synchronized cooperation with end-user (or non-elegant configurations like WAN on port 2-5)

+1 for TR069

Could this be done via script I wonder ?

Some of the routers we deal with are configured to Fetch their config when connected so no firewall issues I believe ?

i am wondering how powerful and popular this is. And will it be better than The Dude and scripting/API

Well, for one it would be a standard and thus work with a ton of other systems.

Two, one would assume that MT would update The Dude to manage TR-069 devices, so then The Dude could be used to manage other TR-069 based devices, whether wireless, fiber, DSL, etc.

+1 (Its not replacable with auto.rsc)

Should be able to base something off this - http://freecwmp.org

I truly think TR-069 would be one of the best things Mikrotik has ever done.

The "inside of the house" is becoming a big challenge for ISPs. We have even small families having 15+ devices inside their home. It could be a BIG help and profit to ISPs to be able to effectively manage that.

I wouldn't even mind if there was an up-charge (higher license) to have that feature.

Paul, PDMNet

+1

Domenico

I truly think TR-069 would be one of the best things Mikrotik has ever done.

The "inside of the house" is becoming a big challenge for ISPs. We have even small families having 15+ devices inside their home. It could be a BIG help and profit to ISPs to be able to effectively manage that.

I wouldn't even mind if there was an up-charge (higher license) to have that feature.

Paul, PDMNet

My ISP (Beeline - one of biggest ISP in Russia) starting use TR-069...
I want this feature.

+1

+1

nice feature

????
In some scenarios, I donot know how useful is this protocol.
For a WISP, I doubt it.

VERY useful for us. We are doing lots of manual customizations for customers and would do a lot more if we could control/manage it centrally.

VERY useful for us. We are doing lots of manual customizations for customers and would do a lot more if we could control/manage it centrally.

I think many things that WISPs don't so is simply because people don't yet understand the advantages of it.

+1.
We make extensive use of TR-069

+1

we need it!

Everyone, thanks for the suggestions.

Please, post your favorite TR-069 ACS (auto configuration server) software so that we can consider adding support

Here is an Open Source Project:

http://sourceforge.net/projects/openacs/

It is used by many ISP.

Please let us know when a beta could be ready

its just shouldn't be part of core (ie "system")package and be in separate one.

+1 for a TR-69 client!

Trying to revive this thread!

I want to jump in and make a few observations to better make the case for TR-069.

First, as we all know, RouterOS is about solving problems. If there isn't a built in function, we write a script. Always a work around! However, we can't think about a workaround for TR-069 and here is why. TR-069 is the number one protocol used by telecoms to manage CPE devices and it currently can't manage RouterOS so they don't buy RouterOS.

"They should use the Dude" is not a solution, they won't and likely they can't for a myriad of reasons. We can't propose stuffing a square peg into a round hole simply because we don't have round ones and don't want to produce them. We have to make round pegs or square pegs if that is what the market demands, make even oblong ones with curb feelers. Responding with workarounds is pointless if we want to succeed big. The only other option is continue succeeding small to medium but it will never be big until we think big.

Therefore, if we want to bring RouterOS to what is likely the largest market out there we need TR-069 support. Responding with workarounds here is pointless because they will not be accepted. Even D-Link has TR-069 support in some models so this is not rocket science.

Will TR-069 help the WISP? Probably not. The WISP will continue using the Dude, or flashfig, or the custom scripts they wrote and big telecom will continue buying Adtran and similar overpriced, underpowered devices until we get TR-069 for Mikrotik.

Anyway, this feature would require us to open up the firewall, and if we are doing that, I can also upload the .auto.rsc (because ISP sees what you plugged in there)

+1 for this.

And to correct your earlier point Normis, it doesn't require to open the firewall - the router either receives the TR-069 server details via DHCP option, or has a default hostname for TR-069 which we can then manage on our network via DNS - and the router connects out to the server, not the other way around

Anyway, this feature would require us to open up the firewall, and if we are doing that, I can also upload the .auto.rsc (because ISP sees what you plugged in there)

+1 for this.

And to correct your earlier point Normis, it doesn't require to open the firewall - the router either receives the TR-069 server details via DHCP option, or has a default hostname for TR-069 which we can then manage on our network via DNS - and the router connects out to the server, not the other way around

depends how tr-069 implemented.
only in few "hardwired" (usually portion of Chinese ODM/OEM devices, shipped to ISP directly)CPE was bypassed firewall "on purpose", rest - will comply/follow firewall in that, but include rules in "default config" that enable it on public interfaces.
personally i think "hardwired" things a extremely Evil thing and strongly against it. which apply to mandatory TR-069 access(and other protocols and features(one of competing companies aside TR-069 - also enforced HIP support and other nonsense, but that just ridiculous and side-effect of bogus code the borrowed "off the shelf" in FOSS branch w/o modifications).

Afternoon all,
Has there been any movement on this? We are dying to use TR-069 on MT, it would solve pretty much all our provisioning issues!

Hope this happens sooner rather than later.

Afternoon all,
Has there been any movement on this? We are dying to use TR-069 on MT, it would solve pretty much all our provisioning issues!

Hope this happens sooner rather than later.

Normis asked which TR-069 ACS everyone is using. Would you mind listing what you use?

Isn't there a logical flaw in the request?
Which SW we use so MT can support it, which we don't use because MT devices doesn't support it yet, because we don't use a software so MT can support it, which we don't use because... [ loop until stack overflow or neural exhaustion, whichever applies].
So this is directed to those using TR-069 already, which don't use MT devices because they are not supported, so they are probably not on this forum, not being MT users...

Maybe the right question is: Which software you know of would you like to be supported, so you can use it in the future for support testing.

Every implementation has to follow these requirements, anything else being vendor specific and irrelevant: https://www.broadband-forum.org/cwmp.php
Shouldn't this be the only reference, since broadband forum are the document owners?
No one implements a web browser based on reverse engineering apache...

Not really. Some of ISPs do DSL and WIreless or DOCSIS Cable and Wireless or even just got sick of dealing with customer issues and moved to using TR-069 managed in home devices for the customer. Some ISPs are deploying LTE equipment.

At my company, we don't use MikroTik for outdoor wireless. We do use MikroTik for routing. I wouldn't mind selling customers managed in home routers which I can use to perform QoS and see how many piss poor wireless signal devices they have in their home. The other existing TR-069 equipment, which have provisions for fiber to the premises, offer us those capabilities, now.

The existing gear tends to be more expensive. But at some point, it will be worth moving that direction. We only have 2500 wireless customers right now. We will have to do something different by the end of the year when we should be at 3100 or more. Right now we have customers using whatever device they prefer for in-home. It's a support nightmare. We are looking to standardize.

At scale, it gets difficult to manage all those in-home customer router/APs without a tool. TR-069 is an existing standard on which to build that tool. A TR-069 based tool will also work for our LTE devices which we are testing on 4 towers. The LTE devices already have support.

its still remain ~ ODM/OEM thing for ISP, rather than feature of "retail" firmwares for CPE , BRAS.
some companies even design "stub" wrappers to overcome "legacy" gear of installbase(which is pretty expensive investment into developing such software/infrastructure)including SOHO gear.
my point is: its apparently not priority, yet.
but for outdoor gear it can be especially handy, perhaps, especially for ptp bridges.

Afternoon all,
Has there been any movement on this? We are dying to use TR-069 on MT, it would solve pretty much all our provisioning issues!

Hope this happens sooner rather than later.

Normis asked which TR-069 ACS everyone is using. Would you mind listing what you use?

Sure, we currently make use of Tilgin routers as a CPE, due to the fact they have an ATA built in and an ACS (Auto configuration Server) system that works on TR-069, however it is proprietary.

I'm game for any ACS/TR-069 server product as long as it works.

Any updates guys?

Afternoon all,
Has there been any movement on this? We are dying to use TR-069 on MT, it would solve pretty much all our provisioning issues!

Hope this happens sooner rather than later.

Normis asked which TR-069 ACS everyone is using. Would you mind listing what you use?

Sure, we currently make use of Tilgin routers as a CPE, due to the fact they have an ATA built in and an ACS (Auto configuration Server) system that works on TR-069, however it is proprietary.

I'm game for any ACS/TR-069 server product as long as it works.

thats major issue with most "TR-069-aware/supported"-labeled things - they simply don't, relying on sub-standard, proprietary sub-sets, twisted beyond imaginable/usable limits in most cases. same about PON gear.
interoperability, compatibility, scalability in result - become ruined, not improved. sadly.

Morning all,

There been any developments?

Morning all,

There been any developments?

What do you expect? I hope not that you expect that when you file a request, it will be implemented a week later.

my guess since nobody mentioned such feat much from MT crew/designers/PR - its was worked low-priority. i hope thats will get "green light" atleast in ROSv7, but NOT in enforced/enabled-by-default state.

Hello,

the TR-69 feature request is old and a not answered by Mikrotik. I dont think they are interested, they want you to use the API/Dude.

We use(d) Mikrotik's on client sides to terminate PPPoE behind GPON ONT's.
As the network is growing, we need to supply our NOC a proper and standardized way of checking the end user devices. 
This can only be TR-69. (Dude cannot do this scabable/standardized/integrated with Support Systems)
As Mikrotik doesnt offer TR-69, we move away from Mikrotik and terminate PPPoE now on the ONT's itself.

Thanks,
Heiko

We are working on TR069 but it would be great if there would be some consensus on which generic configuration options you want to set with it. 
The whole point of TR069 is vendor agnostic configuration settings, so that you can set all of your devices with new config, without worrying about syntax and such things, so we would like to see which features are most important, where we could start. 

I'd like to chime in here and add my 2cents.

TR-069 would cool but everyone here uses Mikrotik, the config can get complicated, it supports many protocols that other vendors don't OR the TR-069 server doesn't support OR mikrotik only support certain aspects of their config.

I don't care about proprietary systems when it comes to configuration. So for me, what would be ideal would be one of the following.

Router receives config servers details (This could be an open system i.e. *we* understand how the protocols work and implement our own server OR integrated into the dude), it can receive these details either via A) dhcp option or B) or via some sort of other protocol (similar to l2 discovery of capsman).

Once router finds the server, it initates a request to that server sending either the serial number or MAC address of its interface
Server then looks in its system for a complete config file, client grabs the file, reboots and *locks* onto the server.

Now, everytime the router reboots, it will look on the server if there is a later revision of config, if there is, it will grab that and reboot into that config.

I push out about 100 odd new routers to clients each month, Its crazy to configure all of these by hand and the default config of routeros blocks incomming connections on the WAN so I can't even use the API (not to mention if this is behind NAT then i am screwed). If the client initiates the connection to the server, life would be so easy.

EDIT:

Or even better, use the cloud. We already get DDNS names, on that system configure your router where to find its config server, then the router would only need internet acecss

Hi Normis,
I would like to configure at least below configurations by TR069
1. IP address configuration
2. Router DNS client configuration (including additional DHCP option set)
3. VLAN conifguration
4. PPPoE client configuration
5. DHCP client configuration
6. Add/remove/set Firewall filter rule
7. Add/remove/set Firewall NAT rule
8. Add/remove/set Firewall address-list
9. Add/remove/set Firewall mangle rue (to change ToS, DSCP for iptv service QoS)
10. Add/remove/set Queue simple rule
11. Interface bridge and interface bridge port configurations
12. DHCP server lease configuration to give static IP to STB

I believe with those possibilities IPTV providers can offer routerboard as IPTV/OTT CPE router with any QoS methods.

usually relevant to "basic config" options/management are common in TR-069, eg to ensure consistency/integrity of configuration across network, basically(&seamlessly update it too).

I'd like to chime in here and add my 2cents.

TR-069 would cool but everyone here uses Mikrotik, the config can get complicated, it supports many protocols that other vendors don't OR the TR-069 server doesn't support OR mikrotik only support certain aspects of their config.

I don't care about proprietary systems when it comes to configuration. So for me, what would be ideal would be one of the following.

Router receives config servers details (This could be an open system i.e. *we* understand how the protocols work and implement our own server OR integrated into the dude), it can receive these details either via A) dhcp option or B) or via some sort of other protocol (similar to l2 discovery of capsman).

Once router finds the server, it initates a request to that server sending either the serial number or MAC address of its interface
Server then looks in its system for a complete config file, client grabs the file, reboots and *locks* onto the server.

Now, everytime the router reboots, it will look on the server if there is a later revision of config, if there is, it will grab that and reboot into that config.

I push out about 100 odd new routers to clients each month, Its crazy to configure all of these by hand and the default config of routeros blocks incomming connections on the WAN so I can't even use the API (not to mention if this is behind NAT then i am screwed). If the client initiates the connection to the server, life would be so easy.

EDIT:

Or even better, use the cloud. We already get DDNS names, on that system configure your router where to find its config server, then the router would only need internet acecss

I agree with "blingblow" on the approach at least for the beginning.
Developing a full data-model which supports extensive configurability of the entire set of commands supported by the CPE can be really heavy.
A usual trade-off is to support some basic parts of the parameter tree and leave to config file the more complex functions.
The Download RPC of TR-069 is meant to serve for this purpose : instruct the device to download a config file from a configurable address [which could be a different one for each device]
The Download RPC of TR-069 is also the basis for firmware upgrades.
Just my 2 cents.
Have a great day - Domenico

Hi Normis,
I would like to configure at least below configurations by TR069
1. IP address configuration
2. Router DNS client configuration (including additional DHCP option set)
3. VLAN conifguration
4. PPPoE client configuration
5. DHCP client configuration
6. Add/remove/set Firewall filter rule
7. Add/remove/set Firewall NAT rule
8. Add/remove/set Firewall address-list
9. Add/remove/set Firewall mangle rue (to change ToS, DSCP for iptv service QoS)
10. Add/remove/set Queue simple rule
11. Interface bridge and interface bridge port configurations
12. DHCP server lease configuration to give static IP to STB

I believe with those possibilities IPTV providers can offer routerboard as IPTV/OTT CPE router with any QoS methods.

To add that list
13. WLAN settings (SSID, encryption, PSK, channel settings)
14. Administration - username/password, radius, WAN access to management etc)

For us the most important thing with TR-069 is ability to (pre-)configure PPPoE client settings such as username and password, and set up wireless with a certain SSID and key etc. 90% of time spent on phone between technicians and customers is dealing with these two items, due to lack of customer technical understanding. If TR069 support was there, this could be entirely automated.

Hi,
are you using any opensource of TR-069 server?

Hi Normis,
I would like to configure at least below configurations by TR069
1. IP address configuration
2. Router DNS client configuration (including additional DHCP option set)
3. VLAN conifguration
4. PPPoE client configuration
5. DHCP client configuration
6. Add/remove/set Firewall filter rule
7. Add/remove/set Firewall NAT rule
8. Add/remove/set Firewall address-list
9. Add/remove/set Firewall mangle rue (to change ToS, DSCP for iptv service QoS)
10. Add/remove/set Queue simple rule
11. Interface bridge and interface bridge port configurations
12. DHCP server lease configuration to give static IP to STB

I believe with those possibilities IPTV providers can offer routerboard as IPTV/OTT CPE router with any QoS methods.

About security of TR-069 in RouterOS

By default TR-069 Remote Request WAN port 7547 is quite secure. When CWMP client is enabled/configured, then it is "strongly linked" with an ACS with provided URI and only initiates communication with that ACS. On incoming port 7547 there is HTTP server listening and validating that incoming request is HTTP-GET, that URI is correct and that authentication is correct. Everything else is dropped. If those incoming parameters are correct, then incoming HTTP connections is closed. After that CWMP initiates Session with previously configured ACS server. This means that incoming connection cannot change anything on CWMP client - it can only "poke" it to start communication with ACS. So even IF attacker had all the correct credentials to make a valid request, in worst case scenario it will simply start Session with previously configured/secured ACS server.

Unfortunately there is much misinformation on Internet about this attack - it seems that CWMP client was listening for incoming connections on WAN port using another protocol - TR-064, which is meant to perform initial configuration through LAN ports. For that reason it accepted configurations using HTTP-POST on WAN port, which of course is insecure. Don't know if that was because ISPs misconfigured routers or it was a software bug, that allowed TR-064 requests on WAN port.

Anyway RouterOS doesn't implement TR-064, so the specific security issue isn't there. RouterOS supports a more powerful initial configuration through Netinstall, so there is no need for TR-064. We plan to have "Best Practices Guide" in Wiki for TR-069.

That sounds good to me. It may be a good idea to advise the use of a literal IP address, preferably
a local address, for the ACS server instead of a DNS name to reduce the possibility that an attacker
could intercept or replace the DNS record and get the routers connecting to his own server.

+1000! This will be a musthave feature.

For some time it is a feature of the RouterOS. Get the tr069 package, install on the router and connect to your ACS server.

See the docs here:
https://wiki.mikrotik.com/wiki/Manual:TR069-client

For some time it is a feature of the RouterOS. Get the tr069 package, install on the router and connect to your ACS server.

See the docs here:
https://wiki.mikrotik.com/wiki/Manual:TR069-client

Wow? thank you!

Hi guys -

I just installed the tr069_client package on a hAP ac running RouterOS v6.39.1 and have a quick question.

Do I have to manually open the connection request port (7547) on the hAP ac firewall?

The hAP ac is communicating with my ACS via BOOT and PERIODIC informs. However, I am unable to initiate connections to the hAP ac from the ACS. The ACS is sending TCP Syn packets to the ConnectionRequestURL reported by the hAP ac, but no response is received and the connection request eventually times out. What I am expecting to see here is that the ACS is able to open a TCP connection to the port specified by the hAP ac in the ConnectionRequestURL parameter that it sends to the ACS (port 7547). Once the TCP connection is established the ACS will send an HTTP GET to the ConnectionRequestURL which should then cause the hAP ac to initiate a new CWMP session with the ACS.

Thanks!
-Matt

Yes, you have to open ports for that service in the firewall. Our suggestion would be to allow only traffic in from known hosts list, like from your ACS server.

Thank you janisk!

It might be helpful for others in the future if a note about this is added to the tr069_client help page. It was not obvious to me that this was needed.

-Matt

Hi guys - I just installed the tr069_client package and I would like to use the ProvisioningCode, to identify the configuration revision. As you will see below, this parameter is allways empty.
Do you know, how can i set this value ?
Thanks!

Usually, ProvisioningCode Parameter can be set using DHCP option (which is not yet supported by ROS tr069-client). But for now, it can be set from the ACS, because it is simple writable Parameter.

Hi,

I'm deploying TR069-Client on all the Mikrotik CPEs of an ISP, having a lot of its customers behind NAT.
Thus the ACS (cloud hosted) is currently getting back from the CPE a bad connection request URL containing the private IP address, which is unreachable from the outside.

TR-069/ Annex G defines two mechanisms in order to solve this issue :

• STUN and UDP NAT Traversal
• XMPP TCP session

Do Mikrotik plan to add support for Annex G ie TR069 Connection Requests behind NAT ?

Hi,

I'm deploying TR069-Client on all the Mikrotik CPEs of an ISP, having a lot of its customers behind NAT.
Thus the ACS (cloud hosted) is currently getting back from the CPE a bad connection request URL containing the private IP address, which is unreachable from the outside.

TR-069/ Annex G defines two mechanisms in order to solve this issue :

• STUN and UDP NAT Traversal
• XMPP TCP session

Do Mikrotik plan to add support for Annex G ie TR069 Connection Requests behind NAT ?

+1 for STUN

+1 for STUN

To keep plug-n-play feature of TR069-Annex G-enabled router, a public STUN server address or hostname should, by default, be configured in Mikrotik router default config, right ?
Does such public STUN server exist or do you think Mikrotik should operate its own STUN server ?

To keep plug-n-play feature of TR069-Annex G-enabled router, a public STUN server address or hostname should, by default, be configured in Mikrotik router default config, right ?
Does such public STUN server exist or do you think Mikrotik should operate its own STUN server ?

TR-069 is not for people who would worry about that. It is for ISPs who can deploy their own infrastructure for this, inside their access network.

+1 for STUN

To keep plug-n-play feature of TR069-Annex G-enabled router, a public STUN server address or hostname should, by default, be configured in Mikrotik router default config, right ?
Does such public STUN server exist or do you think Mikrotik should operate its own STUN server ?

For ISP - it is not a problem. For ex. you have 30000 rb951ui and tr-069. But some of them - under the NAT. So, you have 2 options - vpn and stun. I prefer stun. Clear?

For ISP - it is not a problem. For ex. you have 30000 rb951ui and tr-069. But some of them - under the NAT. So, you have 2 options - vpn and stun. I prefer stun. Clear?

Yes, I agree, TR069 and Zero-touch configuration are not to be confused.

Hi Normis,
I would like to configure at least below configurations by TR069
1. IP address configuration
2. Router DNS client configuration (including additional DHCP option set)
3. VLAN conifguration
4. PPPoE client configuration
5. DHCP client configuration
6. Add/remove/set Firewall filter rule
7. Add/remove/set Firewall NAT rule
8. Add/remove/set Firewall address-list
9. Add/remove/set Firewall mangle rue (to change ToS, DSCP for iptv service QoS)
10. Add/remove/set Queue simple rule
11. Interface bridge and interface bridge port configurations
12. DHCP server lease configuration to give static IP to STB

I believe with those possibilities IPTV providers can offer routerboard as IPTV/OTT CPE router with any QoS methods.

To add that list
13. WLAN settings (SSID, encryption, PSK, channel settings)
14. Administration - username/password, radius, WAN access to management etc)

I'm facing some technical error while configuration.

Add/remove/set Queue simple rule - I want to make simple rule to add or remove but getting error

I requested this of support, but I want to see TR-143 support as well.

I requested this of support, but I want to see TR-143 support as well.

nice idea

Hello everyone,

We have started using TR-069 for our RB912R-2nD-LTm&R11e-LTE MikroTik devices.
Please put the "Access Technology" parameter for the Device.Cellular interface(s) - it is very userfull to our deployment.

Thanks,
Tudor

Hello everyone,

We have started using TR-069 for our RB912R-2nD-LTm&R11e-LTE MikroTik devices.
Please put the "Access Technology" parameter for the Device.Cellular interface(s) - it is very userfull to our deployment.

Thanks,
Tudor

MikroTik team already added this feature in Testing software version.
You can check it with nodes:
"Device.Cellular.Interface.1.X_MIKROTIK_CurrentAccessTechnology"
"Device.Cellular.Interface.1.X_MIKROTIK_BandInfo"
"Device.Cellular.Interface.1.USIM.IMSI"
"Device.Cellular.Interface.1.USIM.ICCID"

I also will like to have TR-143 support.

Hello everyone,

We have started using TR-069 for our RB912R-2nD-LTm&R11e-LTE MikroTik devices.
Please put the "Access Technology" parameter for the Device.Cellular interface(s) - it is very userfull to our deployment.

Thanks,
Tudor

MikroTik team already added this feature in Testing software version.
You can check it with nodes:
"Device.Cellular.Interface.1.X_MIKROTIK_CurrentAccessTechnology"
"Device.Cellular.Interface.1.X_MIKROTIK_BandInfo"
"Device.Cellular.Interface.1.USIM.IMSI"
"Device.Cellular.Interface.1.USIM.ICCID"

It's working in ROS 6.46beta59, thank you!

Hello to all,
Can we expect some additional useful information? To manage interface links (if Gigabit links works ar 10/100), to solve WiFi problems if device CCQ are low. Like:
Interface>Status>Rate - Device.Ethernet.Interface.*.Rate
Wireless>Status>Overall Tx CCQ - Device.WiFi.AccessPoint.*.ccq
Wireless>Registration>Signal>Device CCQ - Device.WiFi.AccessPoint.*.AssociatedDevice.*.ccq

I requested this of support, but I want to see TR-143 support as well.

+ FOR TR-143
+ FOR XMPP [Annex K of TR-069 Amendment 5]

Thanks

Support for TR-143 and XMPP would be great as we have carrier customers who are deploying behind CG-NAT, and have requirements for CAF testing which can be supported, per FCC rulings, using TR-143. We also support HA device management servers which leverages AWS ELB and could use support for a second cookie to manage sessions to the load balancers fronting our ACS.

Necessary functionalities of the tr-069 protocol:
1.pppoe / pptp connection:
- uptime
- down count
- all user / password / server connecion parameters for pptp client
2. Wireless
- client radio signal status parameters

Hi @Normis,

As appears in the TR069 documentation reference (https://wiki.mikrotik.com/tr069ref/current.html), VLAN termination (and other configurations) are not integrated yet in v6.48.5. This would be usefull for all ISP that uses TR-069 for provision their CPE's.

There be great if this points also could be integrated:

• Vlan configuration (termination/trunk)

• Services configuration. For example, disable HTTP service or change SSH port.

• Create DHCP Server network for deploy a DHCP server

• Create IP pool for deploy a DHCP server

• Create users and groups

• Create simple queues

• Create virtual interfaces like bridges

• Configure SNMP

Thanks!

Hi, there are any news or important changes for TR-069 in RouterOS v7??

Regards.

Hi, there are any news or important changes for TR-069 in RouterOS v7??

Regards.

From what I can see on CHR version 7.1.1 looks exactly the same as v6 to me. Everything working as expected.

@Mikrotik team, wondering on ipv6 parameters possibilities? Ipv6 working on the CHR but in tr069 with full GPV there is no ipv6 addresses other than that on DNS.

maybe:
https://cwmp-data-models.broadband-foru ... ice.DHCPv6.
https://cwmp-data-models.broadband-foru ... Address.{i}.
https://cwmp-data-models.broadband-foru ... 6Prefix.{i}.
https://cwmp-data-models.broadband-foru ... Address.{i}.

Unclear how to approach ipv6 for firewall though. Above i suspect above would already help considerably.

Also looking into maybe switching to 2.12 or 13 models? USP support?