ad-hoc mode not working

[davenmccalla]

I noticed that ad-hoc mode was discussed in issue #4 (opened in 2013) and was closed without a resolution. I'm trying to create an ad-hoc network using two (or more) rtl8188eu devices. I have originally tried the Linux driver v5.2.2.4_25483.20171222 from TP-link. Now I'm trying the driver in the v5.2.2.4 branch here since there have been many improvements made.

Here are a few clues:

1. Ad-hoc works with two rtl8192cu devices. They come up with wpa_state=COMPLETED, matching BSSIDs, and are able to ping each other. This gives me confidence that I have wpa_supplicant configured correctly for ad-hoc mode.
2. Using two rtl8188eu devices, one or both come up with wpa_state=ASSOCIATING. If I disable_network then enable_network using wpa_cli I can get wpa_state=COMPLETED on both, but the BSSIDs never match and they are not able to ping each other.
3. Using one rtl8192cu device and one rtl8188eu device, if rtl8192cu comes up first they both get to the COMPLETED state and they have matching BSSIDs, but still not able to ping each other. If rtl8188eu comes up first it gets stuck in the ASSOCIATING state and requires using wpa_cli disable_network then enable_network to get to COMPLETED state. If rtl8192cu comes up after rtl8188eu is in the COMPLETED state, it will get to a COMPLETED state with a matching BSSID but the devices are not able to ping each other.

Please let me know if I can provide any more information to help resolve this issue.

[lwfinger]

The most useful information would be to capture the over-the-air packets using wireshark on a 3rd computer. By comparing what info is passed for the case of two 8192cu devices compared with two 8188eu units, it may be possible to track the problem. Personally, I have not done anything with ad-hoc networks for some time.

[davenmccalla]

I've never used wireshark to capture over-the-air packets. If it's similar to capturing wired packets I shouldn't have a problem. I'll do that to see if it provides more clues.

One more clue I noticed in the scan_results. The rtl8188eu is missing the WPA-PSK-CCMP. Maybe this is because the rtl8188eu devices don't make it to the authentication stage?

The scan_results when using the rtl8192cu devices show: 8e:ce:3e:a7:6f:7c 2442 -10 [WPA2-PSK-CCMP][IBSS] MYSSID The scan_results when using the rtl8188eu devices show: 02:11:87:b5:6c:2c 2442 -9 [IBSS] MYSSID

BTW, the entry in my /etc/network/interfaces for wlan0 is: iface wlan0 inet static address 179.3.0.8 # IP address for other device is 179.2.0.14 netmask 255.255.0.0 broadcast 179.3.255.255 wpa-conf /etc/wpa0.cfg

My /etc/wpa0.cfg looks like this: ap_scan=2 country=US network={ ssid="MYSSID" mode=1 frequency=2442 proto=RSN key_mgmt=WPA-PSK pairwise=CCMP group=CCMP psk="password" }

[davenmccalla]

The only PC I have available to capture the over-the-air packets using wireshark is a Windows 10 machine with Intel(R) Dual Band Wireless-AC 8265, which doesn't support monitor mode. I ordered one of the WiFi adapters identified at https://secwiki.org/w/Npcap/WiFi_adapters that supports monitor mode on Windows 10. I should receive it in a couple days.

I found another interesting clue when using two rtl8188eu devices. When one device comes up with wpa_state=COMPLETED and the other comes up stuck in wpa_state=ASSOCIATING, they can ping each other. If I ifdown/ifup the one stuck in the ASSOCIATING state, it will come back up in the COMPLETED state, but they can no longer ping each other.

[davenmccalla]

adhoc.zip I received the WiFi adapter and was able to put it in monitor mode and capture over-the-air packets. I wasn't able to set the channel, so if the information you're looking for is missing I've got more work to do. If you need the packets over the channel I'll have to try a Linux VM to capture them. I can't seem to set the channel with Windows.

[davenmccalla]

I wasn't able to set the channel for my WiFi adapter but I was able to determine the default channel is 1. I setup my ad-hoc network to use channel 1 and captured the over-the-air packet for both devices. Since I'm not able to attach files with .pcapng extension, I'm attaching .zip files that contain the .pcapng files. rtl8188eu.zip rtl8192cu.zip

[davenmccalla]

Oops... I was looking through the rtl8192cu capture and realized my filter had one MAC address instead of two. The attached capture filters out everything not being sent or received by the two rtl8192cu devices. The previously attached capture for rtl8188eu devices is correct and filtered out everything not being sent or received by the two rtl8188eu devices. rtl8192cu2.zip

[davenmccalla]

Notice that the beacon frames sent by the rtl8188eu devices are smaller than the rtl8192cu devices. They are missing everything after the "Supported rates" in the "Tagged parameters". So they are missing the RSN Information tag. This explains why it doesn't see the SSID as secured (no padlock on icon), but does show the SSID for the rtl8192cu devices as secured. It also explains why it never tries to authenticate.

[lwfinger]

Sorry that I have not gotten to your problem. I'm having a health problem. It should be resolved in the next few days.

What driver are you using for the rtl8192cu devices?

[davenmccalla]

Well, modinfo only returns the filename. It is an in-tree module that was part of kernel version 4.4.70-bone-rt-r17 for the beaglebone. I see your name and email as one of the MODULE_AUTHORs, but I don't know how to tell what version of the driver the source code came from.

[davenmccalla]

If I use the in-tree module for the rtl8188eu from the 4.4.70-bone-rt-r17 kernel, it doesn't even send beacon frames. Just some Multicast Listener Discovery (MLD) and Neighbor Discovery Protocol (NDP) packets.