This is the third article in a series of articles documenting the reverse engineering of the TrendChip firmware image and the disassembly of its CRC checksum algorithm.
In this installment we will see how it is possible to create custom software that will run on your modem router. The task at hand is to modify the ez-ipupdate software so it can handle namecheap’s DDNS protocol. Let’s see first how we can build custom software (hello_world.c – How original!), and then we will take a look at the namecheap’s DDNS protocol and finally we will modify the ez-ipupdate. Sounds like a plan, isn’t it?
What could possibly go wrong?
Photo by Christos Andronis.
Building software for TrendChip firmware
Generally there are two ways to build software for a foreign architecture.
- Cross compile (in the host machine)
- Build in place (in the target machine)
Cross compiling means that after setting the cross compiler we will need to cross compile the target system’s libc. In this case the target’s libc is uClibc version 0.9.30. Debian’s support for cross architectures reaches its limit in this one. There is a package named gcc-mips-linux-gnu that provides MIPS compiler with GNU libc (glibc). So I assume there is room for fame and glory for somebody to provide gcc-mips-linux-uclibc packages for Debian. I am father of two,the time is limited, the clock is ticking and surprisingly I don’t feel the urge to do the famous 3 stage bootstrap of gcc. Maybe it’s just me getting older.
What about the other option – building in place?
The problem in the second option is that the modem is not equipped neither with a compiler nor the development headers of a libc. The space required for this machinery is very big compared with the 23M that the uncompressed squashfs has.
So what’s left? Google I suppose and lo and behold – I found it. The uClibc project builds system images for all uClibc versions. You can boot the system image with qemu like this
system-image-mips$ ./run-emulator.sh Linux version 2.6.25.10 (landley@driftwood) (libc/sysdeps/linux/mips/crt1.S:(.text+0x1c): undefined reference to `main') #1 SMP Sun Nov 23 06:55:47 CST 2008 LINUX started... Overriding previous set SMP ops console [early0] enabled CPU revision is: 00019300 (MIPS 24K) FPU revision is: 00739300 registering PCI controller with io_map_base unset Determined physical RAM map: memory: 00001000 @ 00000000 (reserved) memory: 000ef000 @ 00001000 (ROM data) memory: 0025a000 @ 000f0000 (reserved) memory: 07cb5000 @ 0034a000 (usable) Wasting 26944 bytes for tracking 842 unused pages Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 32767 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 32767 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/hda console=ttyS0 rw init=/usr/bin/qemu-setup.sh panic=1 PATH=/usr/bin Primary instruction cache 2kB, VIPT, 2-way, linesize 16 bytes. Primary data cache 2kB, 2-way, VIPT, no aliases, linesize 16 bytes Synthesized clear page handler (26 instructions). Synthesized copy page handler (46 instructions). Cache parity protection disabled PID hash table entries: 512 (order: 9, 2048 bytes) CPU frequency 200.00 MHz Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 126396k/127700k available (1843k kernel code, 1140k reserved, 263k data, 136k init, 0k highmem) Mount-cache hash table entries: 512 Trying to install interrupt handler for IRQ16 Trying to install interrupt handler for IRQ17 Brought up 1 CPUs net_namespace: 160 bytes NET: Registered protocol family 16 pci 0000:00:0a.3: quirk: region 1100-110f claimed by PIIX4 SMB NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 3, 32768 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered io scheduler noop registered (default) rtc: SRM (post-2000) epoch (2000) detected Real Time Clock Driver v1.12ac Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250.2: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A console handover: boot [early0] -> real [ttyS0] serial8250.2: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A loop: module loaded pcnet32.c:v1.34 14.Aug.2007 tsbogend@alpha.franken.de PCI: Enabling device 0000:00:0b.0 (0000 -> 0003) pcnet32: PCnet/PCI II 79C970A at 0x1020, 52:54:00:12:34:56 assigned IRQ 10. eth0: registered as PCnet/PCI II 79C970A pcnet32: 1 cards_found. Uniform Multi-Platform E-IDE driver ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hda: QEMU HARDDISK, ATA DISK drive hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 512KiB hda: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=4161/255/63 hda: cache flushes supported hda: unknown partition table TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing prom memory: 956k freed Freeing unused kernel memory: 136k freed eth0: link up Type exit when done. / #
The system image provides gcc-4.1.2 while the binaries in the modem are built with gcc-3.4.6 (at least the kernel). Let’s hope that the backward compatibility would be good enough in order to build things in the system-image and then copy them in the squashfs filesystem of the modem.
FileSystem woes
Before we continue we need to adjust the environment to our development cycle. The uclibc provided system image is 64MB (around 50MB root filesystem). It has vi and gcc and make but nothing more. It would be nice if we could mount some host’s exported directories in order to:
- have available more space for the software builds
- use host based editors and file managers
The combination of qemu and linux provides 3 ways to mount host’s provided directories. For more information and the gory details check this article by Rob Landley and Mark Miller especially this part.
- NFS
- SAMBA (private samba server runs by qemu with -smb option)
- FAT image
Any of them should work in theory but you should know the drill by now. It took me two weeks to accept the bitter truth of failure. The reason of the failure was that the uclibc provided kernel has no support for modules and no support for NFS, SMB and FAT filesystems. It took me a week and several network dumps from wireshark to figure out that the dreaded 111 mount returned error means the kernel has no support for NFS. It took me one more week to accept the fact that I can’t build a kernel for MIPS because:
- buildroot of the time fails when it’s trying to build the kernel in a modern system
- cross compiling a MIPS kernel on a recent Debian gives many errors on older kernels and a fatal one in the latest. In any case I cannot find the zImage target in the generated Makefiles.
So what is left? I resized the rootfs image to 2GB and mount it with the loop device. Of course concurrent access via the host and the emulated guest is not allowed so you have to be careful and run qemu / mount / unmount / run qemu again all the time.
Here is how to resize a filesystem image:
#dd if=/dev/zero of=disk.img bs=1M count=1024 oflag=append conv=notrunc #e2fsck -f disk.img #resize2fs disk.img
and here is how to mount / unmount between qemu invocations
#mount -o loop ./uclibc/0.9.30/system-image-mips/image-mips.ext2 /mnt/ #umount ./uclibc/0.9.30/system-image-mips/image-mips.ext2
ez-ipupdate invocation
The first step is to establish the beachhead. We make sure that hello world works. Indeed although the compiler is different – compiling in the guest system is good enough for the hello world to run in the modem just by copying the executable around (and rebuilding the firmware with tcrevenge).
The ez-ipupdate is free software hosted on sourceforge. It is written in C so in theory a modification like this is relatively easy. The namecheap’s DDNS protocol is not exactly rocket science to get right. So let’s see what the TrendChip firmware is doing and how it invokes the ez-ipupdate.
There is the file /etc/ddns.conf which looks like a direct dump of what is stored in the XML romfile. Probably cfg_manager dumps it in that form so subsequent scripts can operate on this data more easily.
# cat /etc/ddns.conf Active="Yes" SERVERNAME="www.dyndns.org" MYHOST="myhost.mydomain.noip" USERNAME="username" # It is literally username as it not prefixed with my (as in myusername) PASSWORD="mypassword" WILDCARD="No"
Then there is /etc/ipupdate.conf
# cat /etc/ipupdate.conf user=username:mypassword host=myhost.mydomain.noip service-type=dyndns max-interval=2073600
which is what will be feed to the ez-ipupdate executable.
There are two scripts. The usr/script/ddns.sh converts the /etc/ddns.conf to the /etc/ipupdate.conf. The other one (/usr/scripts/ddns_run.sh) runs the ez-ipupdate with the /etc/ipupdate.conf as configuration parameter.
Namecheap’s DDNS protocol
It’s not really a protocol. It’s a http GET with certain parameters to the namecheap’s server. Here is how you can update your PC’s DNS manually with curl.
$curl https://dynamicdns.park-your-domain.com/update?host=myhost&domain=mydomain.com&password=mypassword&ip=myip
The only tricky part left is to parse the variables in the configuration file and assemble the GET request.
Finally: Compiling custom software – ez-ipupdate
The following patch implements namecheap support at expense of dyndns support. The potential users of this hack must use the configuration entries of the WEB GUI to fill the proper information in the dyndns section. The TrendChip firmware will use the hostname and password but it will connect to the namecheap’s servers instead.
diff -ur ez-ipupdate-3.0.11b7.orig/ez-ipupdate.c ez-ipupdate-3.0.11b7/ez-ipupdate.c --- ez-ipupdate-3.0.11b7.orig/ez-ipupdate.c 2002-03-12 01:31:47.000000000 +0200 +++ ez-ipupdate-3.0.11b7/ez-ipupdate.c 2015-03-01 20:35:57.981976162 +0200 @@ -56,9 +56,9 @@ #define DHS_REQUEST "/nic/hosts" #define DHS_SUCKY_TIMEOUT 60 -#define DYNDNS_DEFAULT_SERVER "members.dyndns.org" +#define DYNDNS_DEFAULT_SERVER "dynamicdns.park-your-domain.com" #define DYNDNS_DEFAULT_PORT "80" -#define DYNDNS_REQUEST "/nic/update" +#define DYNDNS_REQUEST "/update" #define DYNDNS_STAT_REQUEST "/nic/update" #define DYNDNS_MAX_INTERVAL (25*24*3600) @@ -1919,11 +1919,20 @@ output(buf); } - snprintf(buf, BUFFER_SIZE, "%s=%s&", "hostname", host); + char *dot = strchr(host, '.'); + *dot = 0; + char *domain = dot + 1; + + snprintf(buf, BUFFER_SIZE, "%s=%s&", "host", host); + output(buf); + snprintf(buf, BUFFER_SIZE, "%s=%s&", "domain", domain); + output(buf); + snprintf(buf, BUFFER_SIZE, "%s=%s&", "password", password); output(buf); + if(address != NULL)
One more note: The size of the final ez-update was 122624 bytes while the original was only 84720 bytes. Could it be the compiler? I tried with -Os and stripped all symbols. My guess for this sudden file increase is that ez-ipupdate has support for many DDNS protocols that are not listed in the web GUI of the Trendchip firmware. It is possible therefore that they had stripped the support of the missing protocols from the ez-ipupdate in order to save space.
After patching and moving the ez-ipupdate sources to the guest system the usual procedure of
$./configure $make
can be used to build the software for MIPS. Copy the resulting executable to the expanded squashfs, create squashfs image, rebuild the firmware and upload it to the modem and you are ready.
Hope it was fun. Now off you go to build minidlna in order to enable streaming from your modem router.
Mporeis na anevaseis firmware gia afto to router opou tha einai anoixto to telnet, xwris ta skoupidia tou ote, kai na to dexete to routeraki? (xmm i zitaw polla?) – prospathisa na akoulisw tis odigies sou (me allagi gia to telnet) alla to apotelesma einai “Illegal file”. Isws mporoume na epikinonisoume kapws?
Eyxaristw
LikeLike
Hi,
In my modem telnet is open (version 108NSV1.0.7m_ZRD_GR2_A68). A user that commented on this blog said that 1.17 has closed the telnet access which I find pretty lame. I don’t want to upgrade and
In any case I wouldn’t distribute a firmware image with the limited time I spend and the small amount of personal tests that I have done. That would be irresponsible.
Instead I am documenting my efforts so if anybody wants to try to brick his modem he at least must have a basic understanding.
LikeLike
I understand that the process might brick my modem, though Im still trying…4 days and counting.. Anyway, in the latest firmware they give out they have telnet closed, which indeed IS lame. also they have a new “feature” that doesnt allow firmware downgrade, thats where my firmware falls/fails i guess.
Here is some info of what i have so far, so i might get some help:
Original bin(h108ns/pstn/ote) tcrevenge output:
Manual check (binwalk): header size must be 256 (0x0100)
Magic number: 0x32524448 found 0x32524448 …ok
Magic device: 0x00000100 found 0x00000100 …ok
tclinux.bin size: 6571355 found 6571355 …ok
tclinux.bin chekcsum: 0xFF0FC158 found 0xFF0FC158 …ok
Firmware version: 7.0.1.0
Manual check (binwalk): squashfs offset must be at 0x000E955B
Manual check (mtd partition dump): squashfs size (padded to erase_size at 4K (0x1000)) must be at 5615616 (0x0055B000)
Manual check (all tests have been done with model 3) Model: 3 6035 122 89
My bin tcrevenge output:
Manual check (binwalk): header size must be 256 (0x0100)
Magic number: 0x32524448 found 0x32524448 …ok
Magic device: 0x00000100 found 0x00000100 …ok
tclinux.bin size: 6571355 found 6571355 …ok
tclinux.bin chekcsum: 0xCFD935FC found 0xCFD935FC …ok
Firmware version: 7.0.1.0
Manual check (binwalk): squashfs offset must be at 0x000E955B
Manual check (mtd partition dump): squashfs size (padded to erase_size at 4K (0x1000)) must be at 5615616 (0x0055B000)
Manual check (all tests have been done with model 3) Model: 3 6035 122 74
The only difference i see is at the very last part of the output (89 / 74).
Also there is a 0.64kb filesize difference but I dont think it matters.
Tried to edit the header file to show a higher firmware version, and failed again, got the “illegal file” reply as always.
Would love to try your firmware if you are kind enough to share it, and be sure I wont blame you for any loss. Many people need the firmware that has all the functions restored, so you could always release it.
Still have some hope to get your firmware, but even if i dont, thanks for sharing the knowledge and the tools.
LikeLike
Forgot to mention that even if the original bin gets unpacked and repacked gets that last bit changed (89 / 74) without modifying it, and spits “illegal file”
LikeLike
Oups…
The model 3 6035 122 74 number is hardwired in tcrevenge around line 12. Sorry for that but I played with only with one firmware version and I didn’t know what this thing was for. At least I put a manual check reminder there…
The correct fix is to make it a variable that you can set by command line. Pull requests are always welcome.
Now looks like Firmware version: 7.0.1.0 which is also hardwired are irrelevant because my version also lists 7.0.10
If you are totally lucky the actual version information is stored in the model variable and that’s why it jumped from 74 (my version, hardwired) to 89. I don’t what the actual numbers mean and how they map to 1.07 and 1.17 respectively but it worths a try.
About the size difference: I don’t want to scare you and I am not sure what exactly you have tried or not. But a general note would read:
Do not underestimate size differences. You have to understand exactly what is going on and account for every byte of difference. tcvrevenge will calculate the CRC and will print some info but you still have to understand what’s going on with the squashfs, offsets, paddings and sizes.
LikeLike
The difference in size i guess is by removing their stuff and adding my modifications, i wouldn’t be scared of that(much). The info you provided is actually useful and i will check your source. If everything works out nice i will let you know, else consider it (my router) another brick in the wall.
State of mind:
On MY devices I will either have full access over them and what they do, or they are better bricked.
LikeLike
UPDATE:
Fast eh? IT WORKS!!!!!
With your setting (cmd7) for the snr it locks at 20.5 mbp/s for me, though it disconnects every minute. I need to try and find the best setting for my line.
My plans for now:
1) Find which file sets the telnet support. (inet.conf didnt actually work for that, though after a port scan it reveals that i opened ssh and closed ftp (from this file as a test) – ssh doesnt connect, still need to find the correct settings and files)
2) Kick OTE out of my router/network.
If you have any suggestions please tell 🙂
What i did and it worked:
In tcrevenge.c
line 11 manually added a firmware version (set it at 7.1.8.0\n, but 7.1.7.0 would work too i guess)
and line 12 changed “74” to “89” to match my device/version/model or whatever that is.
I actually call it a success, now i have one problem less.
THANK YOU for the guide and the revenge-tool
ps. i dont know much C so i could fork your tool
LikeLike
Good to hear. Congrats…
Some suggestions.
0) I don’t believe it has a ssh daemon – but if you find otherwise please let us know.
1) Does it have a telnet daemon? I can’t check in mine right now. It should have one.
2) I would download the older firmware version 1.0.7 that has open telnet unpack and diff -ur tclinux.bin-squashfs-1.0.7 tclinux.bin-squashfs-1.1.7 and scan for differences.
About tr-69
0) Change tr69 passwords. This can be done from the WEB GUI. This will work and your ISP provider will be unable to access your modem and your network. Unless you have reasons to believe that the tr69 binary is rigged and has back-doors for the ISP to pass through.
1) you could try find and rename the tr69 daemon to let’s say tr69.orig. This may cause problems if the master binary cfg_manager tries continuously to invoke it.
2) Create an empty executable tr69 with the unix hashbang #!/bin/sh. This will make the executable tr69 to show in the filesystem but if the cfg manager checks regularly on tr69 or is opening ports to check then you are going to still have a problem
Be careful the admin password is used in a lot of places in the romfile and once I almost bricked the device when I tried to perform an overoptimistic global search and replace change.
In any case please post your results…
LikeLike
Good day,
0) In usr/etc/inetd.conf has support for ssh, and a link to /bin/sshd – but the deamon has been removed by OTE
1) In the same file has the suport for telnet, and links to /bin/telnetd – BUT they have renamed the daemon to “utelnet” (So i just edited that line and linked telnet daemon to “utelnet” – IT WORKS better than expected 😀 sadly it doesnt have a text editor to make my life easier in there and i have to use multiple commands to edit files from console- maybe if i figure out how much space is left in its flash i could throw a nano or vi for mips in /bin)
2) When you have some time download their firmware to check what they have done, you will be (negatively) amazed.
What else i have changed:
Your change in the romfile.cfg: “wan dmt2 set snrmoffset 4096 4096” didnt work well for me, so i played around with this command in the now opened telnet, with the command as it is it “locks” at around 20Mbps, but dc’s every minute (gets snr -4). Also tried wan dmt2 set snrmoffset 8192 8192 (for fun) and got the modem to lock at 23999(!!!!!!!!) with snr around -8. Finally used wan dmt2 set snrmoffset 2500 2500 and lock at 19.8Mbp/s stable, with snr 3 to 3.5, but i still have to play around with those numbers to get out more if i can.
In the file profile.cfg i commended out everything that has the word “OTE”, “CWMP” and “TR06”. Amazingly enough I didnt brick the router. YET.
In usr/script there are multiple files that have the lines “if TCSUPPORT_OTE_whatever /usr/bin/killall utelnetd” – so if can actually get a workaround to make telnet work, it runs the checks and kills the daemon. Commenting out everything that has the word “OTE” in profile.cfg seems to work, because the shell scripts it runs on boot return false and it doesnt kill the daemon.
Made also some changes in some boaroot/cgi-bin asp files (not the .cgi ones) and edited some of their javascript to unlock some things they had locked in the webinterface (example: before i couldnt save the CWMP form, becouse the javascript check for the form returned false even if it was true (plase check the new firmware files to see what i mean, but for the love of god DO NOT flash it)
Where am I now:
Having to do your last suggestions
Adding no-ip support for the ddns
Maybe find sshd and/or nano precompiled for mips and throw it in the /bin dir (if they are small enough, and only if i find out how much space is left)
IMO this is a great device that has been ridiculously modified by them to only connect you to the internet and have their backdoor. Yesterday i opened its “hood” and sadly found out that this device has no visible jtag or serial, so if we brick them, they are bricked for good. I blame the new FCC rules/laws for that.. (Though dunno if there is another way to de-brick if bricked) I will keep you (and your readers) updated on what else i accomplish, or if i have any news on it.
LikeLike
Forgot to mention for 2) that older firmware images are hard to find anywhere online, nearly impossible i would say. so keep a backup of your firmware in many places hehe
There are many people that search for a modified firmware for this router if you search the net, thats why i suggested you to upload your somewhere and share it with the world. Im pretty sure yours will be MUCH cleaner than mine, as mine is a test version i would say. Uh also there is a lock that prevents downgrade, so people may not be able to flash your on their router. Anyway, back to digging
LikeLike
Here is my work so far:
http://s000.tinyupload.com/?file_id=11542571328934736919
The file is 16.2 mb and it includes
The unsquashed folder of the latest OTE firmware (with the modified files)
header/kernel/squashed file/padding
Ready tclinux.bin (FOR EMULATOR USE ONLY..)
and a MUST_READ txt file, mostly being a disclaimer and warning for people
If this post is against your blog’s TOS please delete, and im sorry. Wanted to share my work with you. Do not use this firmware as we seem to have different versions/models.
Thank you for your blog, guides and most importantly your help.
Message to your visitors:
If you are not a developer you MUST read the MUST_READ.txt before doing anything stupid with the files provided. Do NOT use this firmware or you will brick your router.
Me or the tool developers cannot be held responsible for your actions, choices, any loses or damage this firmware may cause. This is NOT official release from manufacturer or ISP.
This is meant to be used in emulator only environment by developers. ONLY.
LikeLike
The link provided here does not work. Could you please uploaded again in some place else? Or send me with an email? (yyy@gmx.it)
Thanks!
LikeLike
Thank you for sharing Stav!
LikeLike
Well, you are welcome, but all the credit goes to vasvir 🙂
LikeLike
Dear Stav (& vasvir ofcourse)
Like you said i am no developer and yes i have limited knowledge as you will find out from my question that will follow, but i will try to do my best to understand and keep up with you.
i downloaded your work and i want exactly this :
“This firmware activates telnet support and kills the cwmp/tr69 daemon.”
in your H108NS-1.1.7-pstn-otexxxxxxx.7z file there is a tclinux-pwn.bin
Do i flash this like i do with every bin Firmware file from my router update setting??
will this be enought? or i have to rename the 7z file to bin to flash?
Might be a lame question but i told you..
And i also agree with the Free them Or brick them.
If this looks like spaming a great tutorial will you be kind enought to contact me with in any other way you wish to help me.(email,fb etc)
Thank you in advance
Panos
LikeLike
Dear all, I’ve managed to upload the souped up firmware on my router with success. Now the telnet is up again. Another crucial feature that is not available on this router is “NAT Loopback”. So, I tried to telnet the following commands to enable it. The goal is to reach my webserver (that is running on 192.168.15:8080) from the intranet using the external IP:
iptables -t nat -A PREROUTING -d -m tcp -p tcp –dport 8080 -j DNAT –to-destination 192.168.1.15:8080
and then:
iptables -t nat -A POSTROUTING -j MASQUERADE
I noticed strange behavior though. When connecting via Ethernet it works ok, but when connecting via a wireless device (e.g. mobile phone, PC connected to router by wifi) it doesn’t.
I think it’s a nice feature to add so if you can understand why this happens let me know.
LikeLike
Hi Kostas,
I am not a networking expert but the NAT lookup looks like a Linux thingy. Other TCP/IP stacks may have it enabled by default.
While I was researching the issue AFAIR was a per port setting. Your iptables command line seems to confirm that. That means it is not a one time off command. You have to repeat it for every port.
So I gave up on that particular fight. Here is the workaround if you have a Dynamic DNS entry. Let’s say
-Go to DNS entriess of your modem and add the dns entry
Now you don’t need NAT lookup in order to access your server from your LAN.
Caveat: The above scheme works if you have one server in your internal LAN however it fails if you have multiport redirection i.e.
You will need to have then in your modem’s DNS entries
where ssh is an alias of www in your external DDNS entries. It’s a double setup – not the nicest in earth but it works great for one server and with some maintenance burden if you have more than one.
Hope that helps.
Vassilis
LikeLike
Hi Vassilis. I happen not to be an expert either but it seems you have the networking expertise anyway. I assume that by “Dynamic DNS entry” you mean a service like dyndns or no-ip but what is still unclear to me is how to set this dns entry on my H108NS modem/router -> Do you mean by editing the /etc/hosts file of H108NS via telnet? I’ve already done this with no success:
http://www.mystartup.com 192.168.1.15:8080
If you mean that I have to edit another file please let me know. I’m struggling more than 3 days with it and you seem to have already solved it!
Regards
K
LikeLike
Hi Kostas,
Yes when I am saying Dynamic DNS I refer to dyndns, or no-ip etc. You need one of these so you can access your server from the WAN. Otherwise you will need to know the exact dynamic ip of your modem every time you need to access your server.
Inside your LAN your modem runs dnsmasq. That means it acts as a DHCP server and a caching DNS server. Usually the modem’s DNS server just caches your ISP DNS replies. However it is possible to override the normal behavior for some entries. This can be done from the modem GUI. Unfortunately I don’t have access to the modem right now and I cannot guide you exactly.
No need to fiddle with /etc/hosts
Hope that helps.
LikeLike
Hi to all and Merry Christmas!!!
Is it possible to upload again the “fixed” version of the firmware without the OTE’s bloatware settings?
The link above isn’t working anymore…
I can upload it to my EasyBytez account (and post here the link) that it can’t be deleted (since i have premium account there) if it downloaded at least one time in 240 days…
Thanks,
Dimitris
LikeLike
Hi Dimitris,
I don’t provide ready made firmware and I certainly don’t redistribute original firmware.
You may want to look at https://vasvir.wordpress.com/2017/01/28/trendchip-firmware-zte-h108ns-derived-works/ in case you find there what you are looking for.
LikeLike