Old AWUS036H vs new AWUS036ACH - performance comparison

I've been using the 36H for a long time now, but being it is 802.11 b/g only, decided to upgrade to a 36ACH, now that it's supported. Oddly enough, it seems like the ACH is quite a bit weaker in terms of what it'll pick up at any given range.

I'm wondering if this is a common thing or if maybe I've got something set up incorrectly. I actually ordered two 36ACHs, and they both seem weaker, so either they're both bad or the old 36H just seems to do a better job at distance.

The below screenshot shows the new 36ACH on the right on the old 36H on the left.

Thoughts?

http://www.i64x.com/pics/alfa.png

For the 36ACH, I wasn't able to use the drivers available from the apt repository that the Kali page suggests, but I found another forum post and was able to compile a different driver. I found that driver here: https://github.com/kimocoder/rtl8812au

I'm not sure if that makes a difference or not.

I'm able to get the new card into monitor mode, although using "airmon-ng start [wlan int]" doesn't work with the 36ACH like it does with the old adapter. For the new one I have to type "link set [wlan int] down && iwconfig [wlan int] mode monitor && ip link set [wlan int] up"

Not a huge deal, just different. I basically have to go through the same steps again to get it out of monitor mode, only use "mode managed" instead of "mode monitor." I'm wondering if there's some compatibility weirdness between these drivers and airodump, since airmon doesn't like doing things the "normal" way with the 36ACH.

Also, I notice that the 36ACH is finding 5Ghz networks almost exclusively, though it does see a couple of 2.4Ghz networks. I would expect the range on 5Ghz networks to be less, and therefore see less of them in the airodump output, but being that it's dual radio, shouldn't it be finding all of the 2.4Ghz networks that the 36H is finding PLUS the 5Ghz networks?

Any insight is appreciated.

Hi i64x ... I'm not a regular Kali user, just ended up on this forum looking for more info on the AWUS036ACH performance in Linux.

I bought the adapter looking for a better wifi connection to an outbuilding we have here and mainly use Debian Stretch although I have also now installed Kali to see if there was any performance increase as some on the forum here seem very happy with it.

I have been using Stretch 9 (Live usb with persistence) and Kali 2017.3 with the 4.13 kernel (Live usb with persistence, packages fully upgraded but can't upgrade the kernel as the live install doesn't allow that so couldn't try the latest 4.15).

First off as I said I was mainly interested in the adapter for it's long range performance which is what it is marketed for ... supposedly although I've not tried it myself yet as I mainly use Linux the performance in windows is excellent.

I have tried loads of the different drivers on both Debian & Kali and have been very let down by the range performance with these drivers. Here's some points I've noticed along the way:

The only drivers I can get to work properly in "managed" mode when plugging the adapter into USB 3 ports on my Dell Optiplex 7010 (Intel i5) are drivers up to 4.3.20 from the many people modding them at Github ... (with these I can see 12+ local AP's and get a 100% connection, 70/70 connection quality) anything newer and I can only see 1 AP (my own router) and find it very hard to connect to it.

TX power seems to be fixed at 12dB with these drivers no matter what changes are made with iwconfig and even going as far as recompiling crda and the regulatory.bin. Which I would guess means that the adapter is still running at a lot lower performance than it is capable of.

So after reading about people's success here ... yesterday I installed Kali 2017.3 (upgraded everything except the kernel (4.13), installed Linux-Headers, Build Essentials, BC, etc, checked with Module Assistant that everything was ready for driver compilation and installed and loaded the latest Kimocoder 5.1.5 driver as instructed here expecting it to work properly and finally be able to up the TX power .... but as it turned out the adapter behaved exactly the same as it has with every other driver after 4.3.20 ... only one AP showing (42% connection) and very difficult to connect to.

Although I didn't think it would make any difference as the adapter is marketed as a usb3 device ... just as a matter of interest I plugged it into one of the usb2 ports and to my surprise another 5 or 6 AP's appeared and the best signal increased to 82% (but would still only be able to connect to one AP in monitor mode) ... this led me to further investigate the port connections with lsusb -t and lsusb -v commands and discovered that the adapter is running at usb2 modes (480m, max500ma current available) when plugged into a usb3 port and on even further investigation this would seem to be intentionally implemented by design as a power saving feature ... the driver will only switch the adapter to full usb3 mode (5000m data rate, 900ma current) on sensing a connection to an AC mode router ... (which I can't test as my router is an older N model). So yes monitor mode was working, I could up the TX power setting .... but still had terrible range compared to the 4.3.20 driver that I use (I don't know if monitor mode works on this though).

If anybody wants to compare range the best range I get here is with this 4.3.20 driver (labelled as Master (4.3.21) but internally 4.3.20) ... https://github.com/astsam/rtl8812au Use the Master branch ... I tried the driver from the actual 4.3.21 branch but the performance was bad. In fact it seems to me here that any of the drivers that incorporate the TX power change option have terrible range performance.

Another thing I noticed is when changing the TX power with Kimocoder's 5.1.5 driver ... it reads as having changed from 12 to 30dB in iwconfig but seems to make no actual practical difference.

I would be interested in what kind of confirmed range the people who are having success with the Kimocoder driver and Kali 2017.3 have? ... whether they are plugging into usb3 or usb2 ports? and also if they are connecting to AC mode routers which switches the driver/port to full usb3 mode and almost doubles the current available to the adapter? I cant help but wonder if this usb2/3 switching on the usb3 ports has an effect on the adapter effective range.

Anyway that's what I've learned so far .... as soon as I've got some more free time I'll try to look into it further but so far for me for just normal "managed" mode wifi ... drivers after 4.3.20 have had terrible range performance and Kali 2017.3 in monitor mode with the Kimocoder driver would have been pretty useless unless the AP's were within 5m of the AWUS036ACH.

One more point just sprung to mind after reading lots of posts here ...

It may be much easier to install drivers properly on a full hard drive installation than it is on a persistant live usb as it seems very difficult (if even possible?) to upgrade the kernel on live persistent usb's and it may be that other parts of the OS are not communicating with the driver properly too during and after installation.

I think this may be why some people find it really easy to install and everything works well and others seem to have all sorts of different errors and bad performance.

Does anybody using a 2017.3 live usb with persistence have all functions: monitor mode, packet injection, TX power changing properly and all working at a confirmed long range?

Just tried again with the latest weekly image (LXDE build if that makes any difference) and full update/upgrade apart from kernel which was 4.14.

Also installed headers, build-essentials and bc ... followed instructions that seem to be working for others:

Code:

---

git clone https://github.com/kimocoder/rtl8812au
cd rtl8812au
make && make install

---

Checked performance first in normal managed mode and same as ever:

When plugged into usb3 port only one AP visible (my own) and couldn't associate with it ... very disappointing it doesn't seem to work at all in usb3 ports here (checked lsusb,dmesg,iwconfig etc. and nothing wrong, modprobed 8812au, lsmod ... tried replugging usb, reboot and tapping my head whilst rubbing my tummy) ... no change.

When plugged into usb2 port 7 AP's visible but not great signal strength.

Changing the TXpower from 18 to 30dB did make a difference when plugged into usb2 this time but still very bad performance:

Code:

---

root@kali:~# iwconfig
wlan0    IEEE 802.11  ESSID:"SKY33505" 
          Mode:Managed  Frequency:2.452 GHz  Access Point: 00:1F:1F:34:1F:24 
          Bit Rate=144.4 Mb/s  Tx-Power=18 dBm 
          Retry short limit:7  RTS thr:off  Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=24/70  Signal level=-86 dBm 
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0  Missed beacon:0

lo        no wireless extensions.

eth0      no wireless extensions.

---

Code:

---

root@kali:~# iwconfig wlan0 txpower 30
root@kali:~# iwconfig
wlan0    IEEE 802.11  ESSID:"SKY33505" 
          Mode:Managed  Frequency:2.452 GHz  Access Point: 00:1F:1F:34:1F:24 
          Bit Rate=144.4 Mb/s  Tx-Power=30 dBm 
          Retry short limit:7  RTS thr:off  Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=56/70  Signal level=-54 dBm 
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0  Missed beacon:0

lo        no wireless extensions.

eth0      no wireless extensions.

---

Then put it into monitor mode:

Code:

---

ip link set wlan0 down
iwconfig wlan0 mode monitor
ip link set wlan0 up

airodump-ng -i wlan0

---

And although it did list a few AP's the signal strength was very low .. :(

What is the minimum reliable signal strength that you guys can work with?

Starting to think this is either PC hardware related (Dell Optiplex 7010 with Intel i5) or the fact that this is a usb live persistant install and that is making a difference to the driver installation.

For just normal managed mode wifi In Debian Stretch (LXDE) this also happens with these latest drivers but when I use the 4.3.20 mentioned above the usb3 ports work properly and I get more than double the AP's with 6 or 7 100%, 70/70 link quality signals ... :confused:

That's a lot of great information. I should have specified how I'm currently running my adapter. It's running on a full hard drive installation of 2017-3, all software updated, and I'm running the Kimocoder drivers as well. I'm able to up the TX power to 30dB. It's good to see that I'm not the only one having issues. I guess for now I'll assume that it's just driver weirdness and hopefully as time goes on the drivers will be improved. I guess for now I'll keep using the trusty 'ol 36H unless I absolutely need to do something on 5Ghz.

Another thing I just found:

When plugged into a usb3 port lsusb -v reports:

Code:

---

Bus 002 Device 004: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
Device Descriptor:
  bLength                18
  bDescriptorType        1
  bcdUSB              3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass        0
  bDeviceProtocol        0
  bMaxPacketSize0        9
  idVendor          0x0bda Realtek Semiconductor Corp.
  idProduct          0x8812 RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
  bcdDevice            0.00
  iManufacturer          1 Realtek
  iProduct                2 802.11n NIC
  iSerial                3 123456
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                9
    bDescriptorType        2
    wTotalLength          83
    bNumInterfaces          1
    bConfigurationValue    1
    iConfiguration          0
    bmAttributes        0x80
      (Bus Powered)
    MaxPower              200mA
    Interface Descriptor:
      bLength                9
      bDescriptorType        4
      bInterfaceNumber        0
      bAlternateSetting      0
      bNumEndpoints          5
      bInterfaceClass      255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0400  1x 1024 bytes
        bInterval              0
        bMaxBurst              4
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0400  1x 1024 bytes
        bInterval              0
        bMaxBurst              4
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0400  1x 1024 bytes
        bInterval              0
        bMaxBurst              4
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0400  1x 1024 bytes
        bInterval              0
        bMaxBurst              4
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x85  EP 5 IN
        bmAttributes          19
          Transfer Type            Interrupt
          Synch Type              None
          Usage Type              Feedback
        wMaxPacketSize    0x0040  1x 64 bytes
        bInterval              1
        bMaxBurst              0
Binary Object Store Descriptor:
  bLength                5
  bDescriptorType        15
  wTotalLength          22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes  0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes        0x00
    wSpeedsSupported  0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport  1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        255 micro seconds
Device Status:    0x000c
  (Bus Powered)
  U1 Enabled
  U2 Enabled

---

So when plugged into a usb3 port the max power (current) the driver allows is 200ma ... this stays the same whether the txpower is set to 18 or 30dB ... :(

When plugged into a usb2 port lsusb -v reports:

Code:

---

Bus 003 Device 007: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
Device Descriptor:
  bLength                18
  bDescriptorType        1
  bcdUSB              2.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass        0
  bDeviceProtocol        0
  bMaxPacketSize0        64
  idVendor          0x0bda Realtek Semiconductor Corp.
  idProduct          0x8812 RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
  bcdDevice            0.00
  iManufacturer          1 Realtek
  iProduct                2 802.11n NIC
  iSerial                3 123456
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                9
    bDescriptorType        2
    wTotalLength          53
    bNumInterfaces          1
    bConfigurationValue    1
    iConfiguration          0
    bmAttributes        0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                9
      bDescriptorType        4
      bInterfaceNumber        0
      bAlternateSetting      0
      bNumEndpoints          5
      bInterfaceClass      255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0200  1x 512 bytes
        bInterval              0
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0200  1x 512 bytes
        bInterval              0
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0200  1x 512 bytes
        bInterval              0
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0200  1x 512 bytes
        bInterval              0
      Endpoint Descriptor:
        bLength                7
        bDescriptorType        5
        bEndpointAddress    0x85  EP 5 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type              None
          Usage Type              Data
        wMaxPacketSize    0x0040  1x 64 bytes
        bInterval              1
Binary Object Store Descriptor:
  bLength                5
  bDescriptorType        15
  wTotalLength          22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes  0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes        0x00
    wSpeedsSupported  0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport  1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        1023 micro seconds
Device Status:    0x0002
  (Bus Powered)
  Remote Wakeup Enabled

---

So it's obvious now why plugging into a usb2 port gives much better performance with the full port current allowance of 500ma available.

What is happening with the usb3 port being restricted to 200ma? ... that explains the really poor performance here with these drivers ... :(

As a matter of interest ... when plugged into a usb3 port what does the lsusb -v command report as the MaxPower for you i64x?

Happy New Year by the way! ... :)

Having exactly the same problems described here with the current kimocoder driver on kali linux 2017.3 64 bit, kernel 4.14.0-kali1-amd64, using the VMware kali image.

I'm running the VM on a MacBook Pro Retina so I'm stuck with 2 USB3 ports and no USB2 port to try, and here the MaxPower reported by lsusb -v is 200mA.

Quote:

---

Originally Posted by cowmooflage

Having exactly the same problems described here with the current kimocoder driver on kali linux 2017.3 64 bit, kernel 4.14.0-kali1-amd64, using the VMware kali image.

I'm running the VM on a MacBook Pro Retina so I'm stuck with 2 USB3 ports and no USB2 port to try, and here the MaxPower reported by lsusb -v is 200mA.

---

You'll have very poor range then ... I get this with all drivers (Kimocoders and others) after version 4.3.20 ... from 4.3.21 onwards the TX power control changing feature was added ... maybe with certain hardware this is having a negative effect.

Just as an example of range difference ... @200ma I can only see my own AP and can't associate with it ... @500ma with the 4.3.20 drivers I can see 17 AP's and have a 100%, 70/70 signal quality connection with 6 or 7 of them (and that's with the TX power @ 12dB) so it should have a lot more performance available if the TX power could be set to 30.

So it's obviously not just me this is happening with then and the AWUS036ACH is definitely not working properly on some usb3 ports.

Maybe it's happening more than some think ... people with lots of AP's very close to them might not notice it as obviously.

I'd love to see what the range would be like at full usb3 port current and TX power set at 30 in Linux ... it's really dissapointing to see it work so well in windows with just the standard driver the OS comes with.

Quote:

---

Originally Posted by Trace

You'll have very poor range then ... I get this with all drivers (Kimocoders and others) after version 4.3.20 ... from 4.3.21 onwards the TX power control changing feature was added ... maybe with certain hardware this is having a negative effect.

Just as an example of range difference ... @200ma I can only see my own AP and can't associate with it ... @500ma with the 4.3.20 drivers I can see 17 AP's and have a 100%, 70/70 signal quality connection with 6 or 7 of them (and that's with the TX power @ 12dB) so it should have a lot more performance available if the TX power could be set to 30.

So it's obviously not just me this is happening with then and the AWUS036ACH is definitely not working properly on some usb3 ports.

Maybe it's happening more than some think ... people with lots of AP's very close to them might not notice it as obviously.

I'd love to see what the range would be like at full usb3 port current and TX power set at 30 in Linux ... it's really dissapointing to see it work so well in windows with just the standard driver the OS comes with.

---

Absolutely right, at 200mA I can only see one AP positioned 3-4 meters away in my house, and I can't even associate with it.

Also I was able to confirm it's not a hardware problem as using the USB device on the host machine's Mac Os X with Alfa drivers I can see at least 20 APs in the area! So I guess it's the drivers. I'll wait for a fix too :-)

Sorry for the delayed responses. All of my replies need to be moderated so it takes half a day for them to show up. I'll do some more testing tomorrow at work when I have access to my laptop and my 36ACH. I do have a cable for my 36H that has a USB micro to two USB type-A interfaces... essentially one is used for data and the other is used to provide additional power. I'll test the 36ACH with that to see if it makes a difference. With the 36H I never even bothered to connect the power-only USB-A portion of the cable to an additional port because it worked fine with only the single USB-A connection. Maybe that'll be the solution? Fingered crossed. haha.

One thing that comes to mind that I don't like is that the Lenovo T450S that I have Kali installed bare-metal on doesn't have colored USB ports... I know it supports USB 3.0, but neither port is blue, so I don't know if one is USB 3.0, or both, or what. :-/

I'm not sure if the main guys that have been modding these drivers have noticed this ... on this page where a few of them are discussing it: https://github.com/abperiasamy/rtl88...inux/issues/12

In post #3 PolishMike talks about the adapter being in usb2 mode and shows his output of lsusb -v which reports it as usb2 with a MaxPower of 500ma

Then in post #4 crazyc proposes a fix to run the adapter in usb3 mode and shows the output of his lsusb -v which now reports the adapter as a usb3 device and everybody is happy and excited about the usb issue ...... BUT

Nobody seems to notice that although the adapter is now reported as being a usb3 device the MaxPower of the adapter is now reported as being only 200ma which is what seems to be killing the range.

I think this range problem is more obvious to me as the main reason I bought the adapter was to get a good connection to an outbuilding we have here through two walls and a wooden fence ... so driver performance is immediately obvious to me whereas if people are pentesting at really close range in e.g. an office setup then this adapter current difference may not be that obvious.

Unfortunately I don't have the ability to modify drivers myself ... all I can do is find as much relevant info as possible and hope that someone who can will spot it ... :)

Did a little more testing. I failed to remember that the interface cable to the 36ACH was a USB 3.0 style mini plug so my aforementioned data/power USB mini cable from the 36H won't work. I plugged in to both of my USB ports with the 36ACH though, which apparently are both USB 3.0, and got the same thing as you did - 200mA on both ports. I then plugged my 36H into each port, and being as it's a 2.0 device, registered at USB 2.0 but showed as being supplied the full 500mA. I'll try to put a note on the GitHub page and hopefully the devs see it.

Quote:

---

Originally Posted by i64X

Did a little more testing. I failed to remember that the interface cable to the 36ACH was a USB 3.0 style mini plug so my aforementioned data/power USB mini cable from the 36H won't work. I plugged in to both of my USB ports with the 36ACH though, which apparently are both USB 3.0, and got the same thing as you did - 200mA on both ports. I then plugged my 36H into each port, and being as it's a 2.0 device, registered at USB 2.0 but showed as being supplied the full 500mA. I'll try to put a note on the GitHub page and hopefully the devs see it.

---

No worries about the delayed responses ... I'm still getting moderated too and it's frustrating waiting for replies to get posted.

That was a good idea to try and test it with a dual power cable ... I don't have one here either that will be suitable ... :(

You'll see then how the range increases when you plug the adapter into a usb2 port but the link and signal quality are still very bad when compared to the 4.3.20 driver I linked to earlier in the thread ... :(

I see Kimocoder has picked up on the issue at Github :) :) :) ... he did have a point that lsusb -v might not be reporting current accurately but it does make sense of the short range of the adapter and it looks now as if none of these main developers had actually noticed that the adapter might be running at very low power.

I had a look tonight at /sys/kernel/debug/usb/devices and interestingly that file reports MxPwr= 800ma for the adapter:

Code:

---

T:  Bus=04 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  3 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=0bda ProdID=8812 Rev= 0.00
S:  Manufacturer=Realtek
S:  Product=802.11n NIC
S:  SerialNumber=123456
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=800mA
I:* If#= 0 Alt= 0 #EPs= 5 Cls=ff(vend.) Sub=ff Prot=ff Driver=8812au
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=85(I) Atr=13(Int.) MxPS=  64 Ivl=125us

---

So who knows what is correct ... at least it's now in the hands of capable developers ... fingers crossed ... :)

I have ordered a short usb3 extension cable so that I can hack it and get an accurate current reading with a multimeter from the 36ACH when it's plugged into usb3 ports ... hopefully arrive in a couple of days, might be Monday though ... :)

Hurray! replies are being posted immediately now ... :)

Anybody know how many mw the 36ACH is at maximum? I can't seem to find the specification anywhere.

If it's 1000mw (1w) ... then 1w @5v = 200ma.

So the problem may be somewhere else ... it'll be interesting to see if there is a difference in actual true current between the 4.3.20 (best range I could find) and 5.1.5 drivers on the same hardware usb3 ports.

I got this to measure usb current:

https://www.amazon.com/PowerJive-Vol...VZMCFKKK2B3CDT

I've connected the 036ACH through an ammeter to a USB3 port and took it for a walk around the neighborhood.
The adapter draws ~200mA under normal operation and spikes to ~500mA when pushed.

It never drew more than 200mA when in monitor mode, which would make sense because it should be the transmitter that draws the most, not the receiver.
When putting in managed mode, I had to walk for two blocks before I lost a few bars and then it started to increase it's power consumption while surfing the Internet.

Not having spent too much time comparing (yet) and playing with the tx power settings, I think that adapter performs rather well with that driver.
It's going to be 40 degrees Celsius tomorrow so I won't be doing any walking but I plan to do some comparisons on Sunday, ok?

Quote:

---

Originally Posted by re4son

I've connected the 036ACH through an ammeter to a USB3 port and took it for a walk around the neighborhood.
The adapter draws ~200mA under normal operation and spikes to ~500mA when pushed.

It never drew more than 200mA when in monitor mode, which would make sense because it should be the transmitter that draws the most, not the receiver.
When putting in managed mode, I had to walk for two blocks before I lost a few bars and then it started to increase it's power consumption while surfing the Internet.

Not having spent too much time comparing (yet) and playing with the tx power settings, I think that adapter performs rather well with that driver.
It's going to be 40 degrees Celsius tomorrow so I won't be doing any walking but I plan to do some comparisons on Sunday, ok?

---

40c! .... wow it's going to be about 4c here in Scotland tomorrow ... :o

Can you translate "two blocks" into metres? ... it sounds a long way?

Are you using this with an AC router?

Two blocks must have been around 150m, before it got above 200mA. It should theoretically boost the transmission power when it's starting to get transmit errors so that would make sense.
I was using an AC router on 5GHz so I wouldn't have to walk that far :D

Enjoy a wee nip of lagavulin and some haggis around the log fire, I'm off to the beach now :p

Using an AC router must be making the difference ... quite a few of us with N routers are only seeing our own AP and having trouble connecting at 5m.

What your describing is how I would expect the adapter to work but it would appear not all are having the same experience ... :(

I have exactly the same problem, is there any solution?

Hello, sorry for my english.
I wanted to buy myself AWUS036ACH, but I see that it has problems with the drivers.
I compared the source code of the versions: master (4.3.20), 4.3.21 and 5.1.5
I drank vodka and found a difference that can be responsible for usb2 / 3
This is in the file os_dep \ linux \ usb_intf.c
Perhaps this is due to a malfunction in usb3, please write this in to the developers, because my English is bad. Suka blyad.

Code:

---

MASTER 4.3.20

static int usb_reprobe_to_usb3(PADAPTER Adapter)
{
        struct registry_priv  *registry_par = &Adapter->registrypriv;
        int ret = _FALSE;
       
        if (registry_par->switch_usb3 == _TRUE) {


                if (IS_HIGH_SPEED_USB(Adapter)) {
                        if ((rtw_read8(Adapter, 0x74) & (BIT(2)|BIT(3))) != BIT(3)) {
                                rtw_write8(Adapter, 0x74, 0x8);
                                rtw_write8(Adapter, 0x70, 0x2);
                                rtw_write8(Adapter, 0x3e, 0x1);
                                rtw_write8(Adapter, 0x3d, 0x3);
                                /* usb disconnect */
                                rtw_write8(Adapter, 0x5, 0x80);
                                ret = _TRUE;
                        }
                } else if (IS_SUPER_SPEED_USB(Adapter))        {
                        rtw_write8(Adapter, 0x70, rtw_read8(Adapter, 0x70) & (~BIT(1)));
                        rtw_write8(Adapter, 0x3e, rtw_read8(Adapter, 0x3e) & (~BIT(0)));
                }



        }
        return ret;
}


4.3.20

static int usb_reprobe_to_usb3(PADAPTER Adapter)
{
        struct registry_priv  *registry_par = &Adapter->registrypriv;
        u8 ret = _FALSE;



#if defined(CONFIG_RTL8812A) || defined(CONFIG_RTL8821A)
        if (IS_HIGH_SPEED_USB(Adapter)) {
                if ((rtw_read8(Adapter, 0x74) & (BIT(2)|BIT(3))) != BIT(3)) {
                        rtw_write8(Adapter, 0x74, 0x8);
                        rtw_write8(Adapter, 0x70, 0x2);
                        rtw_write8(Adapter, 0x3e, 0x1);
                        rtw_write8(Adapter, 0x3d, 0x3);
                        /* usb disconnect */
                        rtw_write8(Adapter, 0x5, 0x80);
                        ret = _TRUE;
                }
               
        } else if (IS_SUPER_SPEED_USB(Adapter))        {
                rtw_write8(Adapter, 0x70, rtw_read8(Adapter, 0x70) & (~BIT(1)));
                rtw_write8(Adapter, 0x3e, rtw_read8(Adapter, 0x3e) & (~BIT(0)));
        }
#else
        rtw_hal_set_hwreg(Adapter, HW_VAR_USB_MODE, &ret);
#endif
        return ret;
}


5.1.5

static int usb_reprobe_switch_usb_mode(PADAPTER Adapter)
{
        struct registry_priv *registry_par = &Adapter->registrypriv;
        HAL_DATA_TYPE *pHalData = GET_HAL_DATA(Adapter);
        u8 ret = _FALSE;

        /* efuse not allow driver to switch usb mode */
        if (pHalData->EEPROMUsbSwitch == _FALSE)
                goto exit;

        /* registry not allow driver to switch usb mode */
        if (registry_par->switch_usb_mode == 0)
                goto exit;


















        rtw_hal_set_hwreg(Adapter, HW_VAR_USB_MODE, &ret);

exit:

        return ret;
}

---

Quote:

---

Originally Posted by RUSSIAN_BEAR

Hello, sorry for my english.
I wanted to buy myself AWUS036ACH, but I see that it has problems with the drivers.
I compared the source code of the versions: master (4.3.20), 4.3.21 and 5.1.5
I drank vodka and found a difference that can be responsible for usb2 / 3
This is in the file os_dep \ linux \ usb_intf.c
Perhaps this is due to a malfunction in usb3, please write this in to the developers, because my English is bad. Suka blyad.

Code:

---

MASTER 4.3.20

static int usb_reprobe_to_usb3(PADAPTER Adapter)
{
        struct registry_priv  *registry_par = &Adapter->registrypriv;
        int ret = _FALSE;
       
        if (registry_par->switch_usb3 == _TRUE) {


                if (IS_HIGH_SPEED_USB(Adapter)) {
                        if ((rtw_read8(Adapter, 0x74) & (BIT(2)|BIT(3))) != BIT(3)) {
                                rtw_write8(Adapter, 0x74, 0x8);
                                rtw_write8(Adapter, 0x70, 0x2);
                                rtw_write8(Adapter, 0x3e, 0x1);
                                rtw_write8(Adapter, 0x3d, 0x3);
                                /* usb disconnect */
                                rtw_write8(Adapter, 0x5, 0x80);
                                ret = _TRUE;
                        }
                } else if (IS_SUPER_SPEED_USB(Adapter))        {
                        rtw_write8(Adapter, 0x70, rtw_read8(Adapter, 0x70) & (~BIT(1)));
                        rtw_write8(Adapter, 0x3e, rtw_read8(Adapter, 0x3e) & (~BIT(0)));
                }



        }
        return ret;
}


4.3.20

static int usb_reprobe_to_usb3(PADAPTER Adapter)
{
        struct registry_priv  *registry_par = &Adapter->registrypriv;
        u8 ret = _FALSE;



#if defined(CONFIG_RTL8812A) || defined(CONFIG_RTL8821A)
        if (IS_HIGH_SPEED_USB(Adapter)) {
                if ((rtw_read8(Adapter, 0x74) & (BIT(2)|BIT(3))) != BIT(3)) {
                        rtw_write8(Adapter, 0x74, 0x8);
                        rtw_write8(Adapter, 0x70, 0x2);
                        rtw_write8(Adapter, 0x3e, 0x1);
                        rtw_write8(Adapter, 0x3d, 0x3);
                        /* usb disconnect */
                        rtw_write8(Adapter, 0x5, 0x80);
                        ret = _TRUE;
                }
               
        } else if (IS_SUPER_SPEED_USB(Adapter))        {
                rtw_write8(Adapter, 0x70, rtw_read8(Adapter, 0x70) & (~BIT(1)));
                rtw_write8(Adapter, 0x3e, rtw_read8(Adapter, 0x3e) & (~BIT(0)));
        }
#else
        rtw_hal_set_hwreg(Adapter, HW_VAR_USB_MODE, &ret);
#endif
        return ret;
}


5.1.5

static int usb_reprobe_switch_usb_mode(PADAPTER Adapter)
{
        struct registry_priv *registry_par = &Adapter->registrypriv;
        HAL_DATA_TYPE *pHalData = GET_HAL_DATA(Adapter);
        u8 ret = _FALSE;

        /* efuse not allow driver to switch usb mode */
        if (pHalData->EEPROMUsbSwitch == _FALSE)
                goto exit;

        /* registry not allow driver to switch usb mode */
        if (registry_par->switch_usb_mode == 0)
                goto exit;


















        rtw_hal_set_hwreg(Adapter, HW_VAR_USB_MODE, &ret);

exit:

        return ret;
}

---

---

I have passed this on to Github ... check out the developers thread here: https://github.com/aircrack-ng/rtl8812au/issues/77