rtl8812au wifi dongle on RPi 3

1st Official Post

    Hello,

    I'm getting problems on LibreELEC 8.0.0 with a Fenvi dongle based on rtl8812au chip.

    It seems to work fine but on playback of HD videos, after several minutes, the video freeze and playback stops. It's not a buffering problem, the playback is stopped and exits completely:

    The debug log reports:


    Is the speed to high to loose data on usb bus?

    The dongle as shown in dmesg:


    Any clue? Thank you in advance.

    Edited once, last by giannia (March 9, 2017 at 2:14 PM).

    Hi,
    I'm experiencing a similar problem. I am running LibreELEC on a RPi3 streaming through smb protocol from a RPi2 that I use as a NAS, among other things, with an Edimax EW-7811UTC that uses a rtl8812au chip. Every now and then (a very variable time from 2 to 30 minutes) happens that the stream of mkv files at 720p or 1080p stops. The video freeze for 30 seconds and then goes back to the main menu without restarting the GUI. Going back to the file I was playing, it asks me to restart from where leaved and the playback goes well for other few minutes. The messages from the logs are quite similar to the ones giannia posted.
    I've experienced the problem both with 7.0.3 and 8.0.1 version using smb and nfs. I've also tried to run the movies from a directly connected hard drive and in that case the playback went well.
    I've seen that someone else pointed out a similar problem in this thread: thread-3467-post-29019.html
    According to bd0426, this problem was not present running OpenELEC 6.0.3
    Here is my log: kodi.log - Google Drive (didn't use pastebin because of the size of the log - 413 Request Entity Too Large)

    Any suggestion on how to fix it? Thanks

    Quote from chewitt


    If you want a reliable network experience use Ethernet. It's a sucky answer, but it sucks less than the sh1t quality realtek drivers that we are forced to embed in our otherwise reliable distro.

    Yeah, I'm aware of that. Ethernet cables are always my favorites, but in this case it's not a very good option.
    As far as you know, there are some chipset with drivers that suck less? Buy a new wifi dongle with better performances/drivers support can be a more suitable alternative for me in this case

    Thanks

    Yep, same exact thing happens with my rtl8812au wifi stick under 8.0.x on both pi2 and a pi3.

    But under 7.0.x, it runs perfect, so Ive just downgraded and used the older libreelec. :)

    Maybe not the best, but works for me.

    Edited once, last by gz519 (April 13, 2017 at 11:21 PM).

    Quote from gz519


    Yep, same exact thing happens with my rtl8812au wifi stick under 8.0.x on both pi2 and a pi3.

    But under 7.0.x, it runs perfect, so Ive just downgraded and used the older libreelec. :)

    Maybe not the best, but works for me.

    I experienced this problem under 7.0.3 and upgraded to 8.0.1 hoping to solve. But nothing changed

    My exact usb device is
    Bus 001 Device 004: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter


    Maybe I just got a lucky 8812au that works in 7.0.3

    I even queued up some random 20/30/40 mbit mkvs to play all last night on repeat, and all played with no errors logged and still playing when i woke up this morning.

    Still no idea what changed in the driver that messed things up though. :(

    Thanks for the replies. The issue occurs only using the 5Ghz band, if i connect using the 2.4Ghz band there are no issues!
    I'm lucky and I'm getting at least 50 mbit very stable on 2.4 so I can still use the stick. I got this stick as replacement for the internal RPi 3 WiFi since the built in antenna is very poor and cannot use power line.

    lsusb output:

    Code
    Bus 001 Device 004: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter

    My device is:
    Bus 001 Device 005: ID 7392:a812 Edimax Technology Co., Ltd

    Sadly I need to use 5GHz band, otherwise it keeps buffering while playing high bitrate files. There are too much interferences on 2.4GHz due to the presences of more then ten other WIFIs

    Quote from rha666


    My device is:
    Bus 001 Device 005: ID 7392:a812 Edimax Technology Co., Ltd

    Sadly I need to use 5GHz band, otherwise it keeps buffering while playing high bitrate files. There are too much interferences on 2.4GHz due to the presences of more then ten other WIFIs

    Mine was flaky as well on a pi2 with 8.0.1. I did put the following in a modprobe config file and rebooted:

    rpi3:~ # cat /etc/modprobe.d/8812au.conf
    options 8812au rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1 rtw_vht_enable=0 rtw_ht_enable=1

    This limits the wifi to n instead of ac, so max 150mb/s, but it is stable. Perhaps it will work for you and provide enough bandwidth in the less crowded 5ghz range?

    Quote from zaphod24

    Mine was flaky as well on a pi2 with 8.0.1. I did put the following in a modprobe config file and rebooted:

    rpi3:~ # cat /etc/modprobe.d/8812au.conf
    options 8812au rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1 rtw_vht_enable=0 rtw_ht_enable=1

    This limits the wifi to n instead of ac, so max 150mb/s, but it is stable. Perhaps it will work for you and provide enough bandwidth in the less crowded 5ghz range?


    Thank you very much! Also 5Ghz band is working well now! So, is there a known bug on the ac protocol?

    Edited once, last by giannia (April 29, 2017 at 4:44 PM).

    Quote from zaphod24

    Mine was flaky as well on a pi2 with 8.0.1. I did put the following in a modprobe config file and rebooted:

    rpi3:~ # cat /etc/modprobe.d/8812au.conf
    options 8812au rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1 rtw_vht_enable=0 rtw_ht_enable=1

    This limits the wifi to n instead of ac, so max 150mb/s, but it is stable. Perhaps it will work for you and provide enough bandwidth in the less crowded 5ghz range?

    Thank you very much zaphod24, with this configuration it seems to work perfectly

    Quote from rha666

    Thank you very much zaphod24, with this configuration it seems to work perfectly

    Glad that worked for others. Can't remember where I found that, but it wasn't something I did on my own. I believe the comment I saw at the time was that the Realtek drivers were flaky due to crummy support/code from Realtek and that various developers were having to hack through things to fix them. I'm using the same Edimax USB devices on some RPi2 devices as an access point running hostapd. For those, I found some updated/experimental drivers on github that seem to work ok for other devices connecting in AC mode. I hope that eventually the RTL8812/8821 devices work consistently as a client in AC mode as well.

    Hi rtl8812au users.

    There's a new rtl8812au driver in a recent LE9/Kodi18a1 test build, based on the work done by gordboy.

    The download details and initial feedback (working/stable AC connection) are here, and it would be really great to have more testing and feedback in order for us to make a more informed decision about switching to this new driver.

    Unfortunately this new driver does not support rtl8821au and some other chipsets that the older driver may have supported, so there could be some fallout but hopefully not too much.

    I'll start including this new v5.2.9 driver in future nightly LE9/Kodi 18 builds from tomorrow, Tuesday (#0718).

    I have this device

    {USB_DEVICE(0x7392, 0xA812), .driver_info = RTL8821}, /* Edimax - EW-7811UTC */

    which apparently uses the 8821 and not 8812 driver. Excited that AC might finally work for others, but for now I guess I'm capped at 5.1.5. Is there any hope in getting the 8821 device(s) working with 5.2.9?

    Quote from zaphod24

    I have this device

    {USB_DEVICE(0x7392, 0xA812), .driver_info = RTL8821}, /* Edimax - EW-7811UTC */

    which apparently uses the 8821 and not 8812 driver. Excited that AC might finally work for others, but for now I guess I'm capped at 5.1.5. Is there any hope in getting the 8821 device(s) working with 5.2.9?

    It's possible, but not looking terribly likely at the moment. The new rtl8812au driver doesn't include the HAL support for 8821AU/8814AU, and that's the only drawback to this driver.

    So at the moment a switch away from the old 5.1.5 driver would mean your hardware is no longer supported, but rtl8812au users would have working AC (based on feedback so far).

    I don't know if it will be possible to continue using the older 5.1.5 driver for non-rtl8812au users - we may need to investigate that - or else we stick with the older and somewhat broken driver as that "works" for everyone. Ideally the HAL support for the other chipsets would be merged into this newer driver, giving the same support as before, but it appears that chipset support is becoming a little fragmented with the more recent drivers provided by Realtek.

    Quote from milhouse

    It's possible, but not looking terribly likely at the moment. The new rtl8812au driver doesn't include the HAL support for 8821AU/8814AU, and that's the only drawback to this driver.

    So at the moment a switch away from the old 5.1.5 driver would mean your hardware is no longer supported, but rtl8812au users would have working AC (based on feedback so far).


    I don't know if it will be possible to continue using the older 5.1.5 driver for non-rtl8812au users - we may need to investigate that - or else we stick with the older and somewhat broken driver as that "works" for everyone. Ideally the HAL support for the other chipsets would be merged into this newer driver, giving the same support as before, but it appears that chipset support is becoming a little fragmented with the more recent drivers provided by Realtek.

    No worries. For now, I think it makes sense to get as much testing as possible with the 5.2.9 driver in your test builds (not that my opinion counts anyway :) ). I'm hopeful that by the time Libreelec releases 9.0 that the driver will either be split or the 8821 and 8814 chipsets will be included in 5.2.9 at that point. I'm just glad to year that AC is finally stable for any of these Realtek chipsets. It is really too bad they're not more open with their drivers and firmware.