TrendChip firmware (ZTE-H108NS): Build custom software – add namecheap DDNS support

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?
Petrified - Tinos. Photo by Christos AndronisPhoto by Christos Andronis.

Building software for TrendChip firmware

Generally there are two ways to build software for a foreign architecture.

  1. Cross compile (in the host machine)
  2. 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.

  1. NFS
  2. SAMBA (private samba server runs by qemu with -smb option)
  3. 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.

Author: vasvir

Interested in a wide range of topics from deep learning and big-data to embedded, from web GUI (GWT) to API and code consolidation. Maintainance is also fun for me unlike many other normal people...

24 thoughts on “TrendChip firmware (ZTE-H108NS): Build custom software – add namecheap DDNS support”

  1. 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

    Like

    1. 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

      1. loose all my customizations
      2. loose time trying to fight over this thing

      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.

      Like

  2. 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.

    Like

  3. 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”

    Like

  4. 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.

    Like

  5. 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.

    Like

  6. 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

    Like

  7. 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…

    Like

  8. 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.

    Like

  9. 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

    Like

  10. 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.

    Like

    1. 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!

      Like

  11. 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

    Like

  12. 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.

    Like

    1. 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

      www.mystartup.com:

      -Go to DNS entriess of your modem and add the dns entry

      www.mystartup.com --> 192.168.1.15

      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.

      www.mystartup.com:80 --> 192.168.1.15:80
      www.mystartup.com:22 --> 192.168.1.222:22

      You will need to have then in your modem’s DNS entries

      www.mystartup.com:80 --> 192.168.1.15:80
      ssh.mystartup.com:22 --> 192.168.1.222:22
      

      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

      Like

      1. 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

        Like

  13. 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.

    Like

  14. 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

    Like

Leave a comment