What should I do if the telecom optical modem settings are changed back in the middle of the night? The revised bridge was restored overnight, and I figured out the temperament of ITMS

recently, I wrote in my about how to modify the bridge in the super password article. Later, a friend did it—it was fixed on Friday night, but the internet disconnected by Sunday morning. When I entered 192.168.2.1, I saw the bridge was gone, and the WAN connection table had reverted to its original state. He asked me: Is this optical modem really something? It's not Cheng Jing, it's ITMS doing it. I've run into the exact same pitfall myself: at 3 a.m., the optical modem restarts by itself, but the whole family can't get online in the morning. That day, I almost had to send the router back to the factory.

clarify first, your optical modem also has a remote control

ITMS is the telecom remote network management system. You can think of it as the operator's main unit managing the entire province's optical modem. Your optical modem has a dedicated connection called TR-069, and the service type is neither INTERNET nor OTHER, just the line between it and ITMS. The modem regularly "reports" to ITMS; when a technician visits, changes to plans, or a unified firmware rollout in the area, ITMS will also trigger a standard configuration for your optical modem.

problem lies in this standard configuration. If what you change in the backend doesn't match the template—changing bridging is a major hit, deleting routing connections or drastically changing LAN subsidiaries counts—ITMS might overwrite your settings when issued once. It's like rearranging furniture at home, and the property management comes in every night to arrange it according to the floor plan, but you wake up in the morning and it looks familiar but you can't quite say what's wrong.

distribution is mostly concentrated between 2 a.m. and 5 a.m., with some cases being forced to push within 72 hours after installation. So the phrase "changing Friday to Sunday morning and discovering it's broken" is especially typical: the early morning in between, which is the time of the incident.

my night: the altered bridge, overnight back to square one

tell me about my own case. On Friday night, I switched to a bridge. The optical modem was a bridge plus my router's dial-up, everything worked fine. The wired speed test reached 940 Mbps. I was satisfied and went to sleep. At 7 a.m. on Sunday, the router at home turned red, and everyone was cut off.

first reaction was that the router was broken and restarting was useless. I plug my computer straight into the optical modem LAN port and find the address is 192.168.2.x—my heart skipped a beat. In bridge mode, plugging the optical modem directly into the computer won't get the address. If it does, it means the modem will return to routing mode and dial on its own. I used useradmin to check the backend, and the bridge connection I built was gone. The previously deleted ROUTE connection was left unchanged in the list, and even the WiFi name was restored to the first string from ChinaNet on the day of installation.

that one is a Huawei HS8145V5. Later, my friend's ZTE F7015T and my other second-hand TEWA-750G were both pushed once, and their performance was pretty much the same. The model affects how you defend later, but it doesn't affect your judgment.

How can

confirm that he was pushed last night: three pieces of evidence

Don't rush to act, get the evidence first, or you won't even know who to blame."

the first place: the system log. The path is usually a status → system log, which you can check until two or three in the morning to find records labeled TR-069 or ACS. Seeing SetParameterValues (the given parameters) means the configuration is overridden, and seeing Download Request means the firmware has been pushed. Huawei's logs often write "TR069: Session," while ZTE sometimes writes it as CWMP. It's okay if you don't recognize them all; these two keywords appear in the early morning hours basically without error.

second, WAN connection table. The links you deleted are back, and the links you created are gone—that's the most direct evidence. By the wayIPTV check if the OTHER connector is still there, and it's often the ones who get pushed to wipe it out in one go.

Third place, firmware version number. The system → write down the version number in the version info and stick a sticky note on the modem. Last night it was still V3.0.5, today it's V3.0.6, meaning the firmware was pushed out overnight.

one more thing: when checking the lights, first glance at the indicator light. If the LOS red light flashes or the PON doesn't turn on, it's a wiring issue. If you the light self-check , don't blame the light degradation fault on ITMS. The lights were all normal, but I couldn't get online, so I started to suspect it was being pushed.

I'll try each of the three paths one by one, don't get the order confusing

First, the main road: call number 10000. The script is crucial. Don't say "I want to change the bridge"—customer service will mostly reply, "The optical modem does not support self-modification." For example, "I bought a router myself and need the optical modem to switch to bridge with dialing from the router. Please send the bridge configuration on the ITMS side." In the installer's backend, there's a template called "User Own Router." Select it, and the template that will be pushed to your home will be the bridge. Changing the bridge won't be pushed back, but will actually be protected. That's how I did it the second time, and for the next three months, I wasn't pushed even once. Free of charge, from call to action takes about ten minutes.

Second, half-hearted route: delete the TR-069 connection. You have to go to the Super Administrator backend. How do you get Super Secret? see this . Connect to the network → WAN, find the service type TR-069, delete or disable it, and from then on, ITMS won't find your cat—the world is peaceful. But the cost is to know in advance: Xiaoyi Butler's App remote function is useless, and later you can't check the remote repair or maintenance system remotely, so you have to arrange an appointment at your door; What's even more troublesome is that some provinces detect TR-069 long-term missing contact and immediately issue a reset command. When you wake up and return to factory condition, you have to redo the process of restoring the factory rescue . Before deleting, be sure to back up the configuration file: save → system → configuration management and export the conf file and store it properly.

Third method: Change the ITMS server address. Change the ACS address in the TR-069 connection to an invalid IP, such as 192.168.255.254, so that the "report" never fails. I tried it on the HS8145V5 and it lasted three months without issue; My friend's F7015T was brought back after two weeks. The model and firmware differ too much and don't maintain durability. If the first two don't work, try this again.

firmware automatically upgrades, this matter should be viewed in two halves

firmware push is even more brutal than configuration push. During the upgrade process, the optical modem should restart for five to ten minutes, and the whole family will be disconnected; After upgrading some custom configurations, they will be reset. I've encountered a modified LAN segment being restored back to 192.168.1.1. In the settings → System Management → firmware upgrade, some models have an automatic upgrade switch. TEWA-750G has it, but my version HS8145V5 doesn't. If it does, turn it off. If you don't have a switch, don't force it. The unified push in the area is done in batches and one-time; once it's over, things settle down.

to be fair, upgrading isn't always a bad thing. After upgrading the firmware on my old F7015T, the old 2.4G disconnection problem was actually fixed. So don't delete TR-069 right after upgrading just to avoid it. First, think about whether you still want features like remote management and one-click fault reporting in Xiaoyi Butler. If you delete them, they're all gone.

which settings will be pushed back, and which won't

After being pushed a few times,

paid attention, jotted down the changed settings one by one, and observed them for over a month. The general pattern is as follows (our template is for reference only):

Wrap up with an order: first check the logs to confirm it's been pushed, not the wiring or router's fault; Then enter number 10000 to exchange for the "user-provided router" template, which is the only legitimate route that doesn't harm functionality; If that doesn't work, back up the configuration files before running TR-069; After deleting Xiao Yi Butler, he pretended it never happened. Before switching to bridging, remember to take a screenshot of the entire WAN connection table, especially the VLAN values from the IPTV line. If you get pushed back, just follow the screenshot and recover in ten minutes, so you won't get confused.