Build for Netgear R7800

No, I upgraded from stock Netgear firmware and the system came up in a state that was not really ideal, I only could access it with a fixed IP.

Well yes that's what I would think too. But I'm not able to check the image file to see why it is that way. Maybe this image was intended only for upgrading from stock-openWRT?

Well, for me the solution to manuallly create the config file solved the issue.
But if somebody here can check the source tree for building these images, it might be worth adding a default dhcp config file :wink:

The DHCP config file should be there quite normally. There is no functional difference in factory image ( for flashing with OEM firmware or TFTP) and sysupgrade image ( for flashing from a running OpenWrt).

I'm a bit confused .... which one is preferred now?

  • master-r14443-f1bc66c765-20200910 (ath10k-ct)
  • stable openwrt-19.07 owrt1907-r11210-29b4104d69-20200907 (ath10k-ct)

I'm running master-r13628-870588b6eb-20200625, so if I read hnyman's statement above, the most promising 19.07.4 fixes were already included in my firmware?

  • kernel: fix hardware flow offload
  • firewall: fix TCP MSS clamping that was only applied on one direction ([FS#3231]

Master is the “trunk” and has all the latest updates (kernel 5.4). My opinion - If you are already comfortable with master...“want the latest”, stay with master.

19.07.4 is an update of a branch off of the trunk back in July 2019. It is using kernel 4.14 still. Hardware offloading in 19.07.4 is for other routers, not the r7800.

Thanks, the 5.4 kernel is a good argument.
Do you think the firewall fix (MMS clamping) will fix quirky FTP connetions through different zones (lan/wan and lan/guest), or was this already present in the trunk?
Too bad for the R7800 hardware offload, I hope it will be there some time. I'm now at 60% line speed (it's fast anyway :wink: )

@zaadstra R7800 NSS hardware offloading is discussed here :sunglasses::

1 Like

Hi,

I just upgraded to master-r14465-04d3b517dc-20200913. I noticed the vnstat(2?) is missing and check Software for re-install. I installed this in the previous firmware, I thought packages would survive sysupgrade? It seems other pakages are gone too.

Update Lists results in an error:
Unable to execute *opkg update* command: SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data

I checked the /etc/opkg/distfeeds.conf als in the WNDR3700 build was mentioned that http was used instead of https, but this looks ok:

root@OpenWrt:~# cat /etc/opkg/distfeeds.conf
src/gz openwrt_core https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/packages
src/gz openwrt_base https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base
src/gz openwrt_luci https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/luci
src/gz openwrt_packages https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/packages
src/gz openwrt_routing https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/routing

Did I miss something?

I just mimiced the update command and grabbed https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/packages/Packages.gz in a browser, this works fine.
(wget -q -O /tmp/opkg-elpLmH/Packages.gz https://.....)

When returning after two hours planning to flash the previous firmware, I saw in Software that the package list was filled .... magic.
Then installing vnstat2 and after some while I get the same JSON data line 1 error. When retrying the install to capture the error text I get a new error:

Collected errors:
 * opkg_conf_load: Could not lock /var/lock/opkg.lock: Resource temporarily unavailable.

The opkg install command failed with code 255.

Is this something with the build or a common issue? When searching for the error message I find a post from 2016, with answer a flame on Luci.

Some later if I check the software list it says vnstat2 and vnstati2 are installed but I don't see it.

Thanks for any clue.

Neither.

My guess is that you managed to try the download the package list (opkg update) just when the buildbot was uploading a new build version of the packages to teh download server.

opkg update and installing vnstat2 works quite normally for me:

 OpenWrt SNAPSHOT, r14465-04d3b517dc
 -----------------------------------------------------
root@router1:~# opkg update
Downloading https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.sig
Signature check passed.
root@router1:~# 
root@router1:~# opkg install vnstat2
Installing vnstat2 (2.6-1) to root...
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/packages/vnstat2_2.6-1_arm_cortex-a15_neon-vfpv4.ipk
Installing libsqlite3-0 (3330000-1) to root...
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/packages/libsqlite3-0_3330000-1_arm_cortex-a15_neon-vfpv4.ipk
Configuring libsqlite3-0.
Configuring vnstat2.

No,
installed add-on packages have never survived the sysupgrade. Their configs do survive, but the packages themselves need to be reinstalled after sysupgrade.

1 Like

Thd Software update lists button throws the same error: Unable to execute opkg update command: SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data

If I switch to another screen and return to Software after 5 minutes, the packages are there.

Typing it in ssh still complains about the lock:

root@OpenWrt:~# opkg update
Collected errors:
 * opkg_conf_load: Could not lock /var/lock/opkg.lock: Resource temporarily unavailable.
root@OpenWrt:~#

I remember the behaviour in Luci was better in june, is it timing out to early now?

Althought vnstat seems to be running, I don't see it in the interface (reboot did not help):

root@OpenWrt:~# ps | grep vnstat
 5303 root      2188 S    /usr/sbin/vnstatd --nodaemon
 5830 root      1104 S    grep vnstat
root@OpenWrt:~#

vnstati2 is installed too.

In the system log I noticed this message:

Mon Sep 14 00:20:04 2020 daemon.info vnstatd[1866]: Info: vnStat daemon 2.6 started. (pid:1866 uid:0 gid:0 64-bit)
Mon Sep 14 00:20:05 2020 daemon.err collectd[1932]: configfile: stat (/etc/collectd/conf.d) failed: No such file or directory

This folder (and file) was not present, I created the folder now.

Upd: the lock message may seem correct:

root@OpenWrt:~# ps | grep opkg
 5672 root      1124 S    /bin/sh /usr/libexec/opkg-call update --force-removal-of-dependent-packages
 5673 root      1124 S    /bin/sh /usr/libexec/opkg-call update --force-removal-of-dependent-packages
 5675 root      1188 S    opkg --force-removal-of-dependent-packages update
 5923 root      4640 S    wget -q -O /tmp/opkg-ljknBL/Packages.gz https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/luci/
 5944 root      1104 S    grep opkg
root@OpenWrt:~#

Works ok for me:

There deninitely is something quirky here .... Where can I look, how to fix this?
I don't need to reload config settings after sysupgrade, do I? (I choose preserve settings).

Ok, now I'm ashamed, I was convinced that the vnstati2 was the display part of the duo, but there's a third one: luci-app-vnstat2
It gives the error message (json) too... Browsing away and back and it is not installed. The opkg seems to be very slow.
vnstati2 which I uninstalled and re-installed did not re-install I see now...

I got focused on the opkg error messages. Maybe this just needs some time to finish its housekeeping. Another (shell) package find-utils also did not show up.

I guess that you have some problems with the network config and/or reachability. Perhaps some cache, proxy, antivirus, whatever...

Normally opkg is quick. Having several unfinished processes shown by ps (like you have) is abnormal.

My suggestion is to clear all your settings with "firstboot" and reboot. Then manually reconfig the router. And please make sure that there is no pihole, ISP antivirus, proxy, whatever external factor that prevents the normal connectivity for opkg (= wget or uclient-fetch as underlying file download tools).

Thank you for your fast replies @hnyman.

I understand the choice of firstboot/clean start but if there is a change I can prevent to enter all config again (lots of port forwards) and having downtime (kids/school) then I'll go for that. I hope you understand. I don't have weird network config or tools installed (they're gone with the update anyway). I do want to install kmod-nf-nathelper if this is working again (for ftp).

As the download in the browser is lightning fast, and on the router it isn't, I tested some more.

Manual opkg update ran fine:

root@OpenWrt:~# opkg update
Downloading https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.sig
Signature check passed.
root@OpenWrt:~#

BUT it took at least 15 minutes .... Then I simulated a download:

root@OpenWrt:~# wget  https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/packages/Packages.gz
--2020-09-14 18:44:02--  https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/packages/Packages.gz
Resolving downloads.openwrt.org... 2a01:4f8:150:6449::2, 176.9.48.73
Connecting to downloads.openwrt.org|2a01:4f8:150:6449::2|:443... failed: Operation timed out.
Connecting to downloads.openwrt.org|176.9.48.73|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 83415 (81K) [application/octet-stream]
Saving to: 'Packages.gz'

Packages.gz                              100%[===============================================================================>]  81.46K  --.-KB/s    in 0.02s

2020-09-14 18:46:12 (4.30 MB/s) - 'Packages.gz' saved [83415/83415]

root@OpenWrt:~#

And that looks fast but it hung for about 2 minutes on the downloads.openwrt.org|2a01:4f8:150:6449::2|:443 part.

As my provider does not offer IPv6, is it the right conclusion that something changed between master-r13628-870588b6eb-20200625 and master-r14465-04d3b517dc-20200913, which switched priority between IPv4 and IPv6 traffic, or did add some other IPv6 magic? In the June firmware I did not have this issue and I noticed local devices talking IPv6 (win10, rasp pi etc) then.
Does this ring a bell?

Note that there is ipv6 DNS results...

Not really. Ipv6 functionality is pretty much the same. And ipv6 has always been preferred over ipv4.

You might have ISP that hands out ipv6 DNS results although it provides no actual ipv6 connection/routing.

That has been a problem earlier with the download tool that opkg uses by default (uclient-fetch defining itself as wget). You might try installing the full wget package, as it handles faulty ipv6 better.

Got into bootloop after flashing the latest master, at least I learned a new skill today (tftp).

TFTP fixed it but had a couple issues because I kept trying the sysupgrade.bin file instead of the factory.img. Once I realized that it was quick and luckily I made a backup of settings before trying to upgrade.

Thanks I'll keep that in mind as a second option.

It appears the provider offers IPv6 and I do have an IPv6 address (even more than one)! So DNS works and ping and traffic etc not. The issue looks a bit like this one: https://forum.openwrt.org/t/solved-cant-ping-ipv6-wan-from-router/47157/17. The first of the two fixes is strange, I don't have all that routing options he mentions? The second looks easy, adding one line.
Does this solution makes sense in your build?

My build has nothing special regarding IPv6.

Not sure if those settings make any sense, as they are apparently for semi-misconfigured ISPs.

(I have a normal full IPv6 with prefix delegation from my ISP, so I can't really test those.)

A bit off topic now, but if you can tell or show what is normal, I can check with what happens here and optionally ask the provider to change things. They say it is working with their 'own box' however.
My first IPv6 address at status screen starts with :: and I'm affraid (can't check) that is used for routing. The other two addresses are nice real world addresses.