Thats it, Im a small ISP trying to start using TR 069 to configure my clients’ CPEs remotely with ease. Currently we have to do remote web access and they’re not standardized. Also, when the CPE gets reseted, We’re in trouble.
hello!
first of all you need to build a lab with a dhcp and olt setted with helper address to that dhcp.
on ont side you need to check if it take option43 suboption 1 (string) for acs url, and also that send the option60 with tr069 or tr181 broadband forum says (something.com).
on dhcp side you need to configure that when discover is recieved with option60, send the response with the acs url.
with that you have the first step.
second you need to see wich user password is by default. here you have two options:
1 if ont has some user pass by default you can permit that or ask to vendor a firmware with some user pass that you want
2 if you dont know or also is not possible to change you can allow any connection
when you have the connection with the acs you can start to set the parameters on genie via script o manually. see the datamodel provided by vendor or on datamodel of broadband forum.
there is a learning curve but it is not complicated you need to read and read. also is good to have some basic skills of programming at least to understand scripta provided here in the forum.
Thanks for the reply, what I’m looking for is exactly that: someone who will do all of that to me, because I dont have the knowledge and time for that.
ps: do the TR069 uses the same credentials as the web access in order to authenticate?
@zaidka sells commercial support. I would engage with him.
To answer your other question, no. The GenieACS GUI and CPEs do not use the same credentials.
I spent one entire month dissecting the documentation, the source code the posts on this forum. I even made one contribution to the GitHub repository Wiki.
So many experiments on localhost labs.
It was a fun experience.
Now I am implementing a Genie ACS server to my ISP employer in a production environment.
I will contribute more here, return some of the knowledge that I got here.
Your posts helped me a lot!
1 Like
I’m glad I could help!
One thing I will caution you when you run into CPE bugs - and you inevitably will - CPE vendors always try and blame the ACS. The way I’ve found to beat them at that finger pointing game is hit them with the soap conversations and then always point back to the spec where their device isn’t conforming. Because their standard response is going to be “works for me.”
My favorite is one vendor told me “None of our other customers are having these issues” and I responded back, “yeah, because none of them are actually using the features of the CPE”, like DHCP option 43. Because if they were, they’d be filing defect reports too…
If you haven’t looked into DHCP option 43, I would encourage you to use it if at all possible. It allows the CPE to get the ACS URL from DHCP. This makes it really, really easy to swap CPEs between a dev and prod environment. Absolutely no intervention is needed on your part.
To give a more concrete example, in my office all my (both DSL and eth wan) are configured for untagged traffic is PPPoE, and CPE mgmt is vlan 4 (our CPEs are configured with two WAN services per interface - one for PPPoE, one for CPE management). When the CPE gets its DHCP on the mgmt interface, it also gets the IP of our dev acs instance via DHCP option 43.
In the field, the dhcp server on vlan 4 (CPE mgmt) gives out the acs URL for our production ACS server.
If you are using DSL, one thing that was a huge time saver for our support guys is being able to pre-qualify loop issues. The CPE and DSLAM support whats called a DELT - duel ended line test. And with the diagnostic data that comes back, you can plot it out and see why the customers loop might be having issues. I don’t have anymore examples of really bad loops, but here is an example DELT on a CPE in our office, so the loop is really short and doesn’t show any real issues.
If this loop had huge spikes on the QLN, that would be an indicator that there is bonding/grounding issues with the loop. And those spikes are usually at the frequency of nearby AM radio stations. If the HLog has a valley (not that dip you see at 1,850khz in this picture), thats an indication there is a bridge tap.
1 Like
I already have faced some CPEs bugs on the implementation of TR-069. The most recent one was with ZTE F670L and F680, the problem was when I try to set: InternetGatewayDevice.ManagementServer.PeriodicInformTime
In response, I get an error of cwmp.9003 Invalid arguments.
I think that is a facturer problem because the actual value is equal to InternetGatewayDevice.ManagementServer.PeriodicInformTime -62135596800000.
I only can set with success the same value. If I change to something else that is not equal to -62135596800000 I get an cwmp.9003 Invalid arguments.
With your vaste experience with TR-069. Have you faced something like this?
Oh yes :). Not quite on that level, but yes. Some CPE vendors won’t let you set the inform interval to anything under 30 seconds. Now anything under 30 seconds sounds ludicrous, except when the CPE is unprovisioned, I want it to check in as often as possible for when its configuration state changes (i.e., the CPE is added to an account and can actually get config settings). Otherwise, I get pestered from techs/csr’s/my boss that things “aren’t working” because they don’t have any patience.
I recently had to rework my provisioning process because Zyxel VMG4927 times out the session if you change the inform interval while also setting other parameters during the session. I’ve gone around and around enough with Zyxel that it was honestly easier for me to rework my provisioning process than to fight with their sales engineer on why this is a defect.
What happens when you set the inform interval in the CPE GUI and try and read it back via the ACS? Is the value still -62135596800000 no matter what the actual value you put in the GUI? If not, what happens when you try and set the inform interval on the CPE to the value that comes back?
Another thing you can try is pop the cover on the CPE. There is more than likely a 4 pin serial header on there. Hook up a TTL serial cable to the CPE and you will more than likely get a lot more logging/debugging information than the CPE exposes via either its web-based log viewer, or InternetGatewayDevice.DeviceInfo.DeviceLog
I can’t speak for that particular device, but sometimes setting the option cwmp.datetimeMilliseconds (or DATETIME_MILLISECONDS in v1.1) to false helps. This strips away the milliseconds part of the datetime string when setting parameter values.
@akcoder, @zaidka. I found it appropriate to move our discussion to a separate new topic. If it was wrong, tell me and I will remove the newly created topic, and continue the discussion here.
The new creted topic: Problem on Set Periodic Inform Time on ZTE CPEs