View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003867 | GNUnet | WLAN transport | public | 2015-06-27 02:41 | 2021-12-31 09:32 |
| Reporter | dangole | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | confirmed | Resolution | open | ||
| Product Version | Git master | ||||
| Target Version | 1.0.0 | ||||
| Summary | 0003867: Fast WiFi transport / setup-helper should be implemented | ||||
| Description | The current WLAN transport is limited to very low data rates and cannot make use of modern hardware features like MIMO or aggregation. One way to achieve more throughput and easy peering could be via WiFi-Direct aka. P2P. For that, a to-be-implemented helper needs to connect to wpa_supplicant via it's control interface and make use of the P2P_* API and pass-on information about WiFi-P2P connections/peers. On some OS, access to the wpa_supplicant control socket is limited. However, it may be possible to have the OS network management pass-through or allow indirect access of the P2P API. On yet other platforms, P2P is highly integrated with mDNS service announcement/discovery... An alternative to using wpa_supplicants's P2P API could be using IBSS/Ad-Hoc mode or even 802.11s with pre-defined parameters, which is merely a matter of documentation and having some sort of broadcast/multicast peer discovery (see 0003866) | ||||
| Additional Information | wpa_supplicant's API at http://w1.fi/wpa_supplicant/devel/ctrl_iface_page.html Related to https://gnunet.org/bugs/view.php?id=3866 | ||||
| Tags | tng | ||||
|
|
Sounds nice, are you planning/willing to help with this? |
|
|
Directly using wpa_supplicant's control socket seems to be the way. Code example: http://cgit.freedesktop.org/~dvdhrm/miracle/tree/src/wifi Note that there may be several instances of wpa_supplicant running on a system. On some (proprietary) platforms, p2p_supplicant and wpa_supplicant each provide individual sockets. A gnunet-wpa_supplicant-helper should thus glob for available control sockets and connect to ALL of them and probe their P2P capabilities. It should announce the gnunet service and periodically scan for other p2p peers using all P2P-capable supplicants. If peers are found, it should setup a P2P connection, a deterministic order e.g. over some least-significant-bits of the peers pubkeys can decide which role (GO or client) to setup on each side. If IPv6 link-local addressing is enough for GNUnet's UDP transport to work, the resulting P2P interface should be usable for plugin_transport_udp_broadcasting. Related discussions: https://bugzilla.gnome.org/show_bug.cgi?id=734073 https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00018.html |
|
|
My perspective on this issue has suddenly changed due to http://ml.ninux.org/pipermail/battlemesh/2017-April/005445.html and the realization that support for injecting frames at arbitary legacy, MCS and VHT bitrates has been (re-)added to mac80211 on Linux about a year ago. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-06-27 02:41 | dangole | New Issue | |
| 2015-06-27 16:47 | Christian Grothoff | Severity | minor => feature |
| 2015-06-27 16:47 | Christian Grothoff | Status | new => confirmed |
| 2015-06-27 16:47 | Christian Grothoff | Product Version | => Git master |
| 2015-06-27 16:47 | Christian Grothoff | Note Added: 0009351 | |
| 2015-06-27 17:52 | dangole | Note Added: 0009354 | |
| 2017-04-21 20:53 | dangole | Note Added: 0012055 | |
| 2020-10-29 10:54 | schanzen | Tag Attached: tng | |
| 2020-10-29 10:54 | schanzen | Target Version | => 0.15.0 |
| 2021-06-10 19:36 | schanzen | Target Version | 0.15.0 => 0.16.0 |
| 2021-12-31 09:29 | schanzen | Target Version | 0.16.0 => 0.17.0 |
| 2021-12-31 09:32 | schanzen | Target Version | 0.17.0 => 1.0.0 |
