NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
6.9.5 GPL not posted.
OOM-9
https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL has a link to 6.9.5 GPL, but the zip itself hasn't been posted yet. https://www.downloads.netgear.com/files/GPL/R...
Hi StephenB,
The 6.9.5 GPL zip file has been posted already. You should now be able to download the file.
Regards,
This obstruction to building modules is not a small issue for customers who need support for a particular device or want to add features to their machines. For 6.10.x, Netgear needs to make a bold notice to let potential upgraders know that there currently is no easy path to customizing modules or the kernel at this time, and no easy path to downgrade from 6.10.
Will the build environment to make this work be downloadable or redistributable?
I'm sure Stefan can come up with a reasonable process to compile with the tools he's been given, but there's no need to make users jump through hoops to customize their gear. I'm also sure this mess is to prevent tampering with the kernel or encrypt and sign some proprietary pieces of software or some blustery nonsense like that, but like all DRM, it only serves to place barriers and traps for legitimate use.
In any case, I'm eager to either see your results or figure out a safe procedure to do this myself, because I rather like having VirtualBox installed, and there's no reason I shouldn't be able to compile some GPL drivers for this GPL kernel, GPL it!
Unsurprisingly, there's very little information as to how to mount the flash memory from a running system. Maybe it's visible from BusyBox, but I usually had other concerns if I was using that mode.
Then, like you're saying, you have to trust that there are no errors in the .config and that you can produce an identical kernel to the one shipped with the OS with no loss of reliability or function. However, if we're going by history and the mistakes and inconsistencies with source archives in the past, that does not instill confidence in the procedure for the future. One should not have to put their NAS at risk to compile a module that works.
Maybe we should drop RMS a note explaining the situation...
Sorry for the long delay but I was caught up in work. Important things first: I got the new build environment to work and was able to build a kernel and modules. Unfortunately, even with the new build environment, the result stays the same - modules created that way can't be inserted in the running kernel.
I tried to get more information and also the .config file actually used for building the kernel shipped with firmware 6.9.5 but unfortunately the guy from NTGR I was in contact with stopped responding.
That said, I don't think this change (and the resulting problems for developers) were made intentionally. I can see that the new build environment is based on Debian "buster" and from NTGR's perspective it makes perfect sense to use that one to get the latest compilers and better support for newer ARM processors (do I hear speculations about new models? ;)). However, NTGR also should keep in mind that at least a percentage of users is picking the ReadyNAS over the competition exactly because of it's open and easy to extend architecture based on Debian as well as the consistent hardware line-up. I know of no other brand where you can morph your NAS into an automated VCR that easily, add VirtualBox or other stuff. Even app development is a lot easier on the ReadyNAS compared to other offerings and I know of a lot of businesses where those apps are in production use.
Until now one could even attach special hardware to the NAS by just building the needed kernel modules without having to fear one would break something because either the module could be loaded into the running kernel or not - but there was no chance to break the kernel or the NAS by having to replace the kernel. With the current change this is no longer a given.
Since I still believe the problem lies with the .config file shipping with the GPL my suggestion would be:
- ship the next versions of the firmware with the
configs.komodule either included in theroot.tgzor compiled in to the kernel. The support for the/proc/config.gzcopy of the kernel config file is enabled in the firmware since ages anyway, so why not provide the tools to read it? - provide a consistent method along with descriptions and how-tos for building kernel modules and maybe .deb packages based on the build environment
- allow for downloading the current build environment by interested external developers
itachi2 I don't think this has anything to do with DRM or other dark schemes either, since to my knowledge nothing on the ReadyNAS is signed / encrypted in any way beyond what's already done in a standard Debian environment. Even less since you don't even need to sign packages (although I do) to have them installed on the NAS. I don't think that the problem we're currently facing was created intentionally. Rather NTGR didin't think that anyone would use the ReadyNAS beyond the use cases they and their marketing figured it could be used for ;)
-Stefan
Thanks a lot for the spent time to investigate this. This is a big issue now because that means I have to stay an 6.9.4 on all our devices. Being able to compile custom kernel modules is crucial and was the main reason to go with a Netgear device.
I can only hope Netgear will fix this problem in the future.
Success at last. The guy from NTGR support got back to me and hinted me in the right direction. Unfortunatley I can't attach the config.gz file because of the limitations of this forum here, so you have to get the .config file yourself like this:
I didn't know that you could install a subset of the modules built b<y NTGR together with the kernel by simply installing an additional .deb package. Luckily this package also includes the configs.ko kernel module that lets you get to the config of the kernel currently running. So all you have to do to get the config of the currently running kernel is:
ssh into your ReadyNAS (as user root)
cd <where you put the kernel sources> apt update apt install linux-image-extra modprobe configs zcat /proc/config.gz > .config
Works on my machine, ymmv.
-Stefan
P.S.: For thechnically inclined, here's the diff to what's shipping with the GPL archived to the .config actually used:
$ diff -Nau .config.old .config --- .config.old 2019-01-28 22:32:47.000000000 +0100 +++ .config 2019-02-25 06:43:10.000000000 +0100 @@ -1,6 +1,6 @@ # # Automatically generated file; DO NOT EDIT. -# Linux/x86 4.4.157 Kernel Configuration +# Linux/x86_64 4.4.157 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y @@ -73,11 +73,8 @@ CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y -CONFIG_AUDIT=y +# CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y -CONFIG_AUDITSYSCALL=y -CONFIG_AUDIT_WATCH=y -CONFIG_AUDIT_TREE=y # # IRQ subsystem @@ -811,7 +808,6 @@ # # Xtables targets # -CONFIG_NETFILTER_XT_TARGET_AUDIT=m # CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set # CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set # CONFIG_NETFILTER_XT_TARGET_HMARK is not set @@ -3860,7 +3856,6 @@ # CONFIG_SECURITY_YAMA is not set CONFIG_INTEGRITY=y # CONFIG_INTEGRITY_SIGNATURE is not set -CONFIG_INTEGRITY_AUDIT=y # CONFIG_IMA is not set # CONFIG_EVM is not set CONFIG_DEFAULT_SECURITY_DAC=y
Looks like NTGR enabled some auditing and security features in the kernel. I guess we'll see those again in 6.10.x
Now this really p*sses me off. I tried for like a dozen times to post a solution and no matter what I do all post go straight to moderation.
So I try again.
Success at last. The guy from NTGR support got back to me and hinted me in the right direction. Unfortunatley I can't attach the config.gz file because of the limitations of this forum here, so you have to get the .config file yourself like this:
I didn't know that you could install a subset of the modules built b<y NTGR together with the kernel by simply installing an additional .deb package. Luckily this package also includes the configs.ko kernel module that lets you get to the config of the kernel currently running. So all you have to do to get the config of the currently running kernel is:
ssh into your ReadyNAS (as user root)
cd <where you put the kernel sources> apt update apt install linux-image-extra modprobe configs zcat /proc/config.gz > .config
Works on my machine, ymmv.
-Stefan
WhoCares_ wrote:
Now this really p*sses me off. I tried for like a dozen times to post a solution and no matter what I do all post go straight to moderation.
For some reason the posts got trapped by the automatic spam filter. I released the most recent one there. The mods are supposed to check it periodically, but they can get behind (and there often is a flood of spam). If this happens again, you can PM me I will release it for you.
WhoCares_ wrote:
Unfortunately I can't attach the config.gz file because of the limitations of this forum here, so you have to get the .config file yourself
OOM-9 : I think it would be useful if config.gz was included in the GPL zip. Or perhaps a readme that includes WhoCares_ procedure?
That's really cool. Works for me as well. Thanks for the all the work!
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
