On Mon, 2019-08-19 at 13:37 +0200, Josef Miegl wrote:
> On Mon, Aug 19, 2019 at 12:12:43PM +0200, Johannes Berg wrote:
> > Contrary to what Sebastian states, it certainly is possible today,
> > although not through wpa_supplicant's config file, only through the
> > wpa_cli interface, using the VENDOR_ELEM_ADD command. There are various
> > tests showing how to use this.
>
> Thanks Johannes. I noticed this too and tried adding a config file
> option (OpenWRT doesn't compile wpa_supplicant with wpa_cli). I've added
> sta_vendor_elements option (exactly like ap_vendor_elements). This is
> the code setting vendor_elem:
>
> +++ b/wpa_supplicant/wpa_supplicant.c
> @@ -5833,6 +5833,16 @@
> wpas_mbo_update_non_pref_chan(wpa_s, wpa_s->conf->non_pref_chan);
> #endif /* CONFIG_MBO */
>
> + if (wpa_s->conf->sta_vendor_elements) {
> + if (wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ] == NULL) {
> + wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ] =
> wpa_s->conf->sta_vendor_elements;
> + } else {
> +
> wpabuf_resize(&wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ],
> wpabuf_len(wpa_s->conf->sta_vendor_elements));
> +
> wpabuf_put_buf(wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ],
> wpa_s->conf->sta_vendor_elements);
> + }
> + }
> +
> wpa_supplicant_set_default_scan_ies(wpa_s);
>
> return 0;
>
>
> But when I actually set sta_vendor_elements to something, all it does is
> failing the 4-way handshake during association. The IE is perfectly
> valid and it works with ap_vendor_elements, no nl80211 malformed IEs
> error either. Am I missing something?
I don't know, try capturing over the air?
Perhaps the vendor IEs added this way are added *first* before all the
RSN IEs, and that's tripping up your AP, and you'd have to add them
*after* the normal elements? Not really sure where/how they're added?
johannes
