For Jumbo frames to be truly efficient you need to enable it on every device you're using, otherwise you might just aswell turn it off.
1 Like
Good discussion in the r7800 exploration and r7800 performance threads about optimizing performance. Hnyman already has a clean limited number of programs. My two r7800 APs running hnyman 4.19 have all the services in the service drop down turned off and ipv4 DHCP turned off (hardwired to the router via cat 6A cable). Turning off unused low resource programs (firewall) is going to have negligible effect on performance.
See here for CPU tweaks: Netgear R7800 exploration (IPQ8065, QCA9984) - #1929 by ACwifidude
master-r11827-f8424b1b26-20191228-ct
The recent ubus version upgrade two days ago caused a bug for system log, which bug has now been fixed. However, the change also caused some services not to start, e.g. collectd (= LuCI statistics) and nlbwmon. ldir figured out that those fail where the procd init file has a "nice" parameter definition:
I have implemented that workaround in my own build.
Hopefully the underlying bug (in ubus or procd) gets fixed, but until then the workaround is to have the nice definition before the command definition in the procd init file of a service.
EDIT:
seems to be fixed in master. (it was a libubox blobmsg handling error)
master-r11829-e3e939d8e6-20191228-ct
2 Likes
Jumbo frames is enabled because I have a switch between my computer and my homelab, but I don't really need it anywhere else.
This isn't really a problem of efficiency... it's actually crashing the router, so I'm wondering if this is expected to happen or if it's a bug.
Edit: If I understand correctly, it should retry until the frames fit within the 1536, but in this scenario it somehow pushes 1.7KB
Spotted the latest build on the site hnyman, great work as always, thanks very much.
The problem with jumbo frames is a known bug with the ipq806x target, for which I understand a fix is now in master. See this post for a possible workaround.
1 Like
If i want to try the latest master build and if i'm now on vanilla, do i still have to TFTP flash the standard 18.06.5 image before flashing the latest build?
No idea what you mean by "vanilla".
I think that if you are running the Netgear OEM firmware, you might need to use the TFTP to flash the new OpenWrt factory image. (But some people said recently that they flashed OpenWrt directly from Netgear firmware, so I am not sure)
But there is no reason to flash anything 18.06.x
Just flash either the 19.07 build or the master build.
2 Likes
Thank you! I have now installed the current master build. A problem i have now though is that the router's wifi networks are visible but not connectable. 
The settings are the same now as in the vanilla firmware. Any idea what this could be?
No idea. And still no idea what you mean by "vanilla firmware".
There are no wifi-specific special changes in my build.
Did you sysupgrade or tftp? Did you keep your prior config file or did you reset your settings?
Wifi by default is turned off when you first get started. I’d configure the router with a hardwired computer. If it were me with a major upgrade I would reset the settings to the factory default (system drop down / backup firmware option). After it restarted I’d put everything in fresh. Enable the services and wifi settings you desire and you should be good to go.
I originally flashed your build directly over stock firmware about a year ago. Worked perfectly fine
If anyone would run into significantly larger image problem here is the solution:
@hnayman does it make sense to disable CONFIG_DEBUG in your build as well?
Running latest hnyman 19.07 build I'm getting occasional chatter across the network. The link between router & modem is flooded, slowing internet access. Eventually connection breaks with loss of DNS.
Router log is completely filled with:
daemon.notice netifd: wan6 (1879): Command failed: Request timed out
Appreciate this may not be specific to hnyman's build, I'm just looking for any help/hints what the cause is? Thanks.
I don't really have such packages in my build that would not use the normal binary stripping. And so the setting does not cause much size impact. (Samba disabling that stripping functionality and causing binary size growth sounds strange.)
Like jow explained to you in the samba thread, the normal stripping produces the small stripped binary for the firmware image, while the staging dir contains a full debug-enabled non-stripped binary for debugging with gdbserver.
If you add such problematic packages to my build config and you are not actively debugging things, feel free to disable that setting in your own builds.
1 Like
Weird one, have you messed with the IPV6 settings? wan6 is the alias for the IPV6 interface.
Its because of this bug and had no time to investigate this further: https://github.com/openwrt/packages/issues/10783
hnyman's 19.07 10784 just rebooted on me after 4 days of work. It was also behaving weird in 802.11r (roaming) mode. Overall rather vanilla configuration, just DHCP WAN, some ports blocked manually in firewall, and the 2.4ghz wifi enabled.
I went back to hnyman's 18.06. Pity... OpenWRT has become as much of a lottery as DD-WRT.
Roaming working right requires some fine tuning of the maximum transmit power so that radio physics matches with the roaming behavior you desire for your setup.
As an example - I actually had to turn down my max transmit power down to 23 to get a perfect roam for my two r7800 APs running hnyman’s build after some testing of RSSI values / house layout. One r7800 isn’t enough for the performance I want in my house... two required some fine tuning to get the behavior I desired, was very easy.
Your problem is a configuration issue rather than an issue with hnyman’s build or OpenWRT in general.
One reboot can happen with a power outage, accidentally pulling a plug, or a number of reasonable explanations. One reboot is hardly abort criteria without any proof from the logs that the software is to blame.
I’d open a separate thread on these two issues - there is probably a solution so that you aren’t stuck on a old software version (18.06).
1 Like
I meant that the old firmware was behaving better with 802.11r. I could actually go and turn off WiFi on one router, and my phone would switch without disconnecting. With 19.07, the WiFi icon disappears and then it takes it several seconds to reconnect. Moving between the access points doesn't do disconnect-reconnect, but it results in "stickier" behavior than with 18.06, the phone hanging on to weakening signal of router #1 even as I am standing right next to the alternate router #2. Power levels and all other settings identical to 18.06.
As for power outage... there was none. If it's enough to reboot the router, it would've been enough to blink the lights and reboot one of the PCs in the house.
Oftentimes old software is more reliable than new. After a major version comes to an end, they usually fixed many bugs without trying to create new features.