Could not inject WiFi packet error message due libpcap error send: Resource temporarily unavailable after issuing wifi.deauth all command (with logs!) about bettercap HOT 13 CLOSED

The problem seems to be solved. But I'd like that someone with more or properly knowledge than I have shed some light. I touch a situation that I don't know how to address to the open source community.

Before closure, I will let that issue open for a couple days more for appreciation from the experts.

@morrownr, I know it's sudden, but do you think this case worth analysis for the sake of MT7612U driver improvement somehow? If I'm not mistaken, you maintain said driver also used by OpenWRT builds. If it's a mistake of mine, just kindly ignore.

About my initial request of extra parameters to Bettercap, and about my adjust for more detailed debug messages, I will try create a PR so the community and @evilsocket can decide if is something usable.

EDIT:

I will keep a fork with above adjusts for personal testing at

• https://github.com/julianoborba/bettercap

Note that in this fork I remove packet_proxy just so I can build straightforward to OpenWRT.
Note there is compiled packages for those adventurous testers.

from bettercap.

Thank you very much for your work. Have a nice life.
@julianoborba

from bettercap.

Could it be a bias: I notice that if I issue wifi.deauth to my AP BSSID, as soon as the clients got dropped, such an error message appeared, but the clients went out, and the handshake was captured right after, as expected. Could it be that the "resource temporarily unavailable" is, de facto, due to the unavailability of the already disconnected AP client? Thus, is the resource in the said message the client?

from bettercap.

Question:

• bettercap/modules/wifi/wifi_deauth.go

  Line 103 in ee35550

  toDeauth := make([]flow, 0)

  
  if toDeauth has a lost AP in it's list, that lost AP should be removed from toDeauth? Like check APs in current session list, and if the target to deauth is present, keep deauthing it.

And I'm not familiar with Go, but I tested a minor adjust that seems to help a little in my case, so please read it as a simple suggestion:

func (mod *WiFiModule) injectPacket(data []byte) {
	// set wifi.inject.wait.unavailable 5000
	var waitResourceTime time.Duration = (5000 * time.Millisecond)

	if err := mod.handle.WritePacketData(data); err != nil {
		if errorMessage := fmt.Sprintf("%s", err); errorMessage == "send: Resource temporarily unavailable" {
			mod.Warning("could not inject WiFi packet: %s", err)
			mod.Session.Queue.TrackSent(uint64(len(data)))
			time.Sleep(waitResourceTime)
		} else {
			mod.Error("could not inject WiFi packet: %s", err)
			mod.Session.Queue.TrackError()
		}
	} else {
		mod.Session.Queue.TrackSent(uint64(len(data)))
	}
	// let the network card breath a little
	time.Sleep(10 * time.Millisecond)
}

func (mod *WiFiModule) sendDeauthPacket(ap net.HardwareAddr, client net.HardwareAddr) {
	// set wifi.deauth.packets 25
	var packetQuantity uint16 = uint16(25)

	// set wifi.deauth.packets.delay 250
	var packetDelay time.Duration = (250 * time.Millisecond)

	for seq := uint16(0); seq < packetQuantity && mod.Running(); seq++ {
		if err, pkt := packets.NewDot11Deauth(ap, client, ap, seq); err != nil {
			mod.Error("could not create deauth packet: %s", err)
			continue
		} else {
			mod.injectPacket(pkt)
		}

		if err, pkt := packets.NewDot11Deauth(client, ap, ap, seq); err != nil {
			mod.Error("could not create deauth packet: %s", err)
			continue
		} else {
			mod.injectPacket(pkt)
		}

		time.Sleep(packetDelay)
	}
}

from bettercap.

Just confirming that in my case, the above adjust was enough to deal with the problem. It's not avoid the problem, it's just give time enough to hardware to recover.

EDIT:

This is not enough, see below.

from bettercap.

Just and update, I'm still comprehending what is happening.

I forked Bettercap and made adjusts just for test (setting delays for example) and add a little more info for detailed debug messages. With that, my impression about "Resource temporarily unavailable" error is that when deauthenticating, for any reason a client in the target access point is perceived as "lost" by Bettercap, the deauth will fail with said message, for me it looks expected (if no clients, no deauthentication would be possible).

So I turned my attention to discover if somehow my Alfa usb antenna was losing data, causing clients from access points to appear as lost from my setup point of view. With that thinking, I found that issue (I know it's for an unrelated chipset as mine is not RTL8812AU):

• aircrack-ng/rtl8812au#116

And here is where the problem get solved, and I don't know why, or how.

If I boot my Pineapple Nano with my Alfa cards configured in access point mode, and after put them in monitor mode as always, when executing Bettercap the error message is completely gone.

Reverted back to boot my Alfa cards in station mode, and after put them in monitor mode as always, when executing Bettercap the error message returned.

from bettercap.

@julianoborba

do you think this case worth analysis for the sake of MT7612U driver improvement somehow?

The MT76 drivers are maintained by Mediatek devs in the Linux Mainline kernel. The OpenWRT MT76 repo is a downstream testing location and code goes back and forth.

I'm interested in any problems as I do have a list and communicate with the kernel devs at times. What problem were you seeing?

from bettercap.

@morrownr

The MT76 drivers are maintained by Mediatek devs in the Linux Mainline kernel. The OpenWRT MT76 repo is a downstream testing location and code goes back and forth.

I'm interested in any problems as I do have a list and communicate with the kernel devs at times. What problem were you seeing?

Thank you very much for the clarification.

In fact I have little evidence and no understanding, due my lack of intimacy with some nuances involving WiFi and USB adapters for this matter, about the following behavior:

If I boot my Pineapple Nano (with OpenWRT) with my Alfa card - AWUS036ACM - configured in access point mode, and after put them in monitor mode - using airmon-ng -, when executing in special Bettercap, the libpcap used by this tool error message - send: Resource temporarily unavailable - is completely gone when performing a high demanding packet transmission, as seen while deauthenticating a target.

I reverted back to boot my Alfa card in station mode, and after put them in monitor mode, when executing Bettercap the error message returned, flooding Bettercap logs.

At this time, for me just seems more or less similar to RTL8812AU packet loss issue.

It's a real problem? How to further investigate? What I'm missing? It's intended behavior? Should I open an issue for that matter at morrownr/7612u?

Thank you in advance, I already owe you since I choose AWUS036ACM based on your content at:

• https://github.com/morrownr/7612u

And so far I have overall great experience with this adapter plus with your repository guidance.

EDIT:

Yet that workaround did not work on my Linux Mint:

$ uname -aor
Linux <REDACTED> 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

I notice a huge dropped packet amount with AWUS036ACM in monitor mode:

$ ifconfig
wlan0mon: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        unspec <REDACTED>  txqueuelen 1000  (UNSPEC)
        RX packets 89247  bytes 10140779 (10.1 MB)
        RX errors 0  dropped 89247  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

EDIT 2:

I notice a huge dropped packet amount with AWUS036ACM in monitor mode

Nevermind, looks like this is expected.

I will fallback to my first assumption: of a client gets disconnected from de AP, while using a Mediatek chipset, libpcap will throw send: Resource temporarily unavailable. But this is expected?

from bettercap.

Yet that workaround did not work on my Linux Mint

Update: worked when using the following configuration:

# hostapd hostapd.conf
#
driver=nl80211
hw_mode=a
channel=36
interface=<REDACTED>
ssid=<REDACTED>

What happens to the USB adapter when put into AP mode and then MONITOR mode?
What happens to the USB adapter when put into STA mode and then MONITOR mode?

from bettercap.

Regarding your hostapd.conf: I have an AP guide:

https://github.com/morrownr/USB-WiFi

See menu item 9. Getting the hostapd.conf configured for the adapter you are using is very important. My guide has example hostapd.conf files that give the specifics for many chipsets, including the mt7612u. Your very limited hostapd.conf will not yield max performance.

What happens to the USB adapter when put into AP mode and then MONITOR mode?

I don't know. My AP's come up in manged mode but are rapidly taken into AP mode by hostapd.

What happens to the USB adapter when put into STA mode and then MONITOR mode?

Sounds like normal ops to me. I guess I don't understand the question.

from bettercap.

Thank you very much, @morrownr .

I will consume that guide. Also, I will try gain a more deep comprehension about operating that network adapter, and I hope I can be more clear both about my analysis and when describing more questions.

Again, thank you very much.

Happy New Year!

from bettercap.

The problem seems to be solved. But I'd like that someone with more or properly knowledge than I have shed some light. I touch a situation that I don't know how to address to the open source community.

Before closure, I will let that issue open for a couple days more for appreciation from the experts.

@morrownr, I know it's sudden, but do you think this case worth analysis for the sake of MT7612U driver improvement somehow? If I'm not mistaken, you maintain said driver also used by OpenWRT builds. If it's a mistake of mine, just kindly ignore.

About my initial request of extra parameters to Bettercap, and about my adjust for more detailed debug messages, I will try create a PR so the community and @evilsocket can decide if is something usable.

EDIT:

I will keep a fork with above adjusts for personal testing at

• https://github.com/julianoborba/bettercap

Note that in this fork I remove packet_proxy just so I can build straightforward to OpenWRT. Note there is compiled packages for those adventurous testers.

Can you build a mipsel ipk thanks a lot!

from bettercap.

@LuckyFishGeek

Can you build a mipsel ipk thanks a lot!

Sure. Check this out. I'm not sure if it's properly compiled, it's my first time building that stuff, really. Give a try, I can't test for MIPSel as I don't have any device with that architecture.

from bettercap.