No. The BCM4331 is recognized by the system with LEDE, but drivers are not compatible with the 5GHz band, and the radio waves in the 2.4GHz band are weak and unstable.
[ 15.204315] b43-phy0: Broadcom 4331 WLAN found (core revision 29)
[ 15.210520] bcma: bus1: Switched to core: 0x812
[ 15.220240] b43-phy0: Found PHY: Analog 9, Type 7 (HT), Revision 1
[ 15.226408] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2059, Revision 0, Version 1
[ 15.233799] b43-phy0 warning: 5 GHz band is unsupported on this PHY
[ 15.240039] b43-phy0 ERROR: b43 can't support any band on this device
[ 15.246499] b43: probe of bcma1:1 failed with error -95
[ 15.251792] b43-phy1: Broadcom 4331 WLAN found (core revision 29)
[ 15.257861] bcma: bus2: Switched to core: 0x812
[ 15.260217] b43-phy1: Found PHY: Analog 9, Type 7 (HT), Revision 1
[ 15.266383] b43-phy1: Found Radio: Manuf 0x17F, ID 0x2059, Revision 0, Version 1
[ 15.280347] Broadcom 43xx driver loaded [ Features: NL ]
What's in the log? grep for 'fast-classifier'
And what version of compiler are you using?
Have you ran make clean before compiling if you are using your current buildroot?
Do you have kmod-shortcut-fe-cm unchecked? Compiler/kernel support me that fast-classifier and sfe-cm cannot co-exist, so when compiled within 1 source package both modules can't be loaded at once. Maybe for your soc arch/compiler version it shouldn't be even compiled together.
edit: I've might have figured out why fast-classifier doesn't operate along with sfe-cm. Commit in my post should solve the issue for you, it's presumably the same source of the problem.
Size of 1249 went down to 6 again, so it's good (I restored bunch of browser sessions that time to see what's going on).
As someone else alredy asked: can you make a patch for the current 17.01 branch? I'm pretty sure even more people would try it out.
Of course I understand that it's more work, so feel free to say no
Thanks
k4.4 and k4.9. Haven't tested if patches for k4.4 apply without errors, but it should.
Fixed a compiler bug when module didn't load. You should choose fast-classifier only. Please test.
Tried to compile shortcut-fe for AR71xx target(kernel 4.4):
$ git fetch https://github.com/dissent1/r7800.git sta62
$ git cherry-pick b354fad4bd240ee623e758c453a660ad962cf64b
$ make menuconfig
tmp/.config-package.in:10347:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
tmp/.config-package.in:10347: symbol PACKAGE_kmod-fast-classifier depends on PACKAGE_kmod-shortcut-fe-cm
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
tmp/.config-package.in:10793: symbol PACKAGE_kmod-shortcut-fe-cm depends on PACKAGE_kmod-fast-classifier
$ make
...
/home/azuwis/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/shortcut-fe/sfe_cm.c: In function 'sfe_cm_sync_rule':
/home/azuwis/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/shortcut-fe/sfe_cm.c:825:15: error: invalid operands to binary + (have 'struct timer_list' and 'u64 {aka long long unsigned int}')
ct->timeout += sis->delta_jiffies;
^
/home/azuwis/src/lede/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/shortcut-fe/sfe_cm.c:888:19: error: 'nfct_time_stamp' undeclared (first use in this function)
ct->timeout = nfct_time_stamp + timeouts[UDP_CT_REPLIED];
...
Interesting, are you using gcc 5.x version? Remove sfe-cm code as you did before and try again please, seems like a compiler linker problem, I cannot reproduce it in my environment.
In my case I use gcc 7.x, now I will try a new compilation with the new commit and see the results. But in the previous compilation when executing "insmod fast-classifier.ko" inside the directory /lib/modules/4.9.37/ it says: "insmod: ERROR: could not insert module fast-classifier.ko"
Yes, but @davidzodelin uses 7.x as do I. While I don't encounter any problem he does, so it's not compiler. Remove the sfe_cm.o and shortcut-fe-cm.o from makefile and try again please to narrow the issue.
edit: 1 of devs has tested it on mips34kc target - works as intended. Do you guys both have mips24kc?
That's pretty good news, thanks! I'll try out during the weekend on Archer C5 v1.2, using current 17.01 branch(is kernel version 4.71 in it?)
Btw, what does that bridge setting do in real world? is it have to be enabled by default?