[OpenWrt-Devel] [PATCH v3] wpa_supplicant: fix generating phase2 config line for WPA-EAP
Felix Fietkau
nbd at openwrt.org
Sun Jan 17 05:36:48 EST 2016
On 2016-01-12 17:43, Daniel Golle wrote:
> Hi Felix,
>
> I started working on fixing the WPA-EAP client support and while
> reviewing your suggestions and the reading the scripts and hostap
> sources, I had some realizations and suggest to do things in yet
> another way:
>
> On Sun, Jan 03, 2016 at 10:13:17PM +0100, Felix Fietkau wrote:
>> On 2016-01-03 22:06, Daniel Golle wrote:
>> > Hi Felix,
>> >
>> > On Sun, Jan 03, 2016 at 09:33:13PM +0100, Felix Fietkau wrote:
>> >> > - append network_data "phase2=\"$auth\"" "$N$T"
>> >> > + append network_data "phase2=\"auth=$auth\"" "$N$T"
>> >> This might break existing configurations that already include the auth=
>> >> part, so when reworking this part you should detect and fix this.
>> >> Also, for EAP-TLS, phase2 needs to be autheap=TLS, which is not
>> >> supported with this change.
>
> The change I suggested is inside a case-section
> case "$eap_type" in
> ...
> peap|ttls)
> ...
> so it will only affect PEAP and TTLS and leave anything belonging to
> TLS unchanged.
>
>> >
>> > Right... Probably this should be changed in LuCI then, because
>> > currently $auth is set to values like 'PAP', 'MSCHAPV2', ... see
>> > https://github.com/openwrt/luci/blob/master/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua#L897
>> > which still matches the pre-netifd behaviour as defined in
>> > https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant.sh#L107
>> > which is what I wanted to restore.
>> > Having a complex value stored in UCI and leaving it to the user/view
>> > to set it seems a bit odd to me (but might still be the best thing to
>> > do), maybe we should rather store eap_type in UCI as well and then
>> > generate the phase2 string in netifd.sh according to that...?
>> >
>> > Let me know what you think and I'll suggest a follow-up patch.
>> How about this:
>>
>> If $auth is set, add it with auth=$auth (strip existing auth= from the
>> variable if present).
>>
>> Then add an eap_auth config option (should be a list), add autheap=<val>
>> for every entry (I think there can be multiple ones).
>>
>> That way you can configure everything and avoid complex UI-hostile types.
>
> Reading up the wpa_supplicant source and test-cases, I found out that
> EAP-TTLS/EAP-MSCHAPv2 and EAP-TTLS/MSCHAPv2 are different methods.
> This is probably for historic reasons as MSCHAPV2 and PAP are stone-age
> protocols originally intended for PPP and thus precede the introduction
> of EAP. Other, more modern protocols, build upon EAP and thus cannot be
> used stand-alone, e.g. EAP-TTLS/EAP-GTC. It thus depends on the vendors
> whether they use MSCHAPV2 as a stand-alone phase2 or wrap it in EAP...
> Have a look at
> https://hostap.epitest.fi/cgit/hostap/diff/tests/hwsim/test_ap_eap.py
> where both methods, EAP-TTLS/MSCHAPV2 and EAP-TTLS/EAP-MSCHAPV2 got
> their corresponding test-cases and are simply being treated as
> different methods.
> To remain compatible with existing configurations, I suggest to:
> Check if $auth starts with string "auth", if so, just set it as phase2
> without changes. This will allow existing configurations which relied
> on the previous behaviour to keep working.
I think this approach makes sense.
> If $auth starts with "EAP-", strip those four characters and pass
> phase2="autheap=$auth", e.g. if auth is set to "EAP-MSCHAPV2" set
> phase2="autheap=MSCHAPV2".
> This will allow to simply add new options for auth to the list in LuCI:
> EAP-GTC, EAP-MD5, EAP-MSCHAPV2, EAP-PAP.
What about supporting multiple auth variants simultaneously? I see some
configurations using that, but I'm not sure if it's necessary or for
which cases it's relevant. Your code does not cover it, but it should be
easy enough to add. Do you think it's worth it?
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list