At most a partial answer but too much for reasonable comments.
ECDHE does NOT require TLS1.2, only 1.0 as I said in the comment. I used it often in openssl 1.0.0 which doesn't even implement 1.2, and still test fine by specifying 1.0 in current openssl or using non-bleeding java (j7 can do 1.1 and 1.2 but defaults to 1.0). In fact openssl actually supports ECDHE (and other ECC features) on SSL3, which the RFC does not call for so it works for openssl-to-openssl but not necessarily with other implementations; but there is no good reason to use that when more robust TLS1.0 is available. The only cipher features that require TLS1.2 are AEAD (in openssl GCM) and SHA2. If your app(s) is requiring say ECDHE-ECDSA-AES128-SHA256 but not ECDHE-ECDSA-AES128-SHA, that would fail on 1.0. What ciphers are offered in your ClientHello? Some googling finds http://w1.fi/wpa_supplicant/devel/tls__openssl_8c.html which suggests at least the possibility to specify the list of ciphers as of 2012, but I didn't see any doc on if and how a user controls this.
Which reminds me: are you looking at the correct version in ClientHello? There are two versions: record layer and handshake. OpenSSL uses "Record Layer" version 0301 (TLS1.0) for ClientHello to offer a range of protocols, to ensure a peer that implements only an older version will "negotiate down" correctly; it is the version under "Handshake Protocol: Client Hello" that specifies the offered version. And you still didn't say what the response is in Wireshark: is there an alert and with what code, or something else, or what?
That said, you may want TLS1.2 for its other benefits or just futureproofing. Among the protocols that openssl implements, the ones it offers for a client or accepts for a server are controlled by calls the respective client or server application code makes. The starting point for an
SSL_CTX are "methods" for a specific protocol like
TLSv1_2_*method, or the "generic"
SSLv23_*method (a legacy name that is now misleading and may be changed in a future openssl version) followed by
SSL_[CTX_]set_options with (among others)
Assuming per above your ClientHello is record version 0301 AND handshake version 0301, meaning TLS1.0 only, it might well be that wpa_supplicant was coded to do specifically
TLSv1_*method. This could have made sense ten years ago when TLS1(.0) was the best available, and there were issues with SSLv2 being attackable and SSLv3 being unacceptable for USgovt use (though then actually safe) so someone might reasonably have felt "we'll protect those @#? users from making a mistake and doing something insecure by forcing TLS1". If so, the passage of time has made this thinking wrong.