rdesktop is not connecting or freezes after login

[ionutr2015]

Hi,

I'm using your driver on kernel 4.0.x and I have trouble with rdesktop when using 5GHz (802.11ac). rdesktop is not connecting at all or if it's connecting it freezes most of the times after login. Any idea on how to fix it ?

thanks

[joseph-jja]

Device? How about lsusb output? iw list output too?

[ionutr2015]

Device is Edimax EW-7811UTC.

% lsusb Bus 004 Device 005: ID 0458:004a KYE Systems Corp. (Mouse Systems) Bus 004 Device 004: ID 046d:c313 Logitech, Inc. Internet 350 Keyboard Bus 004 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 004: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 003 Device 003: ID 7392:a812 Edimax Technology Co., Ltd Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

% iw list iw list Wiphy phy0 max # scan SSIDs: 9 max scan IEs length: 2304 bytes Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP (00-0f-ac:4) Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * monitor * P2P-client * P2P-GO Band 1: Capabilities: 0x1862 HT20/HT40 Static SM Power Save RX HT20 SGI RX HT40 SGI No RX STBC Max AMSDU length: 7935 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 16 usec (0x07) HT TX/RX MCS rate indexes supported: 0-7, 32 Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps * 5.5 Mbps * 11.0 Mbps * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1](20.0 dBm) * 2417 MHz [2](20.0 dBm) * 2422 MHz [3](20.0 dBm) * 2427 MHz [4](20.0 dBm) * 2432 MHz [5](20.0 dBm) * 2437 MHz [6](20.0 dBm) * 2442 MHz [7](20.0 dBm) * 2447 MHz [8](20.0 dBm) * 2452 MHz [9](20.0 dBm) * 2457 MHz [10](20.0 dBm) * 2462 MHz [11](20.0 dBm) * 2467 MHz [12](20.0 dBm) * 2472 MHz [13](20.0 dBm) * 2484 MHz 14 Band 2: Capabilities: 0x1862 HT20/HT40 Static SM Power Save RX HT20 SGI RX HT40 SGI No RX STBC Max AMSDU length: 7935 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 16 usec (0x07) HT TX/RX MCS rate indexes supported: 0-7, 32 Bitrates (non-HT): * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 5170 MHz 34 * 5180 MHz [36](20.0 dBm) * 5190 MHz [38](20.0 dBm) * 5200 MHz [40](20.0 dBm) * 5210 MHz [42](20.0 dBm) * 5220 MHz [44](20.0 dBm) * 5230 MHz [46](20.0 dBm) * 5240 MHz [48](20.0 dBm) * 5260 MHz [52](20.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5280 MHz [56](20.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5300 MHz [60](20.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5320 MHz [64](20.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5500 MHz [100](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5520 MHz [104](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5540 MHz [108](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5560 MHz [112](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5580 MHz [116](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5600 MHz [120](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5620 MHz [124](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5640 MHz [128](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5660 MHz [132](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5680 MHz [136](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5700 MHz [140](27.0 dBm) (radar detection) DFS state: usable (for 151 sec) DFS CAC time: 60000 ms * 5745 MHz 149 * 5765 MHz 153 * 5785 MHz 157 * 5805 MHz 161 * 5825 MHz 165 * 5920 MHz 184 * 5940 MHz 188 * 5960 MHz 192 * 5980 MHz 196 * 6000 MHz 200 * 6020 MHz 204 * 6040 MHz 208 * 6060 MHz 212 * 6080 MHz 216 Supported commands: * new_interface * set_interface * new_key * start_ap * new_station * set_bss * join_ibss * set_pmksa * del_pmksa * flush_pmksa * remain_on_channel * frame * set_channel * connect * disconnect Supported TX frame types: * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 Supported RX frame types: * IBSS: 0xd0 * managed: 0x40 0xd0 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * P2P-client: 0x40 0xd0 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 software interface modes (can always be added): * monitor interface combinations are not supported Device supports scan flush.

[joseph-jja]

So this driver is the Edimax driver with some fixes applied so it compiles on newer kernels.

Does rdesktop work on 2.4ghz?

[ionutr2015]

It's exactly the driver from this git. No need for fixes to compile on newer kernels.\

Yes, it's working on 2.4 GHz, although it's a little slow.

[joseph-jja]

This git repo is the Edimax driver, from their website. It was added to git and has had some patches so it compiles on newer kernels and some other compile fixes.

[ionutr2015]

Yes, I know. I wanted to say that I didn't do any change to the code from this git.

[ionutr2015]

If I use 40 MHz channel for 2.4 GHz (150 mbps), I get freezes on 2.4 GHz after about 5 minutes of working.

[joseph-jja]

What channel freq do you use on the 5ghz?

[ionutr2015]

I'm using channel 36.

Btw, everthing was ok on kernel 3.x.x from Ubuntu LTS 14.04. I was using the driver from gnab git (https://github.com/gnab/rtl8812au.git) then I switched to fedora 22 and used this driver. Trouble started with kernel 4.0.x.

[harshavardhana]

(https://github.com/gnab/rtl8812au.git) then I switched to fedora 22 and used this driver. Trouble started with kernel 4.0.x.

4.0.x had lot of low level changes in wireless subsystem - it was hard time getting things compiled properly, which could be possibly the reason that there are some potential changes which are missing.

Most of our tests are largely on 3.x.x for Ubuntu 14.04, 15.04 .. LTS

[ionutr2015]

I've actuaĺly been able to compile gnab driver on 4.0.x too with a small change, but the behavior was exactly the same.

[joseph-jja]

I had problems on my raspberry pi running 4.0.7+ and this driver. I found out the problems seem to be exacerbated by a line I added to the file /lib/udev/rules.d/75-persistent-net-generator.rules and kernel 4.x

In that file on the pi it looks something like this

KERNEL!="eth|ath|msh|ra|sta|ctc|lcs|hsi", GOTO="persistent_net_generator_end"

When I changed it to this

KERNEL!="eth|ath|wlan[0-9]|msh|ra|sta|ctc|lcs|hsi*", GOTO="persistent_net_generator_end"

I started having issues. Ubuntu and I think Fedora do this by default, but Ubuntu 14. is on 3.x kernel.

Try removing the wlan[0-9]| in that file and reboot. Also remove the /etc/udev/rules.d/70 file as well.

So far this is just a theory. You can back up those files first

[ionutr2015]

Are those interface names ? In my case the interface name is very different: wlp0s26u1u2 IEEE 802.11AC ESSID:"XXX" Nickname:"WIFI@REALTEK" Mode:Managed Frequency:5.18 GHz Access Point: XX:XX:XX:XX:XX:XX Bit Rate:434 Mb/s Sensitivity:0/0

I don't have that files: % ls /lib/udev/rules.d/pers /lib/udev/rules.d/60-persistent-alsa.rules /lib/udev/rules.d/60-persistent-input.rules /lib/udev/rules.d/60-persistent-serial.rules /lib/udev/rules.d/60-persistent-storage.rules /lib/udev/rules.d/60-persistent-storage-tape.rules /lib/udev/rules.d/60-persistent-v4l.rules

% ls /etc/udev/rules.d/70 ls: cannot access /etc/udev/rules.d/70: No such file or directory

[ionutr2015]

I like that I can work with rdesktop on 5GHz for the whole day. That's of course if I succeed to connect and pass the login step. The rate for rdesktop to connect is about 15-20% and the rate to pass the login step is 10-15%

[joseph-jja]

Yes, that would be interface names. I wonder if fedora is using systemd?

[ionutr2015]

Yes, fedora is using systemd.

[joseph-jja]

Have you tried this driver?

https://github.com/ulli-kroll/rtl8821au

[ionutr2015]

Thanks, I've tried it. It looks like it's about the same.

[ionutr2015]

No, actually it's worst. I get freezes all the time.

[joseph-jja]

It seems there are repos poping up all over github for this driver. I forked this repo to try a few things. The latest changes here https://github.com/joseph-jja/rtl8812AU_8821AU_linux are taken from another repo that seems to have a fix for some delays in the driver. Those delays may be the cause of your issue. Try my branch and if that works for you maybe we can push the changes up to this branch.

[ionutr2015]

Thanks, it is still have trouble connecting. 1 of 3 connections are successful but there are no longer login screen freezes

[joseph-jja]

So your connection success rate is up from 15%-20% to 33%? No more freezes is good.

[ionutr2015]

On kernel-4.1.3-201 rate is 25%, on kernel-4.1.3-200 rate is 33%. Overall the things are much better.

[harshavardhana]

can this be tested again after @joseph-jja fix on #81 ?

[ionutr2015]

Previous version seems better, although I got freezes on login screen again and I had to try for 30 times to connect until I have succeeded.

It looks like the rdesktop session is not correctly closed because when I shut down the windows machine (once a week) it tells me there are other users connected via rdesktop. That machine is only used by me. I usually use hibernate on linux machine without disconnecting the rdesktop session first and maybe that's why the rdesktop session remains active although not functional