Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Dear misterx,

Thank you for your help.  I included the information for the internal Wi-Fi card with driver rtw_8822ce for informational purposes. I wanted to indicate that a device using a driver other than the rtl8812au does not have an issue when the kernel is upgraded to 5.13.0-48-generic. 

Below is the procedure I have followed to install the rtl8812au driver:

sudo rm -rf rtl8812au
sudo apt install dkms build-essential git -y
git clone https://github.com/aircrack-ng/rtl8812au.git
cd rtl8812au/
make && sudo make install

I have checked the content of dmesg.  I used the command 'sudo dmesg | grep -i 88XXau'.  Below is the output of the message:

[sudo] password for wtap-sd1:
[ 5.948689] 88XXau: loading out-of-tree module taints kernel.
[ 5.949679] 88XXau: module verification failed: signature and/or required key missing - tainting kernel
[ 14.217528] usb 1-2: 88XXau 9c:c9:eb:2c:fd:21 hw_info[d8]
[ 14.218451] usbcore: registered new interface driver rtl88XXau

Thank you for your help.  I appreciate it.

I'm a bit confused. What does the internal adapter with rtw_8822cw have to do with this?

What github and what branch of rtl8812au are you using?

Have you checked dmesg/journalctl for issues?

Dear Aircrack-ng Forum,

I have been using an internal Wi-Fi card and external Wi-Fi adapters with the Ubuntu 20.04.4 LTS release.  The kernel version I have been using is 5.13.0-44-generic.  The driver for the internal Wi-Fi card is rtw_8822ce and for the external Wi-Fi adapters is rtl8812au.  I had not observed any issues with this configuration. 

A clean install was performed on the desktop computer.  The kernel version had gotten upgraded to 5.13.0-48-generic.  When I connected the external Wi-Fi adapter to the desktop computer and installed the driver, it could no longer associate with the router.  Once I checked the Wi-Fi adapters in the 'Settings' menu of the Ubuntu desktop environment, the name of the external Wi-Fi adapter had gotten corrupted.  I did not observe any issues with the operation of the internal Wi-Fi card when the kernel had gotten upgraded to 5.13.0.48-generic.

I appreciate it if you can provide any insight into the problem I am observing.  Thank you.

wlan0mon is just a name. It was renamed from wlan0 to show there is monitor mode, again, just to show it.

This driver doesn't, so you only get wlan0. And all the tools work just the same.

Hi, newbie here.
I can't get from Wlan0 to Wlan0mon, but the mode is Monitor.

Win10
ALFA AWUS036ACS

Code: [Select]

┌──(kali㉿kali)-[~]
└─$ cat /etc/os-release
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
ID=kali
VERSION="2022.2"
VERSION_ID="2022.2"
VERSION_CODENAME="kali-rolling"
ID_LIKE=debian
ANSI_COLOR="1;31"
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
                                                                                                         
┌──(kali㉿kali)-[~]
└─$ uname -a

Linux kali 5.16.0-kali7-amd64 #1 SMP PREEMPT Debian 5.16.18-1kali1 (2022-04-01) x86_64 GNU/Linux
                                                                                                         
┌──(kali㉿kali)-[~]
└─$ iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wlan0     IEEE 802.11AC  ESSID:"WiFimodem-3815"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:5.3 GHz  Access Point: 44:AD:B1:2C:38:1B   
          Bit Rate:434 Mb/s   Sensitivity:0/0 
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=45/100  Signal level=-30 dBm  Noise level=0 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

                                                                                                         
┌──(kali㉿kali)-[~]
└─$ sudo airmon-ng check kill
[sudo] password for kali:

Killing these processes:

    PID Name
   1693 wpa_supplicant

                                                                                                         
┌──(kali㉿kali)-[~]
└─$ sudo airmon-ng start wlan0


PHY     Interface       Driver          Chipset

phy0    wlan0           88XXau          Realtek Semiconductor Corp. Realtek 8812AU/8821AU 802.11ac WLAN Adapter [USB Wireless Dual-Band Adapter 2.4/5Ghz]
                (monitor mode enabled)

                                                                                                         
┌──(kali㉿kali)-[~]
└─$ sudo airmon-ng           

PHY     Interface       Driver          Chipset

phy0    wlan0           88XXau          Realtek Semiconductor Corp. Realtek 8812AU/8821AU 802.11ac WLAN Adapter [USB Wireless Dual-Band Adapter 2.4/5Ghz]

                                                                                                         
┌──(kali㉿kali)-[~]
└─$ iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wlan0     unassociated  ESSID:""  Nickname:"<WIFI@REALTEK>"
          Mode:Monitor  Frequency=2.457 GHz  Access Point: Not-Associated   
          Sensitivity:0/0 
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=0/100  Signal level=0 dBm  Noise level=0 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
What to do?

Ok, I didn't know that it's not possible, it was just a concept. Thank you for your precious time.

That's not how things work. You are lacking knowledge on the 802.11 protocol.

If you have a whitepaper published, or if you pass your CWNP, we can revisit this topic.

> Is there a document that explains how we can reproduce this?
I'm fairly new to the domain, this is just a concept but I really believe it's feasible in some way.

> They can only send one packet at a time the same way a wired network card does.
Exactly, this is why I think it would work.
What Slowloris does is that it sends requests to a web server as slowly as possible, little by little; and just before the webserver thinks the client is gone and closes the thread, Slowloris continues its unfinished request.
If there's a way to send an unfinished packet, and the default behaviour of routers is to wait for the following packets, then this is definitely feasible.
I think there are two parts of this attack that are worth trying:
1. Send packets at low speed. This would help waste the router's time exchanging with other devices.
2. Send partial packets and let the router wait. Just before the router quits the program continues and lets the router wait again. (I don't know the default behaviour of routers on this yet.)
This combined with MAC address spoofing, we could let the router think that there are different clients that are not having a good connection, and hence upscale the attack. (While the router is waiting we could sent more partial packets to it using different MAC addresses)

With this said I don't have the required knowledge to build low-level software to send some partial requests at low speed, what do you think?

Thank you

After more than 2 years, we are making a release with a decently large amount of fixes, improvements, and additions. We also broke the 4000 commits barrier, and this release has more than 400 commits.

Noticeable changes and fixes are present in a number of tools: airodump-ng, aircrack-ng, airdecap-ng, airmon-ng, aireplay-ng, airgraph-ng, besside-ng. And also osdep, our os-dependent interface for Wi-Fi capture and injection, as well as WPE patches for freeradius and hostapd.

On the less visible side, we get a number of improvements and fixes as well. We did code refactoring, deduplication, cleanup, code style fixes, as well as miscellaneous improvements. We also fixed a bunch of typos, spelling, and wording issues across the board. We fixed a number of issues reported by different static analysis tools we use, among others, PVS-Studio, Coverity Scan, Infer.

Read more in our blog post, or head to the download page.

And finally, the full changelog:

• Airdecap-ng: Endianness fixes
• Airdecap-ng: Output PCAP as little endian
• Airodump-ng: Fixed blank encryption field when APs have TKIP (and/or CCMP) with WPA2
• Airodump-ng: Updated encryption filter (-t/--encrypt) for WPA3 and OWE
• Airodump-ng: Fixed out-of-order timestamp captures
• Airodump-ng: Ignore NULL PMKID
• Airodump-ng: Fixed dropping management frames with zeroed timestamp
• Airodump-ng: Fixed sorting where sometimes it started with a different field
• Airodump-ng: Allow setting colors only in AP selection mode
• Airodump-ng: Fix crash on 4K Linux console
• Airodump-ng: Fixed issue where existing clients not linked to an AP become hidden when hitting 'o'
• Airodump-ng: Allow use of WiFi 6E 6GHz frequencies
• Airodump-ng: Look for oui.txt in /usr/share/hwdata
• Airgraph-ng: Fixed graphviz package conflict
• Airgraph-ng: Fixed downloading OUI with python3
• Airgraph-ng: Ensure support/ directory is created when installing
• Aircrack-ng: Fixed static compilation
• Aircrack-ng: Fix handshake replay counter logic
• Aircrack-ng: Handle timeout when parsing EAPOL
• Aircrack-ng: Fixed WEP display
• Aircrack-ng: Fixed spurious EXIT messages
• Aircrack-ng: Improved handshake selection by fixing EAPOL timing and clearing state
• Aircrack-ng: Ignore NULL PMKID
• Aircrack-ng: Added Apple M1 detection
• Aireplay-ng: In test mode, detect tampering of sequence number by firmware/driver
• Aireplay-ng: Fixed incorrectly rewritten loops affecting fragmentation attack, and in some cases, SKA fake auth
• Aireplay-ng: Fixed a bunch of instances where packets had their duration updated instead of the sequence number
• Airmon-ng: Fix avahi killing
• Airmon-ng: rewrite service stopping entirely
• Airmon-ng: Codestyle fixes and code cleanup
• Airmon-ng: Added a few Raspberry Pi hardware revisions
• Airmon-ng: Fixes for 8812au driver
• Airmon-ng: Fix iwlwifi firmware formatting
• Airmon-ng: Remove broken KVM detection
• Airmon-ng: Show regdomain in verbose mode
• Airmon-ng: Updated Raspberry Pi hardware revisions
• Airmon-ng: Document frequency usage
• Airmon-ng: Add a sleep to help predictable names due to udev sometimes renaming interface
• Airmon-ng: Added warning for broken radiotap headers in kernel 5.15 to 5.15.4
• Airmon-ng: shellcheck fixes
• Airmon-ng: support systemctl as some systems don't support 'service' anymore
• Airmon-ng: Fixes for pciutils 3.8, backward compatible
• Airbase-ng: use enum for frame type/subtype
• Airbase-ng: remove a few IE in association responses
• Besside-ng: Support and detect all channels in 5GHz in Auto-Channel mode
• OSdep: Search additional IE for channel information
• OSdep: Android macro fixes
• Patches: Add missing patches that were on https://patches.aircrack-ng.org but not in repo
• Patches: Updated freeradius-wpe patch for v3.2.0
• Patches: Updated hostapd-wpe patch for v2.10
• Patches: Added docker containers to test WPE patches
• Autotools: make dist now creates VERSION file
• Autotools: Added maintainer mode
• Autotools: Initial support for Link Time Optimization (LTO) builds
• Integration tests: Added a new test, and improved some existing ones
• Airgraph-ng: switch airodump-join to Python 3
• Manpages: Fixes (typos, tools name, etc.) and improvements
• README: Updated dependencies and their installation on various distros in README.md and INSTALLING
• README: Fixed typos and spelling in README.md and INSTALLING
• Packages: Packages on PackageCloud now support any distro using .deb and .rpm, however, it requires reinstalling repo (BREAKING CHANGE)
• General: Fix compilation with LibreSSL 3.5
• General: Fix issues reported by Infer
• General: Updated buildbots
• General: Add Linux uclibc support
• General: Compilation fixes on macOS with the Apple M1 CPU
• General: Removed TravisCI and AppVeyor
• General: Use Github Actions for CI (Linux, Win, macOS, code style, and PVS-Studio)
• General: Added vscode devcontainer and documentation
• General: Fix warnings from PVS-Studio and build with pedantic (See PR2174)
• General: Shell script fixes thanks to shellcheck
• General: Fixes for GCC 10 and 11
• General: Fixed cross-compilation
• General: Code refactoring, deduplication, cleanup, and misc code improvements
• General: Coverity Scan fixes, which includes memory leaks, race conditions, division by 0, and other issues
• General: PVS Studio improvements,fixes and updates
• General: Code formatting/style fixes
• General: Various fixes and improvements (code, CI, integration tests, coverity)
• General: Update bug reporting template and update the process

Is there a document that explains how we can reproduce this?

They can only send one packet at a time the same way a wired network card does.