Build for Netgear R7800

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.

The following ubus command shows that I have been given and IPv6 address via DHCPv6, have been assigned a /56 prefix for delegation (=256 x /64 prefixes for my LAN, of which OpenWrt have been configured to grab /60 by default) and I use upstream DNS servers. Routing nexthop is a link-local address from ISP.

root@router1:~# ubus call network.interface.wan6 status
{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "dynamic": false,
        "uptime": 87775,
        "l3_device": "eth0.2",
        "proto": "dhcpv6",
        "device": "eth0.2",
        "metric": 0,
        "dns_metric": 0,
        "delegation": true,
        "ipv4-address": [

        ],
        "ipv6-address": [
                {
                        "address": "2001:14ba:a301:292e::1",
                        "mask": 128,
                        "preferred": 11231,
                        "valid": 11231
                }
        ],
        "ipv6-prefix": [
                {
                        "address": "2001:14ba:a0cf:d000::",
                        "mask": 56,
                        "preferred": 11231,
                        "valid": 11231,
                        "class": "wan6",
                        "assigned": {
                                "lan": {
                                        "address": "2001:14ba:a0cf:d000::",
                                        "mask": 60
                                }
                        }
                }
        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::4255:82ff:fea4:23d8",
                        "metric": 512,
                        "valid": 3700,
                        "source": "2001:14ba:a0cf:d000::/56"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::4255:82ff:fea4:23d8",
                        "metric": 512,
                        "valid": 3700,
                        "source": "2001:14ba:a301:292e::1/128"
                }
        ],
        "dns-server": [
                "2001:14b8:1000::1",
                "2001:14b8:1000::2"

And the same shown in the routing table (I deleted some irrelevant lines):

root@router1:~# route -A inet6
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
::%35/0                                     fe80::4255:82ff:fea4:23d8%35            UG    512    4        0 eth0.2
::%35/0                                     fe80::4255:82ff:fea4:23d8%35            UG    512    1        0 eth0.2
2001:14ba:a0cf:d000::%35/64                 ::%35                                   U     1024   3        0 br-lan
2001:14ba:a0cf:d000::%35/56                 ::%35                                   !n    2147483647 1        0 lo
fd1b:7654:3210::%35/64                      ::%35                                   U     1024   3        0 br-lan
fd1b:7654:3210::%35/48                      ::%35                                   !n    2147483647 2        0 lo
fe80::%35/64                                ::%35                                   U     256    1        0 eth1
fe80::%35/64                                ::%35                                   U     256    1        0 eth0.2
fe80::%35/64                                ::%35                                   U     256    1        0 ifb4eth0.2
::%35/0                                     ::%35                                   !n    -1     2        0 lo
::1%35/128                                  ::%35                                   Un    0      5        0 lo
2001:14ba:a0cf:d000::%35/128                ::%35                                   Un    0      3        0 br-lan
2001:14ba:a0cf:d000::1%35/128               ::%35                                   Un    0      4        0 br-lan
2001:14ba:a301:292e::1%35/128               ::%35                                   Un    0      4        0 eth0.2

Thanks @hnyman , I compared the ubuses and I've got 2 more addresses and 4 more routes listed. Especially the addresses seem awkward:

        "ipv6-address": [
                {
                        "address": "::3e37:86ff:fe2a:c511",
                        "mask": 64,
                        "preferred": 604764,
                        "valid": 2591964
                },
                {
                        "address": "2a01:90a0::3e37:86ff:fe2a:c511",
                        "mask": 64,
                        "preferred": 604354,
                        "valid": 2591554
                },

The last one has mask 128 and looks like yours.
First I'm going to get some IPv6 knowledge so I know how this works, it is quite different than IPv4. Then if necessary I'll open another topic for this. Thanks for showing the commands.

Update, I contacted the provided and they showed me they only hand over the third (mask 128) address to me. So the two above are created by DHCPv6 or a script. Any thoughts?
They also mentioned the gateway is pointing to an internal address fe80::1, while we would expect an external? Provider says nothing's changed over the previous months.
As DUID the MAC address is sent without additions.

Also, I found a network status screenshot from my first and previous firmware master-r13628-870588b6eb-20200625, and this only showed an IPv4 upstream! So this explains the change ...

The nicest way is to get this working properly, but an alternative is to shut that IPv6 upstream, while leaving it available on the internal network. Is that simply possible? I've tried some disabled but the upstream does not disappear and the two minute delay stays, not only for package management, but also for some websites and apps on pc and phone ...

I am experiencing similar issues on 2.4 GHz. Is there any known fix yet?

I'm trying to install package kmod-nf-nathelper - this refuses to install and complains about a version conflict. I see the package is version 5.4.66-1 while the kernel is 5.4.65-1. Is that the cause?
How to fix this?

image
2.4 GHz on 16 meters and some walls. I would expect symmetrical speeds and have seen higher speeds.

For reference, what 5 GHz does on this distance:
image

1 Like

That is part of the reason. Kernel version has been bumped since I last did a build.

You can't fix it.
Due to precautions, there is strict (kernel version & options based) checksumming for kernel kmods, and in practice you can't install additional kmods to private builds (unless the kmods have been complied along the main firmmare).

If you need additional modules, you have to options:

  • use a release or snapshot firmware from OpenWrt repo and install the additional kmods
  • compile a personal version with the kmods that you need.

Clear.

I had it in my previous WNDR-3700 and it is supposed to fix strange ftp issues (I see now in the R7800).
Is it interesting enough / small enough (7 KB) to include in your release? I see it uncommented with a #. I'd prefer to stick with your master build :wink:

The 2.4ghz band is overloaded. You are probably getting interference from somewhere (baby monitors, virtual networks, neighbors, Bluetooth, and nearly every wireless device ever).

40mhz wide channels frequently default down to 20mhz channels. With a 2x2 client, PHY speed is 144mbps (you’ll never get this).... add in interference + overhead... anywhere between 60-100 is a good result.

See here:

Hi guys,

Does this fix affect the r7800?

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1c6d45644a54e50b6445bbc63eff1ae34b2f1e2e

Thx.

Not quite sure, but I think that it does.
And it might help to fix random disconnections that have been present some weeks.

(The new patch claims to fix 321-mac80211-optimize-station-connection-monitor.patch that was introduced in August. Took a while to figure out that the fix is not for the upstream mac80211, but for the local tweaks/optimizations done for OpenWrt. Not quite sure why nbd did not directly modify his original patch...)

I spent a lot of time with DD-WRT and it's been TREMENDOUSLY unstable compared to OpenWRT/LEDE until the last year, where OpenWRT matched its instability.

Now for both types of firmware, the algorithm is the same: only stick to firmware version which was proven stable via suffering/sacrifice of other users.

Don't believe anyone claiming that whatever's latest on "master" is stable - ever. We are the alpha- and beta-testers for these firmwares, and if you don't want to be one, stick to a proven build.

I still use "R7800-master-r11167" build which I got from this very thread because someone proved that it ran for 50 days with wifi and SFE enabled, with no obvious issues.

I did have to add the startup commands to squeeze more speed out of it.

As for DD-WRT, the stable build for this router is Kong's 37495M . As far as I know.