Results 1 to 24 of 24

Thread: Old AWUS036H vs new AWUS036ACH - performance comparison

  1. #1
    Join Date
    2017-Dec
    Posts
    4

    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?



    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.
    Last edited by i64X; 2017-12-30 at 21:40.

  2. #2
    Join Date
    2017-Dec
    Posts
    21
    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.
    Last edited by Trace; 2017-12-31 at 04:40.

  3. #3
    Join Date
    2017-Dec
    Posts
    21
    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?

  4. #4
    Join Date
    2017-Dec
    Posts
    21
    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 ...

  5. #5
    Join Date
    2017-Dec
    Posts
    4
    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.

  6. #6
    Join Date
    2017-Dec
    Posts
    21
    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 ...

  7. #7
    Join Date
    2017-Dec
    Posts
    21
    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! ...

  8. #8
    Join Date
    2017-Dec
    Posts
    4
    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.

  9. #9
    Join Date
    2017-Dec
    Posts
    21
    Quote Originally Posted by cowmooflage View Post
    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.

  10. #10
    Join Date
    2017-Dec
    Posts
    4
    Quote Originally Posted by Trace View Post
    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 :-)

  11. #11
    Join Date
    2017-Dec
    Posts
    4
    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. :-/

  12. #12
    Join Date
    2017-Dec
    Posts
    21
    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 ...

  13. #13
    Join Date
    2017-Dec
    Posts
    4
    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.

  14. #14
    Join Date
    2017-Dec
    Posts
    21
    Quote Originally Posted by i64X View Post
    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 ...
    Last edited by Trace; 2018-01-04 at 02:05.

  15. #15
    Join Date
    2017-Dec
    Posts
    21
    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 ...

  16. #16
    Join Date
    2017-Dec
    Posts
    21
    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.

  17. #17
    Join Date
    2016-Dec
    Location
    California
    Posts
    18
    I got this to measure usb current:

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

  18. #18
    Join Date
    2015-Nov
    Location
    Australia
    Posts
    187
    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?
    ----------------------------------------
    https://re4son-kernel.com
    - - - - - - - - - - - - - - - - - - - - - -
    Check out "Sticky Fingers Kali-Pi":
    https://re4son.com/kali-pi

    Now with mana-toolkit and more goodies!

  19. #19
    Join Date
    2017-Dec
    Posts
    21
    Quote Originally Posted by re4son View Post
    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 ...

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

    Are you using this with an AC router?
    Last edited by Trace; 2018-01-05 at 19:06.

  20. #20
    Join Date
    2015-Nov
    Location
    Australia
    Posts
    187
    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

    Enjoy a wee nip of lagavulin and some haggis around the log fire, I'm off to the beach now
    Last edited by re4son; 2018-01-06 at 00:32.
    ----------------------------------------
    https://re4son-kernel.com
    - - - - - - - - - - - - - - - - - - - - - -
    Check out "Sticky Fingers Kali-Pi":
    https://re4son.com/kali-pi

    Now with mana-toolkit and more goodies!

  21. #21
    Join Date
    2017-Dec
    Posts
    21
    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 ...

  22. #22
    Join Date
    2018-Feb
    Posts
    1
    I have exactly the same problem, is there any solution?

  23. #23

    Exclamation Urgently!

    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;
    }

  24. #24
    Join Date
    2017-Dec
    Posts
    21
    Quote Originally Posted by RUSSIAN_BEAR View Post
    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

Similar Threads

  1. how performance of kali linux on raspberry pi ?
    By gufkl in forum ARM Archive
    Replies: 13
    Last Post: 2017-10-27, 21:54
  2. raspberry pi b+ performance tweaks
    By i8igmac in forum ARM Archive
    Replies: 0
    Last Post: 2015-03-16, 23:53
  3. optimize the performance of kali
    By Lancha in forum General Archive
    Replies: 1
    Last Post: 2014-01-17, 09:09

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •