RX working but TX not working (regulatory domain unset) #10
Comments
|
I suspect that there might be a problem in the handling of multicast frames. I've just pushed a fix that should prevent frames from getting stuck in the TX queue. Let me know if that helped. |
|
Sadly this doesn't appear to have helped. The behaviour looks to be the same regardless of whether it's a multicast ping or a link-local unicast ping. |
|
Then let's first check if frame injection works at all: run |
|
It looks like not, since the Mac is never learning about Owl looking at Similarly, doing something like |
|
Can you also run wireshark on the Wi-Fi interface in monitor mode? Make sure to set the correct channel. |
|
Not seeing anything either - I used Wireless Diagnostics on the Mac to sniff on channel 4 in both 20MHz and 40MHz mode for a bit, while restarting Owl and running When opening both captures in Wireshark, I see lots of wireless traffic from nearby but absolutely nothing originating from the Owl MAC when filtering, e.g. using Looks decidedly like the frame injection isn't actually happening at all. |
|
Might just not be supported, probably should ask the mt76 folks. |
|
I've opened an issue with the In the meantime, I ran a So this would firmly imply that the problem lies within the wireless driver if these packets never make it onto the air? |
|
Yes, that would imply that the wireless driver/card does not send out the frames. Might also be that the driver does not like the radiotap headers created by Lines 297 to 319 in d16adec |
|
Just tried d16adec, which does look like it makes sense as I am seeing AWDL frames from real Macs being received at 12Mb/s, but that doesn't seem to have resolved the problem either. I'll keep on with the driver guys and see if they can provide some insight. It might be a simple fix in |
|
Hi, According to commit message from linux-wireless:
You can try Hope it helps |
|
I don‘t think that this is the problem here as it persists with channel 6 which does not have any restrictions in any reg dom as far as I know. |
|
It hadn't even occurred to me to check the regulatory domain — it was indeed unset. I did try setting the regulatory domain and that seems to have removed the I am also wondering whether the 2.4GHz bands not being listed under |
|
OK, so setting the regulatory domain does indeed fix the TX problem for channels 44 and 149. I can run Wireshark on another machine and see those frames hitting the air. Nothing on channel 6, however. Since However, I can at least exchange pings between a Mac and a Linux OWL host over the |
|
Additionally, it seems It would perhaps be a good idea for OWL to check the usability of configured frequencies at startup and print some kind of warning if they are not available due to regulatory restrictions. 😄 |
schmittner
changed the title
So I've tried to set up Owl today on a Linux box and haven't been able to get it to communicate with Macs over AWDL (note that the Macs are not running Owl but are instead using the built-in AWDL driver).
Owl starts normally, reports that it is discovering nearby peers and the
awdl0interface gets created.If I
tcpdumpon theawdl0interface then I can hear packets coming from other nodes, but if I ping toff02::1%awdl0(which works between the Macs), the packets are never received by the Macs.The wireless adapter is a TP-Link Archer T1U using the
mt76DKMS driver.Arch Linux:
Device capabilities:
The device does get put into monitor mode:
With debugging enabled, I see entries like this:
The behaviour is much the same if I supply
-c 6or-c 44and supplying-Nseems to make no difference either.I'm not sure if this is a driver issue or if there is something I can do to debug this further?
The text was updated successfully, but these errors were encountered: