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