No WebUI after upgrade to 1.10.0

[rickwookie]

Just upgraded my WZR-HP-G300NH from 1.6.2 to 1.10.0 and initially I was able to connect to the WebUI on 192.168.1.1 using the default password, but then when I set the new password (back to my old one), and then went and restored my settings from my backup, the settings seem to have been applied (since the LAN has now reverted back to 192.168.11.x), but the WebUI won't start. If I scan the ports on 192.168.11.1 port 80 is not running, just ports 22, 53 and 111.

I can connect via SSH on port 22, so I was wondering how to get the WebUI running again.

If it's any help, this is what's running:

Code: Select all

root@(none):~# ps ww
  PID USER       VSZ STAT COMMAND
    1 root      1404 S    /sbin/procd
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW<  [kworker/0:0H]
    7 root         0 SW<  [khelper]
    8 root         0 SW   [kworker/u2:1]
   60 root         0 SW<  [writeback]
   61 root         0 SW<  [bioset]
   65 root         0 SW<  [kblockd]
   67 root         0 SW   [kworker/0:1]
   68 root         0 SW   [kswapd0]
   69 root         0 SW   [fsnotify_mark]
  257 root         0 SW<  [deferwq]
  258 root         0 SW   [kworker/u2:2]
  358 root         0 SWN  [jffs2_gcd_mtd5]
  418 root       888 S    /sbin/ubusd
  429 root       768 S    /sbin/askfirst /bin/ash --login
  471 root         0 SW<  [rpciod]
  495 root         0 SW<  [nfsiod]
  752 root         0 SW<  [cfg80211]
 1058 nobody    1024 S    /usr/sbin/portmap
 1079 root      1564 S    /sbin/netifd
 1121 root      1364 S    /usr/sbin/ntpd -n -l -S /usr/sbin/ntpd-hotplug -p 0.uk.pool.ntp.org -p 1.uk.pool.ntp.org -p 2.uk.pool.ntp.org
 1164 root      1140 S    /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300
 1389 root      1360 S    udhcpc -p /var/run/udhcpc-eth1.pid -s /lib/netifd/dhcp.script -f -t 0 -i eth1 -C
 1887 nobody     944 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid
 1907 tor      21368 S    tor --User tor --PidFile /var/run/tor.pid --RunAsDaemon 1 --SocksPort 0 --AvoidDiskWrites 1 --Log notice syslog --ControlPort 9051 --DataDirectory /var/tor --TransPort 192.168.11.1:9040 --DNSPort 192.168.11.1:9053 --VirtualAddrNetwork 10.192.0.0/12 --AutomapHostsOnResolve 1 --ClientOnly 1
 1964 root      1516 S    /usr/bin/ddns_gargoyle -P /etc/ddns_providers.conf -C /etc/ddns_gargoyle.conf -d
 3325 root      1368 S    /usr/sbin/crond -f -c /etc/crontabs -l 9
 3512 root      1208 R    /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300
 3513 root      1368 S    -ash
10107 root      1360 R    ps ww

EDIT: After Googling around a bit I see that OpenWRT uses uHTTPd to serve the webUI, so I just ran:

Code: Select all

/etc/init.d/uhttpd start

and the webUI not works (ports 80 and 443 both now running). If I reset the router though, uHTTPd doesn't restart. How can I get it to run on startup like it's supposed to?

EDIT2 It seems as though

Code: Select all

/etc/init.d/uhttpd enable

sorts it, so I'll leave this here in case anyone else has the same issue.

[Lantis]

You can’t restore settings from 1.6.2 to 1.10.0. I’d suggest a factory reset and set it up by hand. Who knows what else is broken behind the scenes.

The web UI not working is the easiest one to identify because we changed from httpd_gargoyle to uhttpd.

[rickwookie]

You can’t restore settings from 1.6.2 to 1.10.0. I’d suggest a factory reset and set it up by hand. Who knows what else is broken behind the scenes.

The web UI not working is the easiest one to identify because we changed from httpd_gargoyle to uhttpd.

Oh.

I thought the warning about not trying to preserve settings was in reference to using the factory.bin version as opposed to the sysupgrade.bin version. Does it mean that each major update requires all customisation to be done again by hand?

FWIW, the only other thing that I can see that's "broken" is the fact that if I ever reboot the device, the DST settings don't apply, and I have to go to the ./time.sh page and click "Save Changes". In my case, the timezone is "UTC+00:00 England", and after a reboot the "Current Date & Time" (currently in summertime) incorrectly has a GMT postfix and the time is an hour behind BST, and when I click "Save Changes" it immediately corrects this to BST postfix and has the correct time.

Everything else (Firewall, Restrictions, Portforwards, DHCP reservations, OpenVPN (I had to regenerate new certificates, but I understand this is normal?), static routes, Dynamic DNS) all work as expected.

[Lantis]

Not ALL major updates, but i'd say most.
Keeping in mind that you updated from a version released in 2014 to one in 2017, it's probably not unreasonable to think that some pretty major changes went on.

Specifically, a large change to the UI happened in 1.8.0 which made your config invalid. If you restored everything EXCEPT that config, you probably would have been fine.
That being said, major linux kernel updates have also occurred and the base network config for your device may also have changed.
Preserving settings is offered as a courtesy, but should not be relied on all the time.

I haven't seen the DST issue you described. Have you given the OS enough time to complete its initialization and sync with the time servers?
I will test it in a few weeks when my local area goes to DST.

[rickwookie]

Not ALL major updates, but i'd say most.
Keeping in mind that you updated from a version released in 2014 to one in 2017, it's probably not unreasonable to think that some pretty major changes went on.

Specifically, a large change to the UI happened in 1.8.0 which made your config invalid. If you restored everything EXCEPT that config, you probably would have been fine.
That being said, major linux kernel updates have also occurred and the base network config for your device may also have changed.
Preserving settings is offered as a courtesy, but should not be relied on all the time.

I haven't seen the DST issue you described. Have you given the OS enough time to complete its initialization and sync with the time servers?
I will test it in a few weeks when my local area goes to DST.

Just to make sure we're not at cross purposes:
It's not possible to either "preserve" settings, by using the sysupgrade.bin version, nor to "restore" backed-up settings, using the "Restore Old Configuration" UI option? I did the latter.

If this is the case, would now using the button "Restore Default Configuration Now" put everthing back as it would have been had I not done the "Restore Old Configuration" thing? If so, I could do this to see if it fixes the DST bug.

[Lantis]

I’ll clarify just to make sure you’ve got it, but I think you’re there.

- Upgrading between Gargoyle versions is always done with the sysupgrade images.
- you can elect to preserve settings or not.
- you can take a backup and restore these settings after flashing
- the last two points achieve the exact same thing
- consequently, a recommendation to not preserve settings equally applies to restoring a backup between the two versions

Yes restore to default wipes the entire configuration back to the default state

[rickwookie]

I’ll clarify just to make sure you’ve got it, but I think you’re there.

- Upgrading between Gargoyle versions is always done with the sysupgrade images.
- you can elect to preserve settings or not.
- you can take a backup and restore these settings after flashing
- the last two points achieve the exact same thing
- consequently, a recommendation to not preserve settings equally applies to restoring a backup between the two versions

Yes restore to default wipes the entire configuration back to the default state

So the factory.bin images are only for going from the hardware manufacturer’s original firmware to Gargoyle firmware?

[Lantis]

That is correct

[jstromsoe]

I just upgraded from 1.7.1 to 1.10.0 using the upgrade (.tar) file on my Netgear WNDR3700v4 router. I then, like the OP did, used the restore backup settings method to get all my settings/customization back just fine. And just like the OP I had to

Code: Select all

/etc/init.d/uhttpd start

and

Code: Select all

/etc/init.d/uhttpd enable

to get the webpage to come back. Other than that, everything works as it did before. Hopefully this helps someone else. Don't just do a factory reset on your router just because you can't access the webpage at first! Try to ping/ssh in first and if that works, its probably just because uhttpd is not running yet.

Perhaps @Lantis has some comments as to what else may not be working or borked due to flashing an old settings file... but its just fine now.

[Lantis]

The main issue was the web server.
There is always the chance that in such large version jumps (and associated kernel jumps) that the underlying configuration of the hardware and device itself is no longer compatible, and then you might end up with a non-bootable device.
Chances that this would completely disable failsafe... slim, but not ideal.

We make these recommendations for a reason, and I tend to not provide support to those who choose to ignore them. If you're clever enough to dig a hole, you must have thought to bring a ladder right?