Support ad hoc network #70
Conversation
| /* Don't send packet to device with different SSID. */ | ||
| if (strcmp(vif->ssid, dest_vif->ssid)) | ||
| continue; | ||
| /* Don't send packet to device with different BSSID. */ |
There was a problem hiding this comment.
TODO: move the packet filtering part on netif_rx(). Receivers with promiscuous mode on should expose the packets to kernel (via BPF) even if the packets are not for itself.
There was a problem hiding this comment.
Do you mean that I should rewrite netif_rx() separately, or perform packet filtering in vwifi_rx()?
There was a problem hiding this comment.
The MAC address here refers to the MAC address of the IBSS network itself, rather than the MAC address of any individual device within the IBSS network.
There was a problem hiding this comment.
I mistakenly wrote the netif_rx() rather than vwifi_rx(). It should be vwifi_rx().
The MAC address here refers to the MAC address of the IBSS network itself, rather than the MAC address of any individual device within the IBSS network.
What I mention is both for the randomized IBSS MAC address and the receiver's MAC address. A wireless interface in promiscuous mode should let the sniffer see all the frames in the wireless medium.
But we should defer the implementation of RX filtering to the next PR.
| /* Don't send packet to device with different SSID. */ | ||
| if (strcmp(vif->ssid, dest_vif->ssid)) | ||
| continue; | ||
| /* Don't send packet to device with different BSSID. */ |
There was a problem hiding this comment.
TODO: move the packet filtering part on netif_rx(). Receivers with promiscuous mode on should expose the packets to kernel (via BPF) even if the packets are not for itself.
The same.
|
Have you tried vwifi with WPA/RSN support in IBSS mode? |
I tried using the following file, and it worked. Test Scenario 1Using the command wpa_supplicant, configure vw3 and vw4 to join ibss1: $ wpa_supplicant -i vw3 -B -c scripts/wpa_supplicant_ibss.conf
Successfully initialized wpa_supplicant
$ wpa_supplicant -i vw4 -B -c scripts/wpa_supplicant_ibss.conf
Successfully initialized wpa_supplicantObserving the interface information confirms both successfully joined ibss1: The kernel messages shows that initially ibss1 did not exist, so vw3 created it. vw4, through scanning, discovered the existence of ibss1 and joined it: It's noteworthy that when creating an IBSS network with WPA, the BSSID is automatically generated by the system. This ensures each IBSS network is unique. Attempting to ping from vw3 to vw4 results in successful packet delivery: $ sudo ip netns exec ns3 ping -c 1 10.0.0.5
================================================================================
Ping Test: IBSS vw3 (10.0.0.4) (in ibss1) <--> IBSS vw4 (10.0.0.5) (in ibss1)
(should success)
(be patient, it will take some time to route...)
================================================================================
PING 10.0.0.5 (10.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=1031 ms
--- 10.0.0.5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1031.052/1031.052/1031.052/0.000 msTest Scenario 2vw5 manually creates and joins ibss2, while vw3 and vw4 join ibss1 using WPA: sudo ip netns exec ns5 iw dev vw5 set type ibss
$ sudo ip netns exec ns5 iw dev vw5 ibss join ibss2 2412 NOHT fixed-freq 00:76:77:35:00:00 beacon-interval 300
$ sudo ip netns exec ns3 ip addr add 10.0.0.4/24 dev vw3
$ sudo ip netns exec ns4 ip addr add 10.0.0.5/24 dev vw4
$ sudo ip netns exec ns5 ip addr add 10.0.0.6/24 dev vw5
$ sudo ip netns exec ns3 wpa_supplicant -i vw3 -B -c scripts/wpa_supplicant_ibss.conf
$ sudo ip netns exec ns4 wpa_supplicant -i vw4 -B -c scripts/wpa_supplicant_ibss.confObserving kernel messages shows that vw5 initially creates ibss2, so when vw3 attempts to join using WPA, it scans and finds ibss2 but creates ibss1 instead. vw4, upon scanning, discovers both ibss1 and ibss2, and chooses to join ibss1: Attempting to ping from vw3 to vw5 fails to deliver packets: $ sudo ip netns exec ns3 ping -c 1 10.0.0.6
================================================================================
Ping Test: IBSS vw3 (10.0.0.4) (in ibss1) <--> IBSS vw5 (10.0.0.6) (in ibss2)
(should fail)
(be patient, it will take some time to route...)
================================================================================
PING 10.0.0.6 (10.0.0.6) 56(84) bytes of data.
From 10.0.0.4 icmp_seq=1 Destination Host Unreachable
--- 10.0.0.6 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms |
jychen0611
force-pushed
the
ad-hoc
branch
3 times, most recently
from
b3786f1
to
bd35301
Compare
The adjustments have been completed. |
|
The WPA-related tests and explanations have been updated. |
jychen0611
force-pushed
the
ad-hoc
branch
3 times, most recently
from
3274524
to
5ca6cec
Compare
|
I defer to @rickywu0421 for confirmation. |
| /* Don't send packet to device with different SSID. */ | ||
| if (strcmp(vif->ssid, dest_vif->ssid)) | ||
| continue; | ||
| /* Don't send packet to device with different BSSID. */ |
There was a problem hiding this comment.
I mistakenly wrote the netif_rx() rather than vwifi_rx(). It should be vwifi_rx().
The MAC address here refers to the MAC address of the IBSS network itself, rather than the MAC address of any individual device within the IBSS network.
What I mention is both for the randomized IBSS MAC address and the receiver's MAC address. A wireless interface in promiscuous mode should let the sniffer see all the frames in the wireless medium.
But we should defer the implementation of RX filtering to the next PR.
|
|
||
| /* It is possible to use cfg80211_inform_bss() instead. */ | ||
| bss = cfg80211_inform_bss_data( | ||
| vif->wdev.wiphy, &data, CFG80211_BSS_FTYPE_UNKNOWN, ibss->bssid, |
There was a problem hiding this comment.
What if the ibss->bssid is generated by the system (randomized BSSID)? I'm writing because I didn't see the code assigning this member (if the "if condition" in vwifi:2079 fails).
There was a problem hiding this comment.
Spot on, generating a BSSID should be implemented by the driver. Perhaps we need a global structure to manage the BSSID.
jychen0611
force-pushed
the
ad-hoc
branch
2 times, most recently
from
29b0c27
to
c2eb670
Compare
vwifi.c
Outdated
| memcpy(vif->bssid, ndev->dev_addr, ETH_ALEN); | ||
| struct vwifi_vif *ibss_vif = NULL; | ||
| list_for_each_entry (ibss_vif, &vwifi->ibss_list, ibss_list) { | ||
| if (!memcmp(ibss_vif->ssid, vif->ssid, vif->ssid_len) && |
There was a problem hiding this comment.
You should check if these two SSID's lengths are matched first. Otherwise the unexpected result might happen:
ibss_vif->ssid = "test2", vif->ssid = "test", vif->ssid_len = 4
jychen0611
force-pushed
the
ad-hoc
branch
2 times, most recently
from
bf97492
to
4ad74c0
Compare
In this update, an ad hoc (IBSS) mode has been added. Add the 'NL80211_IFTYPE_ADHOC' interface type to wiphy, enabling it to switch to ad hoc (IBSS) mode through the 'vwifi_change_iface' operation. Implement 'vwifi_join_ibss' and 'vwifi_leave_ibss' based on the 'cfg80211_ops' structure to enable IBSS devices to join a specific IBSS cell and frequency band. In the global structure 'vwifi_context', add 'ibss_list' to facilitate finding IBSS devices. When a device joins, it will be added to the 'ibss_list', and when a device leaves, it will be removed. Implement the IBSS mode packet forwarding mechanism. Additionally, ad-hoc related test items have been added, and the IBSS devices are scannable. Update the README file to include information about IBSS mode. Additionally, WPA support for IBSS mode has been added. The 'wpa_supplicant_ibss.conf' is used to configure the IBSS network. Since using WPA to construct an IBSS network results in the BSSID being automatically generated by the system, the 'vwifi_join_ibss' function does not receive the BSSID parameter. Thus, adopt the following method to assign its BSSID: Search the IBSS list for a network with matching WPA settings (compare the SSID and the frequency band). If found, use its BSSID. If not, use the device's MAC address as the BSSID. Check the lengths of the two SSIDs first before using 'memcmp'. Otherwise, unexpected results might occur. > In C99 standard : "The 'memcmp' function compares the first n characters of the object pointed to by s1 to the first n characters of the object pointed to by s2."
|
Thank @jychen0611 for contributing! |
In this update, an ad-hoc (IBSS) mode has been added. Users can switch their device to IBSS mode using the following command : iw dev [interface] set type ibss
To join a specific IBSS cell and configure other settings, users can use the command :
iw dev [interface] ibss join [SSID] [freq in MHz] [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz] [fixed-freq] [] [beacon-interval ]
[basic-rates <rate in Mbps,rate2,…>] [mcast-rate ] [key d:0:abcde]
eg.
iw dev vw3 ibss join Elian 2412 NOHT fixed-freq 00:76:77:33:00:00 beacon-interval 200
This command signifies that the device vw3 will either join an existing Ad-Hoc network named Elian or create one if it doesn't exist. The device will use the 2412 MHz frequency, not utilize High Throughput mode (802.11n), and maintain a fixed frequency without changes due to other devices. The BSSID (Basic Service Set Identifier) for the IBSS will be set as 00:76:77:33:00:00, and the beacon interval, which is the time between two consecutive beacons, will be set to 200 Time Units (TUs).
To leave the current Ad-Hoc network, users can use command : iw dev [interface] ibss leave
Additionally, ad-hoc related test items have been added, and the IBSS devices are scannable.
ping test
scan result
kernel messages