Comments (5)
thomasst
commented on July 29, 2024
I was able to maybe narrow the problem down a bit.
I have a MacBook running macOS Catalina 10.15.7 (fe80::fc77:26ff:febc:5a5d), iPhone running iOS 14.0 (fe80::1c0d:aaff:fe4d:5a79) and a Linux box running owl (fe80::523e:aaff:fe31:c062) on the AWDL network. ff02::fb is the broadcast address. The iPhone has a share sheet open and the Mac has a Finder Airdrop window open.
- From the MacBook, I can ping both the iPhone and Linux box directly without any issues (latency is between 4ms and 400ms). When I ping the broadcast, I get duplicates back from both the Linux box and the iPhone:
% ping6 ff02::fb%awdl0
PING6(56=40+8+8 bytes) fe80::fc77:26ff:febc:5a5d%awdl0 --> ff02::fb%awdl0
ping6: failed to get receiving hop limit
16 bytes from fe80::fc77:26ff:febc:5a5d%awdl0, icmp_seq=0 hlim=64 time=0.219 ms
16 bytes from fe80::1c0d:aaff:fe4d:5a79%awdl0, icmp_seq=0 hlim=64 time=531.305 ms
16 bytes from fe80::523e:aaff:fe31:c062%awdl0, icmp_seq=0 hlim=64 time=532.701 ms
16 bytes from fe80::523e:aaff:fe31:c062%awdl0, icmp_seq=0 hlim=64 time=925.133 ms
16 bytes from fe80::1c0d:aaff:fe4d:5a79%awdl0, icmp_seq=0 hlim=64 time=926.269 ms
16 bytes from fe80::fc77:26ff:febc:5a5d%awdl0, icmp_seq=1 hlim=64 time=0.228 ms
16 bytes from fe80::1c0d:aaff:fe4d:5a79%awdl0, icmp_seq=1 hlim=64 time=446.991 ms
16 bytes from fe80::1c0d:aaff:fe4d:5a79%awdl0, icmp_seq=1 hlim=64 time=575.425 ms
16 bytes from fe80::523e:aaff:fe31:c062%awdl0, icmp_seq=1 hlim=64 time=576.498 ms
16 bytes from fe80::523e:aaff:fe31:c062%awdl0, icmp_seq=1 hlim=64 time=968.384 ms
16 bytes from fe80::1c0d:aaff:fe4d:5a79%awdl0, icmp_seq=1 hlim=64 time=968.629 ms
...
- From the Linux box running owl I can ping the Mac, however I'm having trouble pinging the iPhone. Sometimes none of the pings go through, sometimes just the first one (
icmp_seq=1). Is this a driver issue with themt76or a bug in owl? What would be special about the first ping compared to the others?
PING fe80::1c0d:aaff:fe4d:5a79%awdl0(fe80::1c0d:aaff:fe4d:5a79%awdl0) 56 data bytes
64 bytes from fe80::1c0d:aaff:fe4d:5a79%awdl0: icmp_seq=1 ttl=64 time=163 ms
^C
--- fe80::1c0d:aaff:fe4d:5a79%awdl0 ping statistics ---
219 packets transmitted, 1 received, 99% packet loss, time 223191ms
rtt min/avg/max/mdev = 163.962/163.962/163.962/0.000 ms
- When I ping the broadcast from the Linux box, I get delayed replies (up to ~15s) from the Mac, but none from the iPhone.
% ping ff02::fb%awdl0
PING ff02::fb%awdl0(ff02::fb%awdl0) 56 data bytes
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=1 ttl=64 time=0.030 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=3 ttl=64 time=0.043 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=4 ttl=64 time=0.043 ms
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=1 ttl=64 time=3598 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=2 ttl=64 time=2595 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=3 ttl=64 time=1572 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=4 ttl=64 time=916 ms (DUP!)
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=5 ttl=64 time=0.047 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=6 ttl=64 time=0.046 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=7 ttl=64 time=0.046 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=8 ttl=64 time=0.045 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=9 ttl=64 time=0.051 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=10 ttl=64 time=0.047 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=11 ttl=64 time=0.048 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=12 ttl=64 time=0.045 ms
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=5 ttl=64 time=7268 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=10 ttl=64 time=2155 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=11 ttl=64 time=1131 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=12 ttl=64 time=107 ms (DUP!)
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=13 ttl=64 time=0.047 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=14 ttl=64 time=0.047 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=15 ttl=64 time=0.045 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=16 ttl=64 time=0.047 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=17 ttl=64 time=0.041 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=18 ttl=64 time=0.045 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=19 ttl=64 time=0.044 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=20 ttl=64 time=0.045 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=21 ttl=64 time=0.046 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=22 ttl=64 time=0.045 ms
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=13 ttl=64 time=9586 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=14 ttl=64 time=8571 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=15 ttl=64 time=7555 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=16 ttl=64 time=6531 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=17 ttl=64 time=5508 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=18 ttl=64 time=4484 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=19 ttl=64 time=3460 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=20 ttl=64 time=2436 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=21 ttl=64 time=1412 ms (DUP!)
64 bytes from fe80::fc77:26ff:febc:5a5d%awdl0: icmp_seq=22 ttl=64 time=395 ms (DUP!)
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=23 ttl=64 time=0.049 ms
64 bytes from fe80::523e:aaff:fe31:c062%awdl0: icmp_seq=24 ttl=64 time=0.048 ms
Note that this is on channel 149 with the regulatory domain set to US. If the regulatory domain isn't set, none of the packets go out (consistent with #10 (comment)).
Maybe @Kulawik @neilalexander have any insights on this since it appears you have the same card?
from owl.
schmittner
commented on July 29, 2024
@thomasst which part of your issue was resolved with #39?
from owl.
thomasst
commented on July 29, 2024
@schmittner Thanks for checking in. #39 fixed queueing up the packets and responding in bulk in the scenario where I ping the broadcast. In my last comment above you can see that fe80::fc77:26ff:febc:5a5d%awdl0 was responding in batches to the pings, since they were previously queued up in the circular buffer -- this is now fixed.
However, there is still packet when sending packets via owl, on both TP-Link Archer T1U V1.0 as well as the Alfa AWUS036NHA. Overall, the Alfa card is performing better than the TP-Link. I suspect it might have to do with the timing of when the packets are sent out, but I'm not familiar enough with AWDL to figure it out. On the machine running owl, I can see all packets going out in wireshark on both awdl0 as well as the physical wi-fi interface, but I can't see it in Wireshark coming in on the Mac, so it appears the packet somehow gets lost "in the air".
With the Alfa card, there is frequent and sporadic packet loss without a specific pattern that I could figure out. On the Archer, certain devices, like my iPhone, barely receive any packets. The issue described above ("Sometimes none of the pings go through, sometimes just the first one (icmp_seq=1).") is still happening.
Do you have any ideas why this might be? If you have time to help out, I'm happy to do any more debugging and provide more details. Thanks!
from owl.
schmittner
commented on July 29, 2024
I see, thanks for clarifying. Can you assert that packets actually arrive at the Mac and not get lost over the air? To do this, set your Mac to monitor mode and record packets on channel 149 (in your case).
from owl.
deanward81
commented on July 29, 2024
I can readily reproduce this here. I have an iPhone running iOS 15.1 and a MacBook Pro running Catalina 10.15.7 with OWL on a Raspberry Pi running kernel 5.10. I'm using a TP-Link Archer T1U V1.0 using the mt76 driver. MBP can send and receive to OWL just fine but the iPhone shows the sporadic traffic patterns described by @thomasst.
Running tcpdump on the Pi, while executing a ping to the link-local address of the iPhone, ICMPv6 echo request packets are being sent over the awdl0 interface and physical WLAN interfaces. Monitoring the rvi0 interface (which is a virtual interface representing all traffic sent to/from the iPhone, exposed on the MacBook as described here) shows that the iPhone is happily responding with an ICMPv6 echo reply, but those are only received sporadically by the Pi - tcpdump on either the awdl0 or physical interface shows that the majority of replies are somehow lost.
When monitoring awdl0 on the Pi I can see other traffic (e.g. mDNS multicast traffic) being received from the iPhone but any unicast traffic seems to be sporadic. When I run tcpdump on the physical WLAN interface while the ping is running I can see the occasional sporadic ping reply being received and plenty of radiotap traffic being received from the iPhone, as well as multicast packets. That seems to indicate that the IPv6 ping reply sent from the iPhone is dropped somewhere along the way.
When pinging the iPhone's link-local address via my MacBook's awdl0 interface then it pings consistently.
Additionally all of this just works if I do the same things from the MBP (rather than the iPhone).
I'm unsure how to go about debugging this further - any pointers really appreciated! I'm really confused as to why the MBP works fine but the iPhone does not.
from owl.
Related Issues (20)
- Device does not support radiotap headers HOT 3
- ipv6 address of our device in MDNS is not correct
- Failed to connect to generic netlink HOT 2
- Is Android mobile phone supported? HOT 4
- Receiver Repeated network packet from macOS（ping）
- Error compiling on Linux with GCC 11 HOT 1
- Error when make HOT 1
- Use monitor mode instead of active monitor mode HOT 2
- Has this worked for anyone recently? HOT 1
- compilation error
- documentation on active monitor mode HOT 2
- complation error when performing make or sudo make install HOT 4
- build error: redefinition of 'struct ethhdr' HOT 4
- The project was successfully launched, but Mac10.15 crashed
- AirPlay can't connect HOT 17
- Is there any way I could emulate (?) active monitor mode?
- make error HOT 2
- Net crashes while trying to run owl
- Could not put device in monitor mode HOT 2
- OWL works, but opendrop doesn't
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from owl.