That is correct.
ok thank you
@Hnyman after doing the large flash master upgrade have you had any issues reverting to stock? I've been unable to get tftp working since then, it always stalls out at 3/4 complete using the windows GUI method or just quits out after a while using the CMD prompt.
Is there any tips and tricks? I've done the obvious with regard to setting a static IP, I've tried various stock firmware files... Good job it always falls back to working Lede 
I had similar issue using Windows TFTP app, FW seemed not to fit, and would stop uploading relative to their size
Using command line version sorted it
I tried the CMD line several times too...
I had the same problem with the old TFTP2 app (from dd-wrt?) that I have been using for years, but I switched to use TFTP64 and that works well. (the client mode)
http://tftpd32.jounin.net/tftpd32_download.html
https://bitbucket.org/phjounin/tftpd64
1 Like
Is the bug with Flow Offload and persistent connections fixed in either the 18.06 or Master branch of this firmware? According to this thread, it was recently fixed in the "main" branch, and I'm not clear on how these changes propagate. Thank you.
It "propagates" once I make a new build from new sources that include the commit with the fix.
I assume that you mean the four commits from NBD on 14 June 2018.
Those are now on both master and 18.06 main source repos, so the fix will be in my next builds.
(Actually the last 18.06 build has been made just from that fix 18f18a2 so it already has the fix)
EDIT:
master-r7200-2f3c5fe-20180616-large-flash
3 Likes
So under UPNP settings, if you enable IGDv1 mode, it fixes the issue because the devices such as PS4 and Xbox One work in that mode best.
I need to do more testing but it seems the nlbwmon cpu usage issue is fixed or doesn't occur anymore. I did a minor change to the nlbwmon service config to control the priority but I'm not sure if that's been the fix.
1 Like
Running r7093-4fdc6ca31b for the moment and wireless was suddenly disabled by itself. Anyone had that problem?
Also /usr/sbin/nlbwmon is causing high load, any info on how to fix it?
18:53:39 up 20 days, 8:10, load average: 1.05, 1.09, 1.03
I restarted nlbwmon for now.
I was on 7275 or whatever version and 4 times in 3 hours wireless disabled and restarted.
never happened before, gone to 7200 to see if it behaves better.
I'm on r7309 with a Kernel 4.14.51 patch applied and no issues with wireless, so it looks like that master rev is stable for the most part (and does away with the 60Mbps per stream limit I was seeing with Kernel 4.14.50)
1 Like
I'm upgrading from Archer C7 flashed with vanilla master-r7312-5c5bf8b865 to R7800 flashed with hnyman's master-r7314-c4aadbdaf6-20180625-large-flash through TTFTP.
I took a settings archive backup from the C7 along with a list of installed packages, and then installed the missing packages on R7800. The R7800 is operating very abnormally at this point; every other DNS request is dying, speeds way below 50kbps (verified it's not an uplink issue as C7 was operating normally). After restoring the settings archive on R7800, it completely stopped working beyond just booting up; no DHCP, no connecting to WAN (LED is off), no WiFi (LED is off and no network seen). I flashed again with TTFTP and tried the same thing - it failed the same way.
Are there any compatibility issues with the configurations that I should be aware of? As far as I know, it shouldn't matter because user-facing configurations don't care what device/arch you're running.
You can't upload a configuration tarball for a completely different router, at least the network (with that the vlan setup) and wireless configuration will be completely different.
While some of the config files are more of less target agnostic, the most essential ones definately are not. You can use your stored config tarball for reference, but not for restoring. Go the firstboot route to reset your new router to its factory defaults and start up fresh.
In some parts uci directives are quite a bit more device agnostic, but even there you do have to consider some differences between different devices.
1 Like
Sounds strange that you are trying to use a backup from another router model. Like slh said, at least the hardware related settings (network, wireless, LEDs, switch, VLANs etc.) are likely incompatible.
reset the router by "firstboot" or from LuCI.
1 Like
@slh That makes sense. I just took a backup of the R7800 and started comparing a few things to the C7's backup and indeed you're right. It makes sense that they're not compatible. Thanks for the help and information
@hnyman Doesn't sound that strange. Before slh's comment, I didn't think much about the incompatibility issues, so naturally I tried to restore the backup to the other model.
Running R7800-master-r7314-c4aadbdaf6-20180625-1822 (master) and trying to sys upgrade to R7800-owrt1806-r7104-ecee5bf1a1-20180626 (18.06), but when the router reboots it is still running master. Do I have to go through TFTP for this? sysupgrade does not log any errors.
Maybe it is similar for R7800, but there was a bug in which hostapd wouldn't quit in time on mt7621, blocking the sysupgrade. It could be fixed by disabling all WiFi interfaces in Luci before upgrading or by running wifi down via ssh.
As you reboot back to master, the flashing was never performed, the sysupgrade stopped before that.
logs do not survive reboot, so the only way to see the logs is either from console, or with a serial console connection.
EDIT: removed the claim that I succesfully upgrade from master r7414 to 18.06 r7104
I used the ssh connection and there was no error logged. I will try later while disabling wifi.