hostapd: Update to version 2.8 (2019-04-21)

This also syncs the configuration files with the default configuration
files, but no extra options are activated or deactivated.

The mesh patches were partially merged into hostapd 2.8, the remaining
patches were extracted from patchwork and are now applied by OpenWrt.
The patches still have open questions which are not fixed by the author.
They were taken from this page:
https://patchwork.ozlabs.org/project/hostap/list/?series=62725&state=*

The changes in 007-mesh-apply-channel-attributes-before-running-Mesh.patch
where first applied to hostapd, but later reverted in hostapd commit
3e949655ccc5 because they caused memory leaks.

The size of the ipkgs increase a bit (between 1.3% and 2.3%):

old 2018-12-02 (2.7):
283337 wpad-basic_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk
252857 wpad-mini_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk
417473 wpad-openssl_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk
415105 wpad-wolfssl_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk

new 2019-04-21 (2.8):
288264 wpad-basic_2019-04-21-63962824-1_mipsel_24kc.ipk
256188 wpad-mini_2019-04-21-63962824-1_mipsel_24kc.ipk
427475 wpad-openssl_2019-04-21-63962824-1_mipsel_24kc.ipk
423071 wpad-wolfssl_2019-04-21-63962824-1_mipsel_24kc.ipk

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>

1 files changed, 0 insertions, 40 deletions

diff --git a/package/network/services/hostapd/patches/065-0001-EAP-pwd-server-Fix-reassembly-buffer-handling.patch b/package/network/services/hostapd/patches/065-0001-EAP-pwd-server-Fix-reassembly-buffer-handling.patch
deleted file mode 100644
index b98e183244..0000000000
--- a/package/network/services/hostapd/patches/065-0001-EAP-pwd-server-Fix-reassembly-buffer-handling.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From fe76f487e28bdc61940f304f153a954cf36935ea Mon Sep 17 00:00:00 2001
-From: Jouni Malinen <jouni@codeaurora.org>
-Date: Wed, 17 Apr 2019 01:55:32 +0300
-Subject: [PATCH 1/3] EAP-pwd server: Fix reassembly buffer handling
-
-data->inbuf allocation might fail and if that were to happen, the next
-fragment in the exchange could have resulted in NULL pointer
-dereference. Unexpected fragment with more bit might also be able to
-trigger this. Fix that by explicitly checking for data->inbuf to be
-available before using it.
-
-Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
----
- src/eap_server/eap_server_pwd.c | 8 +++++++-
- 1 file changed, 7 insertions(+), 1 deletion(-)
-
---- a/src/eap_server/eap_server_pwd.c
-+++ b/src/eap_server/eap_server_pwd.c
-@@ -947,6 +947,12 @@ static void eap_pwd_process(struct eap_s
- 	 * the first and all intermediate fragments have the M bit set
- 	 */
- 	if (EAP_PWD_GET_MORE_BIT(lm_exch) || data->in_frag_pos) {
-+		if (!data->inbuf) {
-+			wpa_printf(MSG_DEBUG,
-+				   "EAP-pwd: No buffer for reassembly");
-+			eap_pwd_state(data, FAILURE);
-+			return;
-+		}
- 		if ((data->in_frag_pos + len) > wpabuf_size(data->inbuf)) {
- 			wpa_printf(MSG_DEBUG, "EAP-pwd: Buffer overflow "
- 				   "attack detected! (%d+%d > %d)",
-@@ -967,7 +973,7 @@ static void eap_pwd_process(struct eap_s
- 	 * last fragment won't have the M bit set (but we're obviously
- 	 * buffering fragments so that's how we know it's the last)
- 	 */
--	if (data->in_frag_pos) {
-+	if (data->in_frag_pos && data->inbuf) {
- 		pos = wpabuf_head_u8(data->inbuf);
- 		len = data->in_frag_pos;
- 		wpa_printf(MSG_DEBUG, "EAP-pwd: Last fragment, %d bytes",