Thanks for the manual. I didn't find it when I was researching wave300 materials.
TP-LINK TD-W9980B(DE) V1.0 firmware updates contain GPL'ed modules of 3.4 version, but no sources. I've asked tp-link to update tarball with GPL source from TD-W9980 (3.1 version I think), but they said it will take some time (and resources) to do that as the device is a few years old now.
A D6100 owner could probably ask somebody in netgear to do that too btw.
I looked there and there seems to be only a build system with compiled object files and kernel modules under GPL version (grep for "GPL"), but no C source codes. You could not make a working driver with object files only, because there will be most likely API+ABI changes in current 4.14 kernel version (and I think these modules are for 2.6, which is really old).
IANAL but you are eligible to obtain GPL source codes as there is GPLed kernel module.
Hmm it seems I deleted my copy of firmware when I regenerated my openwrt build :-/ but all I did was just extracting the firmware from zip file from here combined with 9980 versions of the modem, D6100 GPL zip and copies from the modem itself (you can copy the files to a usb stick in shell on uart console).
I was able to only scan network without any association to AP, but no kernel panic.
Tp link website does not offer the 131012 firmware anymore, it has only newer versions of firmware. I cant find the above firmware that you mentioned before. I don't think that newer firmware versions would work with this driver.
In my case I cant even bring up the wifi interface, it crashes the system while giving a kernel panic when I load the modules. I think it should be related to firmware mismatch between driver and other ProgModel etc files.
I will try to look at that but really I'm pretty sure I didn't had the 131012 firmware either. I've just used a newer one. I'm gonna look at it in the future, but any other 5G AP device I've got now is the second wave300 :-/ . And I'm still waiting on the 3.4 drivers from tp-link anyway
I was also able to debug the error code 0x81d as the stack-trace shows and the output is this:
(gdb) list *0x81d
0x81d is in _mtlk_core_set_wep_key_blocked (/home/ahmar/src/WAVE300/driver/builds/ugw5.1-vrx288/wireless/driver/linux/wireless/driver/linux/core.c:7504).
7501 static int
7502 _mtlk_core_set_wep_key_blocked (struct nic *nic,
7503 const IEEE_ADDR *addr)
7505 int res = MTLK_ERR_UNKNOWN;
7506 mtlk_txmm_msg_t man_msg;
7507 mtlk_txmm_data_t *man_entry = NULL;
7508 uint16 default_key_idx = nic->slow_ctx->default_key;
It seems to me the driver is loading and trying to start the interface but it fails around the authentication methods. Correct me here if needed but I think it's trying to load WEP security protocol and the Key that is being inserted (if any) is not correct and that is why it's failing.
Sorry for not getting back to you about this sooner.
Yes, the latest branch is the master one you found on my repository.
Something changed in OpenWRT in the trunk with respect to the latest release, and I also was getting a similar errror when it came to stripping the modules. Something about: illegal characters during strip of logmacro that is used in many places. I got past this issue by checking out 18.06.2 and issuing a git clean -dfx and wiping and re-downloading all feeds ( they do not get wiped because they are different repositories then the top-level openwrt one.
Sadly it seems to be only a prebuild archive file :-/ but the source codes for rflib are in your repository. Hmm it could be even possible to correlate them with a source code a mark the changes . BTW what the rflib is exactly, something which is communicating directly to the firmware?
The building system of the driver is crazy if I will obtain 3.4 driver from tplink I will probably try to rewrite it.
BTW I managed to build (probably not working) driver, there is bunch of old kernel API which needs to be patched, it seems to be patched in your repo already (mostly /proc file creation API).
No I am not enabling anything apart from the chip itself. This error shows up in gdb but the kernel panic was from the insmod command with ap=1. I think I'll give a try to the new driver. Maybe it can be hooked up and starts to work.
Mmm didn't notice it was prebuilt. I am pretty sure it is distributed like that due to it being under a different license. That sucks, but it may be because it has proprietary RF code that is not licensed under GPL. I believe the code won't build w/o it. Make menuconfig provides a configuration option to provide a prebuilt rflib, so I believe that is the way we should go for now.
I agree, it's pretty crazy. It is not meant to be integrated into OpenWRT or linux, rather, be a platform to build drivers for many different distros.
I hope you do obtain a newer version of the driver, but it may not be in a useful timeframe.
Yeah, me and Mandrake up-ported proc-fs to latest kernels... (surely with a bug or two somewhere, so keep your eyes peeled!)
The other major portion that required updating was the netlink layer, which required work in order to define and allocate generic netlink groups.