iwinfo {phy} assoclist will cause segfault and crash rpcd if approx 150+ clients connected to AP

[mrisaev]

buffersize hardcoded in iwinfo.h
#define IWINFO_BUFSIZE 24 * 1024

in my setup size of the one item in assoclist output is around 175 Byte so:

24 x 1024 / 175 = 140 clients won't cause any problems, but when there is more, iwinfo assoclist
crashes with segfault in luci overview page and wireless page uses this function and crashes rpcd service.

'iw {phy} stations dump -v' - works fine in same conditions.

[Ansuel]

Interesting bug... I need to check how this can be repro.

[morse-evanbenn]

Hi @Ansuel, 802.11ah (HaLow) wifi supports > 8000 associated stations. It would be great if we could enhance iwinfo/libiwinfo to read the assoclist when there are many stations connected to the AP. I have made a patch on our openwrt/iwinfo fork that increases the BUFSIZE to handle this case.

I see your fix has truncated the results at the buffer size. Is there any possibility of a fix that allows iwinfo to pass through however many stations are actually connected? It seems like this might require a breaking API change. Some ideas:

1. Breaking API change - allow the caller to provide an arbitrary length buf + len and truncate the results if neccesary (with a warning to the caller?)
2. Breaking API change - allocate in the library and return the new buffer
3. Increase the IWINFO_BUFSIZE to 8096 * sizeof struct iwinfo_assoclist_entry - not sure if that counts as breaking.
4. Add a assoclist_v2 or whatever, that has one of the above different semantics.

The 3. approach might be the easiest, but all of the callers I have seen are using a stack allocated buffer and may have issues with such a large stack. The patch I made instead mallocs the buffer, which has the advantage of not actually using the memory unless via linux demand paging.

I am able to help with the implementation of this if I can, please let me know your thoughts.