[8192cu] Enables cfg80211 #1489
Conversation
|
@MrEngman any comments? |
|
Don't merge it yet, I'm having some problems with the connection it gets a bit spotty as it runs for some time. |
|
Fixed, it seems to be working now. |
|
Hi @popcornmix, First I must apologise for not responding sooner but I've not been too well for the last couple of weeks. Recovering now but then I received your request for comment and that gave me a real shock and I'm just recovering from that :) I feel really honoured to be asked for my opinion. I must say that I've been involved with wifi on the Pi pretty much since it first appeared, compiling a variety of out of tree drivers, and I guess am one of the reasons the 8192cu driver was included in the image, however, compiling wifi drivers and actually knowing how they work are two completely different matters. However, I do think it would be good to update the driver. I have updated the driver on one of my Pi's and have been running tests transferring data back and forth from the Pi 2 B and a Win7 laptop for the last couple of days and it would appear to be running without any problems. @fran6co looks to have done a good job. There is just one minor alteration I made. In the past I had noticed when compiling the kernel that there was a warning from the 8192cu driver and this was still there when I compiled the kernel before applying @fran6co's update - I applied an additional patch to remove that warning. I have used the same patch on other Realtek drivers. The patch is - |
|
I'm not sure, Perhaps you should wait for @popcornmix to suggest where. |
|
Could you review those changes too? |
|
@popcornmix I did add his patch to #1488. 2bb47d2 |
| WLAN_CAPABILITY_ESS, WLAN_CAPABILITY_ESS); | ||
| #else | ||
| IEEE80211_BSS_TYPE_ESS, IEEE80211_PRIVACY_ANY); |
|
checkpatch has lots of issues with it - see https://gist.github.com/pelwell/e42758ee8cbe2ca864c6eb0452df54f6. |
|
@pelwell I didn't run checkpatch... I'll fix all those issue. |
|
OK - when that's fixed and you've squashed them to one patch I'm happy for it to be merged. |
|
Most of those errors and warnings that come from the realtek driver (for example C99 stuff). Should I create a new commit fixing all that stuff in all the realtek code? |
|
I'd say it's probably not worth fixing warnings from the existing realtek driver. But any code you change would be better to match what upstream prefers. |
|
There are some warning I can't fix, the code uses |
|
Same goes for the use of |
|
I think it should be all or nothing with this, the realtek driver doesn't comply to any of the Linux standards. I could clean and reformat the code to do so but if this driver is not going to be merged upstream I don't see the point. If I just clean this patch, it's going to be a mismatch of code styles in an already messy code. |
|
Yes, I think getting the whole realtek driver through checkpatch is too big a job. @pelwell are you okay with how it is currently? |
|
Yes. Let's hope it has a short life. |
|
Yes, we should start building the upstream driver, with it disabled by default, but easily enabled. @MrEngman / @fran6co do you know which driver gets used if the kernel is built with both the upstream and realtek drivers? |
|
Just tested, it loads the upstream one. |
|
Okay, it would have been easier if it were the realtek one. |
|
Yeah, I'm using |
|
If you have time to play around with this, you probably also want to enable the upstream rtl8xxxu driver and test that with 8188CUS and 8192CU chipsets. |
|
Squashed the commits |
|
@popcornmix WARNING I've got a feeling that the merging of this PR is the reason that none of the 6 Pi's with 8188 dongles I have in my test group, have re-appeared on the network since I updated the kernel an hour ago and rebooted them! |
|
@clivem would be good if you can confirm that reverting this commit fixes it. |
|
@popcornmix Yes, I'll investigate later. Sorry, not in the same physical location that they are, right now. And as is always the case, when you need it, none of those 8188 dongled units are one of the 3 units that have a USB serial console cable plugged into the NUC sat next to them. I think I need to make a bulk purchase of USB serial cables, and daisy chain a few USB hubs back to the NUC, so I have a serial console for each one of the units in the test group. One rainy day...... |
|
Just compiled the updated kernel and the warning when compiling the 8192cu driver I mentioned earlier in this issue is still there. What happened to the patch to fix it? Does the update not include the patches in #1488 where I think my patch ended up in? I initially tested the updated driver with just #1489 but then also added #1488. No obvious differences in operation. Just going to check with 8188eu wifi but don't expect to find any problems But you never know.... ;) |
Eh, I thought the 8188 chip with EU suffix uses a completely different driver, not 8192cu driver? Can the person who submitted the pull request, actually tell me what the supposed benefit of this patch is? It is supposed to result in the kernels cfg80211 being used, rather than the the Realtek code that is bundled with the out-of-tree driver? |
|
So what wifi dongles are you using, 8188?? Just assumed 8188 referred too 8188eu. |
|
@clivem This PR enables the cfg80211 interface to the driver that lets you use more modern tools to manage the dongles like |
|
For example I needed this patch to use the Pi as a WiFi repeater |
|
Probable should have been here in #1489 then. |
|
@popcornmix I've just gotten a third party to pull the power on those 6x RTL8188CUS equipped Pi's and swap the dongles for MT7601U's. 5 are now back on the network. (The one that isn't is probably going to require re-imaging due to having the power pulled.) From what I can see in the logs, the 8192cu driver did load, but the interface (wlan0) wasn't created and they never even attempted to associate with one of the AP's. Which wouldn't be too surprising on the basis that the interface wasn't created....... There are no errors in the logs. It just seems to be that with this patch, the interfaces never got created. Needs further investigation tomorrow. |
|
@clivem what are you using for setting up the interfaces? I'm using |
|
@fran6co Yes, the patch is for > 3.13, but also additionally > 3.14. But it is not in the update, hence the warning when compiling is still there. |
NetworkManager...... Which seems to be the problem. This patch results in the network interface no longer being visible to NetworkManager, so it cannot be managed by NetworkManager....... Which wasn't a problem for the last 3 and a half years, prior to this patch. This patch might be enabling the functionality you need for hostapd, but it is breaking compatibility with NetworkManager, which has worked ever since the vendor 8192cu driver was made the default RPi driver for 8188CUS/8192CU. |
|
I never intended for this PR to be released into the wild without #1488. I think your problem comes from pvaret/rtl8192cu-fixes#23 that is fixed in the other PR. |
|
If you do find some extra time to test #1488 on top of this PR it would be great. |
See: raspberrypi/linux#1524 kernel: 8192cu: Enable cfg80211 and various fixes See: raspberrypi/linux#1489 See: raspberrypi/linux#1488 firmware: dt-blob: Don't statically set i2c0 function on pins firmware: image_fx: Mask off unwanted flags from generated frames firmware: raspivid: Add option -lev/--level to raspvid to select H264 Level
See: raspberrypi/linux#1524 kernel: 8192cu: Enable cfg80211 and various fixes See: raspberrypi/linux#1489 See: raspberrypi/linux#1488 firmware: dt-blob: Don't statically set i2c0 function on pins firmware: image_fx: Mask off unwanted flags from generated frames firmware: raspivid: Add option -lev/--level to raspvid to select H264 Level
|
I crosspost from cfg80211 #631. Just did a rpi-update which brought 4.4.27+ Problem is still existing. |
See: raspberrypi/linux#1524 kernel: 8192cu: Enable cfg80211 and various fixes See: raspberrypi/linux#1489 See: raspberrypi/linux#1488 firmware: dt-blob: Don't statically set i2c0 function on pins firmware: image_fx: Mask off unwanted flags from generated frames firmware: raspivid: Add option -lev/--level to raspvid to select H264 Level
|
uname -a eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 lsusb -v -D /dev/bus/usb/001/005 |
Got some patches from https://github.com/pld-linux/rtl8812au