Closed clintonm9 closed 5 years ago
Is this something that you think we can enable the ioctl() commands to make it work?
I don't think that we can handle that in an easy way. The GEMINI config is really "hard core". Unfortunately the only interface (wlan0) that supports ioctl() commands doesn't support monitor mode. BTW: I pushed another update. If you add CFLAGS += -DDEBUG in makefile here:
CC ?= gcc CFLAGS ?= -O3 -Wall -Wextra CFLAGS += -std=gnu99 CFLAGS += -DDEBUG INSTFLAGS = -m 0755
you will get additional information about all interfaces.
wlan interfaces:
testing lo
not a wireless interface: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
testing ifb0
not a wireless interface: Operation not supported
testing ifb1
not a wireless interface: Operation not supported
testing tunl0
not a wireless interface: Bad address
testing sit0
not a wireless interface: Invalid argument
testing ip6tnl0
not a wireless interface: Invalid argument
testing rndis0
not a wireless interface: Operation not supported
0009345e53a0 wlan0 (mt-wifi)
testing wlan1
not a wireless interface: Operation not supported
That is the main point and the reason why hcxdumptool doesn't work running the GEMINI kernel: testing wlan1 not a wireless interface: Operation not supported
You should ask the GEMINI-KALI developers about the difference between a standard Linux kernel (https://www.kernel.org/) and the GEMINI-KALI kernel.
BTW: Your kernel https://github.com/Re4son/gemini-kali-linux-kernel-3.18 is a fork from https://github.com/gemian/gemini-linux-kernel-3.18 which is a fork from https://github.com/dguidipc/gemini-android-kernel-3.18
Maybe it's a good idea to report the ioctl(issue) on the original version: https://github.com/dguidipc/gemini-android-kernel-3.18
But keep in mind:
The upstream Linux kernel maintainers only fix bugs for specific kernel versions. Those versions include the current "release candidate" (or -rc) kernel, any "stable" kernel versions, and any "long term" kernels.
Please see https://www.kernel.org/ for a list of supported kernels. Any kernel marked with [EOL] is "end of life" and will not have any fixes backported to it.
https://github.com/dguidipc/gemini-android-kernel-3.18/blob/master/kernel-3.18/REPORTING-BUGS
Additionally you can use another tool to test the interfaces: https://gist.github.com/edufelipe/6108057 do a git clone and compile it: $ gcc is_wireless.c -o is_wireless
$ ./is_wireless interface lo is not wireless interface enp33s0 is not wireless interface wlp3s0f0u10u4 is wireless: IEEE 802.11
Let's see if it detect wlan1
This is a very interesting statement: https://www.quora.com/What-are-the-differences-between-netlink-sockets-and-ioctl-calls especially this parts here: "Netlink messages can be lost for various reasons (e.g. out of memory), while ioctls are generally more reliable due to their immediate-processing nature."
"Control: ioctl should be your first choice, unless there’s an overriding reason, due to its immediacy and reliable delivery."
I fully agree with this!
root@kali:~/Repos/6108057# ./is_wireless
interface lo is not wireless
interface ccmni0 is wireless:
interface ccmni1 is wireless:
interface ccmni2 is wireless:
interface ccmni3 is wireless:
interface ccmni4 is wireless:
interface ccmni5 is wireless:
interface ccmni6 is wireless:
interface ccmni7 is wireless:
interface ccmni8 is wireless:
interface ccmni9 is wireless:
interface ccmni10 is wireless:
interface ccmni11 is wireless:
interface ccmni12 is wireless:
interface ccmni13 is wireless:
interface ccmni14 is wireless:
interface ccmni15 is wireless:
interface ccmni16 is wireless:
interface ccmni17 is wireless:
interface cc3mni0 is wireless:
interface cc3mni1 is wireless:
interface cc3mni2 is wireless:
interface cc3mni3 is wireless:
interface cc3mni4 is wireless:
interface cc3mni5 is wireless:
interface cc3mni6 is wireless:
interface cc3mni7 is wireless:
interface ifb0 is not wireless
interface ifb1 is not wireless
interface tunl0 is not wireless
interface sit0 is not wireless
interface ip6tnl0 is not wireless
interface rndis0 is not wireless
interface wlan0 is wireless: IEEE 802.11bgn
interface wlan1 is not wireless
How hard would it be to put together a sample code showing the issue? I think that would be best if I was going to submit a bug to them.
interface wlan1 is not wireless: I looks like the developer of your kernel prefers Netlink instead of ioctl(). Maybe he has a good reason (in combination with Android) to do this. It is not a bug/issue, it is his decision. Just attach the result of is_wireless (and the link to it - the code is easier to understand than the code from hcxdumptool) and ask him, why the prefer Netlink interfaces.
All kernels from here: https://www.kernel.org/ understand ioctl().
I added an issue, thanks again for all your help
Great. I noticed your issue report there and I am looking forward to the reply. There has to be a reason to choose this way. I explained my reason not to do it that way.
By latest commit: https://github.com/ZerBea/hcxdumptool/commit/354b83a3a9232b6ce031277e61109bcf20da9ada hcxdumptool should inform now, that the chosen interface is not usable.
Do we have some new information about the ioctl() behavior from Gemini PDA developers?
I have heard nothing new from them. Would be nice to get more info.
Ok, let's wait....
Pushed another update. Now hcxdumptool has a new option --check_driver. If everything is ok, result should be something like this: $ sudo hcxdumptool -i wlp3s0f0u10u4 --check_driver driver tests passed - all required ioctl() system calls are supported by driver
If an error ocured, hcxdumptool will inform you about possible unsupported/not working driver system calls. You should report them to the maintainer of the driver.
Closed, because we got no further information and the issue isn't related to hcxdumptool (driver and/or system configuration issue).
At least I think I know why it isn't working as expected. The Linux Kernel must be compiled with: CONFIG_CFG80211_WEXT=y CONFIG_CFG80211_WEXT_EXPORT=y because hcxdumptool exactly use WEXT to control the device. It looks like this is not the case on severa Android devices: https://github.com/ZerBea/hcxdumptool/issues/197#issuecomment-997682554
I have a Gemini PDA with Kali Linux on it running a very old kernel of 3.18.41 (that is all that is offered).
I know that airodump-ng works with the older kernel, but is there a way to get this tool to work? I tried to use the android ndk builds, but no look.
The error I get is: