Hi kszaq,
I've been compiling your tree since v7.0.2.009 along with a `hostapd` package I wrote myself, and everything was working fine when setting up a network on `wlan0` (just had to ask `connman` to ignore this network device).
However since the 8.x upgrade trying to run `hostapd` on `wlan0` fails massively, the program segfaults and then the box (S905x) enters a boot loop. That makes no sense to me, as everything used to run just fine, I've tried downgrading `connman`, upgrading `hostapd` (2.5 → 2.6), using the proper DTB as opposed to the master one compiled… The only thing I haven't tried is downgrading the kernel because it's not as simple as changing the hash in the `options` file, and the `rtl8189es` driver hasn't changed anyway.
Do you have any hunch as to what could possibly be going on please ?
`hostapd` log:
random: Trying to read entropy from /dev/random
Configuration file: /tmp/hostapd.conf
drv->ifindex=3
l2_sock_recv==l2_sock_xmit=0x0x750ae8
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
Allowed channel: mode=1 chan=1 freq=2412 MHz max_tx_power=0 dBm
[…]
Allowed channel: mode=2 chan=165 freq=5825 MHz max_tx_power=0 dBm
Completing interface initialization
Mode: IEEE 802.11g Channel: 6 Frequency: 2437 MHz
DFS 0 channels required radar detection
RATE[0] rate=10 flags=0x1
RATE[1] rate=20 flags=0x1
RATE[2] rate=55 flags=0x1
RATE[3] rate=110 flags=0x1
RATE[4] rate=60 flags=0x0
RATE[5] rate=90 flags=0x0
RATE[6] rate=120 flags=0x0
RATE[7] rate=180 flags=0x0
RATE[8] rate=240 flags=0x0
RATE[9] rate=360 flags=0x0
RATE[10] rate=480 flags=0x0
RATE[11] rate=540 flags=0x0
hostapd_setup_bss(hapd=0x751170 (wlan0), first=1)
wlan0: Flushing old station entries
Segmentation fault
Display More
write(1, "hostapd_setup_bss(hapd=0x1f6170 "..., 50hostapd_setup_bss(hapd=0x1f6170 (wlan0), first=1)
) = 50
write(1, "wlan0: Flushing old station entr"..., 36wlan0: Flushing old station entries
) = 36
ioctl(4, _IOC(0, 0x8b, 0xfc, 0x00) <unfinished ...>
+++ killed by SIGSEGV +++
Segmentation fault
It definitely looks like a driver issue (because of the `ioctl` call), but I don't understand why this issue would completey lock the device up in a boot loop afterwards.
Thanks.