Difference between enterprise and normal?
Anyway the Netgear opensource repo is full of this driver
If you could find a newer release than the nss.ak.f I'm sure @quarky would have some use for it.
If nss.ak.e are for 6v qsdk and nss.ak.f for 8v qdsk then maybe the versions for qsdk 10 and 12 are nss.ak.g and nss.ak.h...
I have absolutely no idea what’s the difference. 
But from all the gears available in the market, enterprise offerings are mainly APs only, while retail are routers. So it may end up that the enterprise blob may have less features compared to the retail versions. Size wise, the retail version is larger.
I’ll look again at the Netgear repo. It’ll be great if they have the NSS firmware blobs, but I doubt it, as legally, AFAIK, they do not have to provide them.
Well a strings compare can show some magic like additional feature
I really would like to help out myself as well, but i just don't know how to compile the source for my router.
Although the R7800 is exactly the same as the NBG6817 i just can't do it right.
I had a compile and installed it but never got any connection out of it.
I would highly appreciate if someone with more experience then me could compile it for NBG6817 and i will gladly help out with testing.
If you're brave enough to test my builds, here you go:
https://app.box.com/s/ykyzhbsc8s87qw5dkunv3cv3lv43z0vs
Do note that the image for the nbg6817 has not been tested by me, as I do not have a unit to test with. If you know how to recover from a bad flash, do help test.
If you know how to test with the initramfs image, that'll be best.
Also, this build is based on lede-17.01, kernel v4.4.184. You should not use the sysupgrade image if you're onto openwrt-18.06/19.07/master.
Let me know if the images work for you. If confirm OK, I'll push the changes required to my GitHub repo.
Thanks.
The nbg6817 has a very robust push-button tftp(d) recovery mechanism, unless manually doing stupid things, you shouldn't be able to break it.
Other than the NAND based Netgear ipq806x routers, the nbg6817 is using mmc flash with GPT partitions for kernel/ rootfs instead - and ZyXEL dedicated 4 MB for the kernel from day one, so switching back- and forth between 17.01 and 18.06+ isn't a problem (and doesn't need tftp recovery). However, the wireless calibration (pre-cal) situation in 17.01 wasn't set up correctly yet, which hurts the nbg6817 with its external amps particularly (wireless might not work, even get damaged when operating too strong --> do restrict txpower by at least 3 dBm). Furthermore OpenWrt only learned about the nbg6817's dual-boot/ dual-firmware setup for 18.06, 17.01 can only be installed to the primary partition set (/dev/mmcblk0p4 && /dev/mmcblk0p5), while openwrt-18.06 will always alternate flashing between them - so this will result in confusion/ problems.
You should not flash/ use a 17.01 derived build, such as this, without backporting the pre-cal fixes contributed by @dissent1 (affects both r7500v2, r7800 and nbg6817, the later maybe a little more) and the dualboot feature contributed by me.
pre-cal:
dual-boot:
WARNING: there has been considerable refactoring between these two patches, so you will need further backporting rather than blindly applying them!
Optional: You probably also want to look into the wireless LED changes between 17.01 and 19.07, as this affects the configuration (/etc/config/system and hardware behaviour).
The ipq806x target has seen considerable changes since 17.01, some of which are really important (pre-cal for all ipq806x devices (especially those using QCA9982 and QCA9984 wireless), dual-boot for the nbg6817 in particular). Unless you can do the backporting of the relevant fixes/ changes yourself and can stay ahead with the development, using a 17.01 derived build should be recommended against, as you will hit problems and might even damage your hardware permanently.
My R7800 seems to be working OK with the 17.01 branch tho. Range and speed appears fine too. Thanks for the heads up tho. Will see how to patch the driver.
Installation from OEM firmware went smoothly. BUT there are a few problems.
Lets start with #1: https://i.imgur.com/IooX2K5.png
The second problem is this: https://i.imgur.com/9yV30Fj.png
Speedtest strangely enough only shows 40% sirq while doing 580-600 on the downstream with a bufferbloat up to 2k ms.
The third problem is this: https://i.imgur.com/9TsivCx.png
There are no wifi config options neither does /etc/config/wireless exists.
here yah go: 
Looks like the NSS drivers failed to load. Could you provide the syslog output when it just got rebooted?
I don't have a serial console or how ever that is called. Neither the knowledge to read from the router.
Would it be possible over eth cable?
You can extract from the GUI via browser. Once it’s booted up, log in using browser and save the contents is the syslog via the menu Status - System Log
The first part of the log which can tell me what’s wrong has been overwritten. Can’t tell from your logs why the NSS drivers didn’t load.
I'm not sure how i could get that data as soon the router boots.
Would you know how to ssh into your router? If you do, try the following:
modprobe qca-nss-drv
logread
Pls show me the output you see.
Thanks.
What i seem to get from: modprobe qca-nss-drv is this: No supported HAL compiled on this platform
Ok. I think the .dts file is incorrect. I’ll have to figure out what’s missing.