-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't discover any devices #21
Comments
I also can't find any apple devices |
There could be several causes here. Maybe this helps the debug process:
|
thanks so much for the debugging script. Here is what it looks like on a Purism Librem13v4 (
For what it's worth, the Atheros device I have is slightly different from your lab device. Here's the output of the
So this might just be the iPad not waking up, but then again I don't understand why it wouldn't show up when trying to send a file from the iPad. By the way, thank you so much for your work on this project. I've been wondering for a long time if someone would manage to reverse engineer this protocol, and you made it! I can only hope this can be standardized a bit more in Linux so that more users can use this thing to talk to Apple devices. Congratulations! |
This is how I setup everything:
This is what the latter two look like:
Note that if I start
I can even transfer files (locally) this way, and I suspect this might So, any idea on how I can debug this? |
This is not the way to start
Depending on your regdom, you might want to set channel 44 or 149 via the |
On 2019-09-16 04:11:36, Milan Stute wrote:
> 3. create a monitoring interface:
> ```
> sudo iw phy `iw dev wlp1s0 info | gawk '/wiphy/ {printf "phy" $2}'` interface add mon0 type monitor
> sudo ifconfig mon0 up
> ```
> 4. start owl and opendrop:
> ```
> sudo owl -i mon0 -v -N
> opendrop -i awdl0 -d find
> ```
This is *not* the way to start `owl` with a Wi-Fi driver that properly supports `nl80211`. The `-N` flag effectively disables all `nl80211` functionality which means that neither *active* monitor mode is enabled nor the Wi-Fi channel is set correctly (which is the problem that you are facing here; you still get the console output put that's a no-op). You should not use `-N` as it is just a dirty hack to support devices that use Nexmon for monitor mode and require you to manually set the channel, which is why I did not document this in the README.
To make life easier, simply run:
```
sudo owl -i wlp1s0 -v
```
Depending on your regdom, you might want to set channel 44 or 149 via
the `-c` flag for better performance.
Ah well, I used the -N flag because otherwise I get this error:
10:00:15 ERROR: Error while receiving via netlink: Object busy
10:00:15 ERROR: Could not put device in monitor mode: wlp1s0
10:00:15 ERROR: could not initialize core
same if using the `mon0` interface.
Is there something special that should be done with Network Manager if
it's running? I tried to have it off and on, it doesn't seem to change
anything...
|
You might have to kill |
@anarcat any luck? |
haven't found the time to retry, sorry :/ |
I met the same problem after the macbook system update. Everything worked well before the update. |
Excuse me, sir. |
I have the same issue and the same testing results as @anarcat with ralink rt5372 even after killing all processes from
The Wifi adapter rt5372 looks fine from |
I'm experiencing the same problem
I tried with ... <crop>
bind(4, {sa_family=AF_NETLINK, nl_pid=750819289, nl_groups=00000000}, 12) = 0
getsockname(4, {sa_family=AF_NETLINK, nl_pid=750819289, nl_groups=00000000}, [12]) = 0
sendmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=32, type=nlctrl, flags=NLM_F_REQUEST|NLM_F_ACK, seq=16
17009821, pid=750819289}, "\x03\x01\x00\x00\x0c\x00\x02\x00\x6e\x6c\x38\x30\x32\x31\x31\x00"}, iov_len=32}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=2336, type=nlctrl, flags=0, seq=1617009821, pid=750819
289}, "\x01\x02\x00\x00\x0c\x00\x02\x00\x6e\x6c\x38\x30\x32\x31\x31\x00\x06\x00\x01\x00\x1d\x00\x00\x00\x08\x00\x03\x00\x01\x00\x00\x00"...}, iov_len=16384}], msg_iovlen=
1, msg_controllen=0, msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 2336
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=2336, type=nlctrl, flags=0, seq=1617009821, pid=750819
289}, "\x01\x02\x00\x00\x0c\x00\x02\x00\x6e\x6c\x38\x30\x32\x31\x31\x00\x06\x00\x01\x00\x1d\x00\x00\x00\x08\x00\x03\x00\x01\x00\x00\x00"...}, iov_len=16384}], msg_iovlen=
1, msg_controllen=0, msg_flags=0}, 0) = 2336
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=36, type=NLMSG_ERROR, flags=NLM_F_CAPPED, seq=16170098
21, pid=750819289}, {error=0, msg={len=32, type=nlctrl, flags=NLM_F_REQUEST|NLM_F_ACK, seq=1617009821, pid=750819289}}}, iov_len=16384}], msg_iovlen=1, msg_controllen=0,
msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 36
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=36, type=NLMSG_ERROR, flags=NLM_F_CAPPED, seq=16170098
21, pid=750819289}, {error=0, msg={len=32, type=nlctrl, flags=NLM_F_REQUEST|NLM_F_ACK, seq=1617009821, pid=750819289}}}, iov_len=16384}], msg_iovlen=1, msg_controllen=0,
msg_flags=0}, 0) = 36
openat(AT_FDCWD, "wlan0", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=2326, ...}) = 0
fstat(5, {st_mode=S_IFREG|0644, st_size=2326, ...}) = 0
read(5, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\t\0\0\0\0"..., 4096) = 2326
lseek(5, -1467, SEEK_CUR) = 859
read(5, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\t\0\0\0\0"..., 4096) = 1467
close(5) = 0
write(2, "11:23:41 TRACE: ", 1611:23:41 TRACE: ) = 16
write(2, "pcap: unable to open savefile (w"..., 64pcap: unable to open savefile (wlan0: No such file or directory)) = 64
write(2, "\n", 1
) = 1
access("/proc/net", R_OK) = 0
access("/proc/net/unix", R_OK) = 0
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 5
ioctl(5, SIOCGIFINDEX, {ifr_name="wlan0", }) = 0
close(5) = 0
sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=40, type=RTM_GETLINK, flags=NLM_F_REQUEST|NLM_F_ACK, s
eq=1617009821, pid=167811033}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=if_nametoindex("wlan0"), ifi_flags=0, ifi_change=0}, {{nla_len=8, nla_type=IFLA_EX
T_MASK}, 1}}, iov_len=40}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 40
... <crop> I suppose the resource issue arises here: Edit: This was not the issue for me 😊 Remarks: I've stopped Side note: Using However, fixing this file link issue does not resolve the previous issue. |
Update: so I was able to make it work for me. I've commented out the relevant two if (!state->wlan_no_monitor_mode) /* if device is already in monitor mode */
err = set_monitor_mode(state->wlan_ifindex);
if (err < 0) {
log_error("Could not put device in monitor mode: %s", state->wlan_ifname);
return err;
} I'm making sure myself, to put the interface card in monitor mode. After recompiling and installing, it works. |
I can't discover any devices via the
opendrop find
command. It successfully starts looking for receivers but then just sits there and can't discover any devices. OWL seems to be working fine, and with wireshark (notwireshark-awdl
) I can see packets being sent between other devices.Is this a problem on my end or a bug/limitation of OpenDrop?
Cheers.
The text was updated successfully, but these errors were encountered: