Orbi WiFi 7 RBE973
Reply

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

antinode
Guru

DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

   Model:  DGN2200v4
   Serial: 39V13C7106B0A

Hardware Version        DGN2200v4
Firmware Version        V1.0.0.86_1.0.86
GUI Language Version    V1.0.0.74_2.1.17.5

   I recently updated the firmware of this device, as advised, from
DGN2200v4-V1.0.0.66_1.0.66 to V1.0.0.86_1.0.86.  With this new firmware,
I experience a problem with the Web interface:

   "ADVANCED > Administration > Router Status" causes the Web interface
to stop communicating, apparently forever.  The modem/router functions
continue, apparently unaffected, but the Web interface is dead.

   "ping <router_LAN_address>" works, but Telnet to port 80 returns a
"Connection refused" error.  Normal:

pro3$ telnet dsl 80
Trying 10.0.0.1...
Connected to gw.antinode.info.
Escape character is '^]'.
Connection closed by foreign host.

   After "ADVANCED > Administration > Router Status":

pro3$ telnet dsl 80
Trying 10.0.0.1...
telnet: connect to address 10.0.0.1: Connection refused
telnet: Unable to connect to remote host


   My spare DGN200v4 (Serial: 39V13577035AB) is still at:

Hardware Version        DGN2200v4
Firmware Version        V1.0.0.66_1.0.66
GUI Language Version    V1.0.0.66_2.1.17.5

and, as expected, it seems to have no trouble with "ADVANCED >
Administration > Router Status".

   So far, I have not found any other fatal controls in the
V1.0.0.86_1.0.86 Web interface, but one such problem is enough.  The
only way I've found to recover normal operation is to cycle the power on
the device, which can be very inconvenient.  (Obviously, after it stops
communicating, the Web interface is useless for this.)

   As always, I appreciate your help, and await your suggestions.


Possibly related:
https://community.netgear.com/t5/x/x/m-p/1308780#M17874

Message 1 of 11

Accepted Solutions
antinode
Guru

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

> [...]  I'll probably leave the
> determination of what makes the "ADVANCED > Administration > Router
> Status" control fatal to the Web server to someone else.

   Wrong again, at least partly.

   Today's speculation: Stopping httpd is a (less than perfect) defense
mechanism.

   According to Netgear, multiple (other) Netgear routers have suffered
from a particular vulnerability which exploits a flaw in the router's
Web interface.

      https://kb.netgear.com/000036386/CVE-2016-582384

   One suggested defense against this exploit is to disable the Web
server (httpd).

      http://www.kb.cert.org/vuls/id/582384
      (Look for "Disable web server".)


   Exactly how more modern firmware defeats this exploit may not have
been revealed, but it's interesting to note that an attempt to test for
this vulnerability on the DGN2200v4 also stops the httpd process.  For
example:

      http://<router_LAN_address>/cgi-bin/;echo$IFS'fred'

   Perhaps this was intentional.  A little more experimentation suggests
that requesting any nonexistent Web page will cause httpd to quit.  For
example:

      http://<router_LAN_address>/fred.htm

  If so, then any attempt to access a nonexistent Web page (including
those "cgi-bin" exploits) will close the door on any successive attempts
by stopping the httpd process.  This is a clever scheme, so long as the
normal Web pages don't contain any unintended bad links.

   Interestingly, the troublesome "Router Status" control seems to be a
link to "ADV_home.htm", and that file seems to be missing from the
"/www/" directory.  For comparison, another nearby control, "Attached
Devices", is a link to "DEV_redirect.htm", and that file does exist in
the "/www/" directory, and that control works properly.

   Moreover, on a device with the older V1.0.0.66_1.0.66 firmware, the
"Router Status" control is also a link to "ADV_home.htm", but there that
file exists (and the control works as expected).

   Firmware Version     V1.0.0.66_1.0.66

/ # ls -l /www/ADV*
-rw-r--r--    1 0        root          1380 Jul 18  2015 /www/ADV_home.htm
-rw-r--r--    1 0        root          1421 Jul 18  2015 /www/ADV_home1.htm
-rw-r--r--    1 0        root         28974 Jul 18  2015 /www/ADV_home2.htm

   Firmware Version     V1.0.0.86_1.0.86

/ # ls -l /www/ADV*
-rw-r--r--    1 0        root          1385 Apr  3 23:43 /www/ADVANCED_home.htm
-rw-r--r--    1 0        root          1426 Apr  3 23:43 /www/ADVANCED_home1.htm
-rw-r--r--    1 0        root         29210 Apr  3 23:43 /www/ADVANCED_home2.htm

 

   Changing these file names was harmless, if and only if they were
changed _everywhere_ they appeared.  Sadly:

/ # grep ADV_home /www/*
/www/start.htm:    <li class="noSub" id="adv-home"><a
 href="ADV_home.htm"><span class="nosub_text"><%55%></span></a></li>
/www/start.htm:                  <li class="SubMenu"
 id="router_status"><a href="ADV_home.htm" onClick="return false"><span
 style="border:0;" class="subMenu_text"><%91%></span></a></li>

   So, if the victim clicks on the wrong control, httpd attempts to
access a file which is missing, and then it dies.

   If you have that "telnetenable" program working, and you can access
the device's command-line interface using Telnet, then a command
sequence like the following seems to work around this problem:

      # Remount the "/" file system read-write.
      mount -o remount rw /
      # Create a symlink from the (missing) old name to the new name.
      ln -s ADVANCED_home.htm /www/ADV_home.htm
      # Reboot the device, to return "/" to a read-only mount.
      reboot

   Around here, this seems to have solved the problem.  Until the next
firmware update, at least.

   That was certainly educational.  (I hate educational.)

View solution in original post

Message 10 of 11

All Replies

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

Did you reset the router to factory settings after the firmware flash?

New firmware sometimes introduces changes that are not compatible with the old configuration.

So a factory reset is the first thing to try if you have problems with new firmware.

Backup your configuration first. Netgear does not advise restoring old settings into new firmware, but if resetting does not fix your problem, and you have complicated settings, you might want to restore them.

Message 2 of 11
antinode
Guru

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

> Did you reset the router to factory settings after the firmware flash?

   No.  I assume that if this were required, then the firmware update
instructions would have mentioned it.

> New firmware sometimes introduces changes that are not compatible with
> the old configuration.

   This device has been through at least two previous firmware updates
with no such problems.

> So a factory reset is the first thing to try if you have problems with
> new firmware.

   Before I would risk wasting that much time and effort (based on
guesswork), I'd want to hear from someone who actually has this device
with this firmware, and who does not experience the same problem.  Call
me old-fashioned.

Message 3 of 11

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?


@antinode wrote:

 Call me old-fashioned.


You are old fashioned.

 

Your call. I have suggested a strategy that has worked for some people and that, if you backup your settings, has zero risk for you.

Message 4 of 11
antinode
Guru

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

> Your call. I have suggested a strategy that has worked for some people

   You seem to have suggested a strategy which may have worked for some
people with different problems.  What I'm looking for is confirmation
that I've found a general bug (or that there is no such bug, and my
problem is specific to my device or configuration).

> and that, if you backup your settings, has zero risk for you.

   Someone recently offered the following advice here:

> [...] Netgear does not advise restoring old settings into new
> firmware, [...]

   I don't understand how potentially losing all my settings could
reasonably be described as "zero risk".

> You are old fashioned.

   Yeah.  I expect vendors who offer firmware updates for security
problems in their products to accept bug reports about such firmware
updates (without demanding to be paid for the privilege of submitting
such reports).  Actually fixing such bugs would be a nice gesture, but,
for now, I'd settle for being able to submit a complaint through a
channel which might reach someone with some knowledge of the product,
and the ability to run a simple test.  Clearly, I live in a dream world.

Message 5 of 11

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?


@antinode wrote:

> and that, if you backup your settings, has zero risk for you.

   Someone recently offered the following advice here:


That was me.

 

I leave it to others to continue this discussion.

Message 6 of 11
vinlab81
Initiate

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

I've replicated the same issue, so now we are two or maybe more.

I hope that NETGEAR solve that rapidly.

Model: DGN2200v4|N300 Wireless ADSL2+ Modem Router
Message 7 of 11
antinode
Guru

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

> I've replicated the same issue, [...]

   Thanks for the report.  You (too) must need to reset the router to
factory settings.

> I hope that NETGEAR solve that rapidly.

   A good start would be getting an actual Netgear engineer to reproduce
(or even acknowledge) the problem.  This "Community" seems to be
primarily a way to rely on volunteers (of uncertain capabilities) to
deal with simple problems, leaving the actual Netgear support people
free to handle the customers with paid support contracts.  The
volunteers get their "Community" badges, the users with actual problems
get told to reset to factory settings, and everyone is happy.

   Or, perhaps I'm wrong, and we'll soon get some helpful information
from a Netgear engineer.  I wouldn't hold my breath waiting for that
next firmware release which includes a fix, however.

Message 8 of 11
antinode
Guru

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

   For what it might be worth, I found a "telnetenable" program on the
'net, got it built on my VMS system, and used it to enable the Telnet
interface on the problem device.  Then, using the command-line
interface, I ran a "ps" command before and after the fatal action.  The
difference in the "ps" results looked like this:

alp $ gdiff ps_bef.out ps_aft.out
45d44
<   596 0         7744 S    httpd -S -E /usr/sbin/ca.pem /usr/sbin/httpsd.pem
57c56
< 13838 0         1864 R    ps
---
> 14089 0         1864 R    ps

   That is, the Web server process ("httpd") died, which would explain
the observed failure to communicate.  (The difference in the PID of the
two "ps" commands is not significant.)  I'll probably leave the
determination of what makes the "ADVANCED > Administration > Router
Status" control fatal to the Web server to someone else.

   If httpd death is not certainly impossible, then it might also make
some sense to provide a way to restart it (automatically) when it dies
this way.  Just a thought.

Message 9 of 11
antinode
Guru

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

> [...]  I'll probably leave the
> determination of what makes the "ADVANCED > Administration > Router
> Status" control fatal to the Web server to someone else.

   Wrong again, at least partly.

   Today's speculation: Stopping httpd is a (less than perfect) defense
mechanism.

   According to Netgear, multiple (other) Netgear routers have suffered
from a particular vulnerability which exploits a flaw in the router's
Web interface.

      https://kb.netgear.com/000036386/CVE-2016-582384

   One suggested defense against this exploit is to disable the Web
server (httpd).

      http://www.kb.cert.org/vuls/id/582384
      (Look for "Disable web server".)


   Exactly how more modern firmware defeats this exploit may not have
been revealed, but it's interesting to note that an attempt to test for
this vulnerability on the DGN2200v4 also stops the httpd process.  For
example:

      http://<router_LAN_address>/cgi-bin/;echo$IFS'fred'

   Perhaps this was intentional.  A little more experimentation suggests
that requesting any nonexistent Web page will cause httpd to quit.  For
example:

      http://<router_LAN_address>/fred.htm

  If so, then any attempt to access a nonexistent Web page (including
those "cgi-bin" exploits) will close the door on any successive attempts
by stopping the httpd process.  This is a clever scheme, so long as the
normal Web pages don't contain any unintended bad links.

   Interestingly, the troublesome "Router Status" control seems to be a
link to "ADV_home.htm", and that file seems to be missing from the
"/www/" directory.  For comparison, another nearby control, "Attached
Devices", is a link to "DEV_redirect.htm", and that file does exist in
the "/www/" directory, and that control works properly.

   Moreover, on a device with the older V1.0.0.66_1.0.66 firmware, the
"Router Status" control is also a link to "ADV_home.htm", but there that
file exists (and the control works as expected).

   Firmware Version     V1.0.0.66_1.0.66

/ # ls -l /www/ADV*
-rw-r--r--    1 0        root          1380 Jul 18  2015 /www/ADV_home.htm
-rw-r--r--    1 0        root          1421 Jul 18  2015 /www/ADV_home1.htm
-rw-r--r--    1 0        root         28974 Jul 18  2015 /www/ADV_home2.htm

   Firmware Version     V1.0.0.86_1.0.86

/ # ls -l /www/ADV*
-rw-r--r--    1 0        root          1385 Apr  3 23:43 /www/ADVANCED_home.htm
-rw-r--r--    1 0        root          1426 Apr  3 23:43 /www/ADVANCED_home1.htm
-rw-r--r--    1 0        root         29210 Apr  3 23:43 /www/ADVANCED_home2.htm

 

   Changing these file names was harmless, if and only if they were
changed _everywhere_ they appeared.  Sadly:

/ # grep ADV_home /www/*
/www/start.htm:    <li class="noSub" id="adv-home"><a
 href="ADV_home.htm"><span class="nosub_text"><%55%></span></a></li>
/www/start.htm:                  <li class="SubMenu"
 id="router_status"><a href="ADV_home.htm" onClick="return false"><span
 style="border:0;" class="subMenu_text"><%91%></span></a></li>

   So, if the victim clicks on the wrong control, httpd attempts to
access a file which is missing, and then it dies.

   If you have that "telnetenable" program working, and you can access
the device's command-line interface using Telnet, then a command
sequence like the following seems to work around this problem:

      # Remount the "/" file system read-write.
      mount -o remount rw /
      # Create a symlink from the (missing) old name to the new name.
      ln -s ADVANCED_home.htm /www/ADV_home.htm
      # Reboot the device, to return "/" to a read-only mount.
      reboot

   Around here, this seems to have solved the problem.  Until the next
firmware update, at least.

   That was certainly educational.  (I hate educational.)

Message 10 of 11
antinode
Guru

Re: DGN2200v4 Firmware V1.0.0.86_1.0.86 bug?

> / # ls -l /www/ADV*
> [...]

   For the record, after creating the symlink:

/ # ls -l /www/ADV*
-rw-r--r--    1 0        root          1385 Apr  3 23:43 /www/ADVANCED_home.htm
-rw-r--r--    1 0        root          1426 Apr  3 23:43 /www/ADVANCED_home1.htm
-rw-r--r--    1 0        root         29210 Apr  3 23:43 /www/ADVANCED_home2.htm
lrwxrwxrwx    1 0        root            17 Jul  1 04:16 /www/ADV_home.htm -> ADVANCED_home.htm

 

   Of course, editing the defective file ("/www/start.htm") to replace
the old file name ("ADV_home.htm") with the new one
("ADVANCED_home.htm") would be the clean solution, but, in this case,
creating the symlink seems to be effective and (relatively) simple.

Message 11 of 11
Top Contributors
Discussion stats
  • 10 replies
  • 7693 views
  • 4 kudos
  • 3 in conversation
Announcements

Orbi WiFi 7