View Issue Details

IDProjectCategoryView StatusLast Update
0003867GNUnetWLAN transportpublic2017-04-21 20:53
ReporterdangoleAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status confirmedResolutionopen 
Product VersionSVN HEAD 
Target VersionFixed in Version 
Summary0003867: Fast WiFi transport / setup-helper should be implemented
DescriptionThe 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 Informationwpa_supplicant's API at
http://w1.fi/wpa_supplicant/devel/ctrl_iface_page.html

Related to
https://gnunet.org/bugs/view.php?id=3866
TagsNo tags attached.

Activities

Christian Grothoff

2015-06-27 16:47

manager   ~0009351

Sounds nice, are you planning/willing to help with this?

dangole

2015-06-27 17:52

developer   ~0009354

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

dangole

2017-04-21 20:53

developer   ~0012055

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.

Issue History

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 => SVN HEAD
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