Please suggest the best way to debug hostapd on Debian (Access Point stability problem)

[Kirill Peskov]

On 06/09/16 18:03, Jouni Malinen wrote:
> On Tue, Sep 06, 2016 at 10:54:39AM +0200, Kirill Peskov wrote:
> That sounds like a driver issue or something in the kernel 802.11
> implementation rather than something in hostapd.
>
>> Watching -dd output of hostapd shows nothing unusual.
> hostapd should not be involved during normal data traffic, so this is
> not surprising. Restarting hostapd will reset state in the driver and
> hardware/firmware and that seems to be sufficient to recover from
> whatever state the device reached.
>
>> What would be the best approach to debug/pinpoint the problem? I can
>> download hostapd sources and use (for example) CodeLite as IDE for
>> debugging or any other suggested debugger.
> I'd look at the driver behavior rather than hostapd..
>

It definitely looks as platform-specific issue. Today I started to test
the same card again on both Raspberry Pi 3 and x86_64 and came to the
following situation:


Card is, as said earlier, Ralink-based Dual Band (Alfa Networks AWUS052NH).

Hostapd configuration (4 virtual SSIDs), routing tables, iptables, tor
and openvpn configurations are identical


Here comes the difference:

* PC (AMD x86_64), Debian 8, Linux kernel: 3.16.0-4-amd64

The card is working stable in both bands, 2.4 and 5GHz, the issue
described in the original post seems to be related to routing/tunnel/tor
transport stability, despite my assumptions.


* Raspberry Pi 3 (arm7), Raspbian Jessie, Linux kernel 4.4.13-v7+

On 2.4 GHz it looks stable already several hours (still running the test).

But on 5 GHz it takes 5 to 20 minutes and the AP dies completely (no
SSID longer visible in the air). hostapd daemon is still running, but
upon receiving stop signal drops occasionally 'Segmentation fault' (to
the console or log file, depending on the start mode). What is really
strange, that I have to reboot the Pi completely, otherwise hostapd is
no longer able to start, blaming 'resource busy' even after un- and
replugging the card.


So looks definitely like driver's issue, but the question is, what would
be the fastest way to pinpoint the root of the problem?


Kirill