Problem with rflib is that it had some specific compilation options and in theory you have to set the identical configuration. Practically I sometimes write empty functions to satisfy binary bloob dependencies.
Which symbols are missing?
It was some locking dependent on debug I think, but the problem was the precompiled v3.4 rflib archive doesn't contain the support for wave300, only the newer ones (probably wave300+).
I've used 3.5 rflib source codes, but they must be backported for 3.4 base driver.
OK, I was able to see wave300 AP essid on another machine. But it constantly crashes under almost any situation. STA mode will be almost impossible to run, maybe only with old drivers (3.1/3.2). It seems it doesn't have the expected ABI and as the real last STA firmware was in 3.2 it wasn't most likely developed for a long time. There may be some patches in DWR-966 sources (custom tree?). I've used only the vanilla tarball.
Firmware files:
cal_wlan0.bin - seems to be an alternative EEPROM (country, bg/a, revision defs), do not use, not required
ap_upper_wave300.bin - Accesspoint mode interfacing, MIPS (any "3.4" in version string should be compatible)
sta_upper_wave300.bin - Station mode interfacing, MIPS (magic cookie doesn't match ABI), mutually exclusive with ap_upper
contr_lm.bin - "lower" (?) interface, MIPS (any "3.4" in version string should be compatible)
ProgModel_BG_nCB_wave300.bin - PHY firmware
ProgModel_BG_nCB_3D_RevB_wave300.bin - HW firmware
| | | |
| | | +-- HW revision, values defined in eeprom
| | +------- HW type, 0x3D seems to be the newest, but some cal_wlan0 are 0x43
| +----------- 20/40 MHz bandwidth support?
+--------------- 11a or 11bg (2.4GHz or 5GHz)
no hostapd, wpa_supplicant etc. support yet ...
Actually contr_lm is a firmware for lower mac (driver<-->HW communication), and ap or sta firmware is for upper (MAC layer = FullMAC device). ProgModels are only calibration data; they are requested on scanning.
I think the old hostapd with a set of patches is the only way to run this card in OpenWRT.
@pc2005 is the crash message the same as previously?
1 Like
Thanks for the explanation what exactly upper/lower firmware is. So the upper firmware will basically send the ethernet frame in some buffer?
Anyway I've discovered the problem with sta_upper (ABI magic value is not detected in non "ap=1" mode) is even before any firmware gets loaded, so there will be a bug in the driver. (I'm a little bit confused, why you need two separate firmwares for AP/STA modes, usb dongles needs just one 
).
Not exactly, I'm able to see the traffic in 802.11a mode, but of course 802.11n has required encryption.
The one with network groups is gone, I backported the code from v5.3. But still the driver sometimes crashes (almost every error, even trivial one is coded to emit kernel panic). There are bugs in object tracking. Probably some pointers gone wrong (in pieces of v5.3 code there was things like fixed pointer references :-/ ).
The "only" problem now is the driver receives damaged buffers where in an ethernet frame there is missing the first octet of a protocol type:
00 09 86 00 00 00 00 1b 77 03 d6 bf 00 45 00 05
needs to be
00 09 86 00 00 00 00 1b 77 03 d6 bf 08 00 45 00 05
1 Like
Version 3.4.2.0.42 in router Arcadyan HomeBox 2 6441 (not rflib)
arcadyan email for inquiries (I have not tried it)
opensource@arcadyan.com
1 Like
Thanks, good find!
I will compare later what got changed from 03.04.02.00.25.
edit: There is just addition of few functions for interferences and rx duty cycle (?) and some function moving around. Somebody can send patches later 
Yes it works! (at least in nonencrypted 802.11a mode)
Two main problems (+ code ugliness vs -Wall of new gcc and 4.14 kernel compatibility): There is a header file which is used for packed and not packed structures it is included multiple times, always before the structure. There was a collision with some other header which included it and resulting structure was not packed even it need to be (that's why bad offset). The second problem was with kernel compatibility, where two MAC address match returned a "true" value and the driver expected "false" value 
.
Gonna delete my asserts from the code, check the 3.4.2.0.42 (but more importantly 5.3) and upload it somewhere.
I think if it's possible you should create a github repo and put your final work there that can be tested on other devices, through building the code maybe. It will also help others suggest any improvements to the driver and the code overall.
According to this github, there is wave300 (actually wave400, but they are usually distributed together) firmware in Dlink DWR956 too. No source codes though. The version is older than in DWR-966.
Wut? Did you manage to ping the router across wifi?
Is this change that you are referring to?
-return compare_ether_addr(addr1, addr2);
+return ether_addr_equal_unaligned( addr1, addr2);
Keep up the good work!
Even iperf ... about 22Mbps (but it is only 11a mode)
Yeah most likely I didn't use patches from your repo yet I wanted to dig into the code so I could learn how it works.
1 Like
I think this is really good so far. With the last driver, which @vittorio88 and others were working on, I believe they were not able to get any connectivity, not even an IP, well I wasn't even able to get it to work to start the wifi. But this seems a lot of good progress and I think we maybe able to make it work and support some devices which weren't attractive because of the driver. One of those is HomeHub 4 which uses both bands with Wave300.
Your work is really appreciated.
A beta version (it will take me time to learn github ). Will do a proper version in few days.
Read README file first!
Use the firmware from DWR-966.
There are still lots of uncommited changes, but this should be the working version (notice murphy's laws 
). If you find some problems send it here.
P.S. You will notice some changes in the Kconfig system (I've updated it from the kernel).
Amazing!
Cool, feel free to PM messages regarding git or Github.
If I may, here is how I suggest you proceed with Github:
- Create a new repo using github.com interface ( do not create a README.md at this time. )
- Using git shell, do the following steps to "overwrite" your new empty repository with the one you have already started. (using my repo as example, you should use yor newly created one)
$ git remote add origin remote https://github.com/vittorio88/WAVE300.git
# Sets the new remote
$ git remote -v
# Verifies the new remote URL
$ git push origin master
# Pushes the changes in your local repository up to the remote repository you specified as the origin
I suggest that you take the following precautions while doing this:
- The first commit should just contain the untouched sources and the tarball it comes from should be mentioned as part of the first commit message.
- When you extract the tarball and perform this first commit, if you extract it in Windows you will break file permissions and ownership data. Ideally you would do this exclusively in linux, but if you use Windows, I believe the file permissions and ownership data will be preserved if you use WSL.
Note: If you didn't take these precautions, you can recreate the repository and its commits from scratch or there are commands with which you can "rewrite commit history". If you believe you need to "rewrite commmit history", you should do this before uploading to Github, because it will break merging with eventual forks that may be created from your sources. Feel free to ask me if you need rename the first commit, compress multiple commits into one, or re-implement a commit.
Cheers! 
1 Like
Yeah, but the rflib part will be difficult (come from different sources).
Anyway, 11n tested. On 1 spatial stream (150Mbps) the speed is up to 120Mbps notebook→wave300 and about 22Mbps wave300→notebook. The TX from lantiq is slow (as usual 
). Hostapd is not required, but the connection is insecure and open (not recommended for a normal use).
I don't have any working 1+ spatial stream device (and STA mode for the second tplink doesn't work). Only other 5GHz 11n device I have is rockpro64, where wifi is disabled due to bugs .
edit: nevermind, now are both ways over 100Mbps
1 Like
I wouldn't include it in the WAVE 300 repo just for that reason. Possibly, in the README.md explain where and how to get it before compiling.
Well that may be problematic to do, the current rflib source came from that broken phicomm tarball. It was partially validated against decompiled/disassembled wave400 object files and then minor patched for 3.4 driver. I may (will) use a different commit for that, but manually adding the files every new driver version will be hell to use for anybody else.
1 Like
So if we need to use rflib then I think we can just create another github repo for it. In the readme file you can mention my given link to the phicomm tarball and also provide a caution that it's broken or whatever and however you compiled it. Then maybe further changes can go beyond that. I'm not sure if it's possible but just a newbie thought.
1 Like
about spatial stream/antenna,configuration is in eeprom and psd.bin,so we need to make new psd.bin when we use other firmware,if not we will get some bugs