That shows there's only one mtd partition, containing the root filesystem, so the config must be stored and accessible some other way, but I don't know what that is.

It's not essential to investigate further and work out how to extract the unencrypted config using the shell, but it is useful, because then you can edit that config, so if you need to reset the device the factory defaults, you can restore something besides a blank config to re-enable the shell access.

Works and looks 100% OK and does not seem to have any impact on the info shown in the gui in spite of the duff info. The config bin file is attached as vanilla config.zip. I am rather ignorant of what actual impact if any no UPnP might have, I do use file and printer sharing so it might not be good for me?

When I tried the duff info on its own with the usual telnet line it did not accept it.

On its own also worked but had the expected harmless gui impact. the config .bin file is attached as just telnet.zip This would be my personal favorite as apart from the odd gui info it does not look to change more than it needs

Sorry to butt in here guys. I'm trying to follow what you are doing and decided to have a poke around myself. Sorry if Im diverting the subject as much of what you guys are doing is over my heads but a couple of points on the serial number that I noticed:

I couldn't seem to find the S/N in my webGUI. No matter I thought as its on the bottom of the modem and in the expected 215xxx range.

Using statPOSTer-test2.jar out of curiosity I attempted to decrypt one of my config files. Its not very clean, but I can make out enough to see that the Serial Number in there, isnt the 215xxx number that's on the bottom of my modem.

I may be corrected but we not seeking to input any such info now. In fact when such info was input it seemed to be ignored hence my vanilla version above. I think the decrypt needs a near factory reset file.

The bin file in "just telnet.zip" in a post above only has the added lines

This makes the gui have an odd device description but that is harmless and at least reminds you of what you have done. The vanilla version does not show that oddity but from ejs past posts it may have stopped UPnp being started. I have not checked on that.

I would try that "just telnet.bin" settings file if you want to see the result with the minimum bother.

I hope ejs or kitzuser87430 will give concluding advice when we have all stopped messing about.

edit I started mine connected about an hour ago and will try it for a day or two. It is uploading to MDWS but I gave the line a heavy speed cap which I will relax a bit later if the errors from the TPlink prove low enough.

The decrypted file is still compressed, which is why it is mostly unintelligible. It starts off fairly readable, but rapidly becomes less readable, presumably due to how the compression algorithm builds up some dictionary or tree as it processes the input. Unique data might still be readable later in the file, if it didn't compress.

One of the original uses for the StatPOSTer program is to view settings, so everything that could go between the DeviceInfo tags in the config file can be viewed using the settings panel. Select IGD_DEV_INFO from the list in the Object box, and press the "Get value" button.

Using the shell, it should be possible to start the upnpd process, but there's probably a severe restriction on the length of the command line you can type in, so you would need to create a script or work around that limitation somehow.

Another limitation, if it's the same as older models, is that the telnetd process only allows one login at a time, so if you want more than one shell login, e.g. one to collect stats and another to generally look around, use the first shell to start another telnetd process on a different port.

It might be possible to get the same config file trick working with the VR900, although I think I'll need to add a further option to the program because the MIPS CPUs in the older models and the 9970 are big endian, but the ARM CPU in the VR900 is little endian.

I have been messing about....sorry experimenting part of the day trying to get another telnet daemon on port 1024, many config.bin files are accepted by the GUI, but I have found the following problems

1) You cannot change the LAN subnet2)You cannot restore the downloaded config (after changing some settings and backing up)3) You have NO telnet on port 1023.

I have not been able to find a solution where you can make the "telnetd" part of the description hidden and have no side effects.

I am not running the vanilla config at the moment but when I did I thought I did change the LAN subnet. I "think" I found that you needed to set up the connection first - without a sync though- and also not get muddled between the NETWORK-LAN and the DHCP tabs which seem to me to overlap apart from the ability to change modem IP only in NETWORK-LAN. Re the 'think' --- it is possible that I am in fact recalling what I did with your version. After a couple of hours trying many different things you can loose track!!!

I do however agree that the vanilla version along with other tries so far at hiding the change are best avoided.

Thanks to les-70, ejs and kitzuser87430, I have managed to hack my TP-Link W9970 and get the DSL stats program working. I uploaded the config 'just telnet.bin' and after the router had restarted, I set-up the rest of the configuration on the router as I had it previously. All of my configuration changes seemed to work fine.

1. The just telnet file seems to work fine, but when I try to run it through the StatPOSTer 2 or 3 program, even without making any changes in the xml file, the router rejects the file. (It WAS set to the 9970) Is the program broken, or am I doing something wrong?

2. Is the new telnet port accessible from outside the LAN (given it uses default username/password, it would be preferable if it isn't with the access it has to the shell). If yes, how do we secure it? I couldn't seem to figure out how to change the password for the new telnet either.

3. What's the root password?

4. I tried adjusting the SNR margin, but every change I tried resulted in no difference in my current connection rate (some change in the SNR Margin and max rate, so it was doing something). Is my ISP only allowing that fixed rate, or does the chipset not allow the SNR margin to be changed regardless of what cli commands are available? Has anyone with this modem tried adjusting it and had success? For reference, we're getting 4mb with an SNR margin often around 12.

1. I'm not sure what you were doing wrong. I managed to re-create the .xml file that would have been used to create the "just telnet.bin" file, and verified that the StatPOSTer program produced the identical .bin file to the one uploaded. The .bin files cannot be usefully decrypted for this model (it's not the encryption that's the problem, it's the TP-Link home made compression routine that not implemented, although it would be trivial to remove the fake compression padding bytes that StatPOSTer adds). Anyway, I've uploaded the .xml file and another xml and bin file with the default description plus telnet.

2. Don't know, you'd have to check it yourself with an online port checker, and check the firewall config with the iptables or ip6tables commands.

3. admin/1234 is the root user/pass. The root username is admin.

It's possible to change the login password, but it's somewhat inconvenient in that you need to generate the salted, hashed password and write out the new passwd file manually. Something like this would need to be done each time the device is rebooted (I use an expect script to automate doing various things on my 8970 running 9980 firmware):

echo 'admin:$1$salt$encrypted:0:0:root:/:/bin/sh' > /var/passwd.newecho 'nobody:*:0:0:nobody:/:/bin/sh' >> /var/passwd.newcp /var/passwd.new /var/passwd ; rm /var/passwd.newOn a Linux system, the necessary line for the passwd file can be generated using the chpasswd program set for md5 and operating on a different root directory instead of changing the system's /etc/passwd file.