Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: Weaver on January 12, 2019, 02:18:55 AM
-
One of my modems has been behaving oddly for a long time. I feel certain that I have unintentionally mucked up its configuration with unwise medical experiments without noticing the effects.
I cannot get it to connect with TCP, or http, with a web browser going to port 80 or 443. It just either sits there for a while before timing out and failing or fails fairly quickly. I am not sure exactly what the protocol sequence is yet as I have not yet got around to capturing a conversation.
I can however telnet to it. It works fine as a modem too.
It is successfully running the latest ‘johnson’ modified firmware, which provides a second http server (stats server) on port 8000. Connecting to the port 8000 http server works fine. I can get a time graph of SNRM, plus all the usual stats reports.
Anyway, I’m wondering about how best to recover it.
I can’t use the web UI to reload a backup config.
I tried to work out how to reload the config using the CLI. I logged in as supervisor, entered the required magic incantation, cfgupdate or whatever it is, but I get rather odd messages after it has swallowed the supplied config XML file, so I am not sure if I am somehow doing things wrong. It seems to just stop eating XML when it gets the closing element, as if it is intelligently parsing the whole thing supplied on the fly, as opposed to requiring the whole file to be delivered first, with a mechanism to define the length or provide a delimiter/terminator marker, and then looking at the content and processing it afterwards. I say this because I tried supplying various control characters after the file content was supplied into the CLI but realised that I did not need to do anything: the messages just come up after all the XML has been entered.
I’m not sure if it is even sufficient to replace the xml config anyway. If I could get it to load up a new config using the web UI, which of course I can’t, or could work out how to do the same thing with the CLI would I possibly need to do more in order to restore sanity?
So, the question: Ideally I would just completely nuke the entire thing and put a known config into it and also a known software image too just in case something went wrong with a previous software installation attempt perhaps.
* Q: What’s the easiest way of nuking it completely? (Would need some very precise clear nuking instructions to give to Mrs Weaver.)
Factory-state reset, starting up into a firmware image-loader state.
Apologies for such a basic question, but I am currently pretty incapacitated most of the time by the pain drugs that I am on. I have been unconscious for more days that not over the last week,
-
Have just tried it to make 100% certain with my 1312.
Power the device off with the switch, insert a paper clip or similar pokey implement into the reset hole to depress the switch (there is a similarly sized but protruding WPS button that could be mistaken for the reset switch) and power on, all the time holding the reset down. It will flash the main power LED red for approx 25 seconds and then go solid red. The device is now in firmware recovery mode. Simply rebooting after this will result in a settings reset, so maybe the visual confirmation of the flashing red then solid will help to ensure the process has been carried out successfully.
If the device is left in the solid red light mode then a recovery page should be accessible on 192.168.1.1, but only if the ethernet cable is connected to port 1, 2 or 3. Port 4 will not work, as I think was a problem last time you were trying to get to the recovery page. Port 4 is the left most one when looking directly at the back of the modem, closest to the RJ11 phone line in, so any of the ones right of this, closer to the power button are fine.
Accessing the recovery page, or indeed the modem after the full reset will require that nothing else on the network has the 192.168.1.1 address.
-
Just a quick addition to @johnsons instructions - I seem to remember from my 1312 that was in firmware recovery mode that DHCP does not work, so the connecting device will need to be manually set to be in the same subnet as the Zyxel to be able to connect.
May not be an issue for you @Weaver but it confused me when I was trying to connect with a standalone laptop, as I could ping the Zyxel but not connect via HTTP initially.
:)
-
@tubaman - thanks - I just assumed in the past that there will be no dhcp. (Rightly or wrongly, in fact.)
The last time I did this, I forgot to disconnect my router, a Firebrick, which was being a dhcp server, but luckily I did remember to check that the modem being set up was not being a dhcp client and picking up an unexpected address from the server. Did so by asking the Firebrick what dhcp clients it had and also looking at ARP/ND.
-
I have now learnt something from johnson's post. :)
I took my spare VMG1312-B10A and gave it a novel configuration (IPoA, different IPv4 address, etc). After performing the "power on with recessed reset button held and waiting for the power LED to show steady red" technique, followed by a power cycle, the VMG1312-B10A was (indeed) returned to its factory default configuration.