Bug 13923

Summary: Default setting from hostapd in CU199 results in exessive logs
Product: IPFire Reporter: Horst Moelleman <Brottus>
Component: ---Assignee: Assigned to nobody - feel free to grab it and work on it <nobody>
Status: CLOSED FIXED QA Contact:
Severity: Minor Usability    
Priority: - Unknown - CC: adolf.belka, bernhard.leeb, horace.michael
Version: 2   
Hardware: unspecified   
OS: Linux   

Description Horst Moelleman 2026-01-10 19:07:23 UTC 
Dear Community,
as mentioned in https://community.ipfire.org/t/core-199-hostapd-write-exessives-logs/15403 when using the web gui for hostapd and configure it accordingly currently the logging will be set to EXESSIVE in hostapd.
[]# hostapd_cli -i 'green0p0' log_level
Current level: EXCESSIVE
Timestamp: 0
This results in a vast amount of logs which killed my disk ヾ(≧▽≦*)o.
Manually setting the value to ERROR via "hostapd_cli -i ‘green0p0’ log_level ERROR" fixes the issue until the next boot.
So the way i found the workaround is locking into this https://github.com/openwrt/packages/issues/26280 . Not sure if this is true for all hostapd implementations or just for openwrt but the workaround works the same way.

Hope this helps a bit to dig depper into it. Thanks for your efforts.
Comment 1 Adolf Belka 2026-01-10 19:32:48 UTC 
For IPFire-2.x the component should always be ---
Comment 2 grisu127 2026-01-12 08:30:12 UTC 
I also see that hostapd log has increased to 50-100 entries per second since Core Update 199.
The interim solution from Horst Moelleman is working on my system. I used the following commands:

Check initial state:

hostapd_cli -i 'blue0' log_level
 Current level: EXCESSIVE
 Timestamp: 0

change log-Level:

hostapd_cli -i 'blue0' log_level ERROR
 OK

Check status again:

hostapd_cli -i 'blue0' log_level
 Current level: ERROR
 Timestamp: 0
Comment 3 Adolf Belka 2026-01-12 15:01:36 UTC 
A DEBUG entry was used in the wlanap settings file in CU187 and earlier. The DEBUG settings was removed from the wlanap.cgi WUI page in CU188 but users that were using the wlanap capability with Core Updates earlier than 188 would likley have had an entry of DEBUG= in the settings file. This would have been a number between 4 and 0 with 4 being warnings and 0 being verbose. The default setting was 4

From CU188 the DEBUG entry was removed from the wlanap WUI page but the entry would stay in the settings file from the previous usage.

Any user starting with wlanap addon from CU188 onwards will not have any DEBUG entry in the settings file.

Unfortunately my previous use of wlanap with my Prime IPFire system had a problem which caused it to require to be freshly installed so I can't go back and check that, although it is also quite likely that I started using the wlanap after CU187 as CU188 was released in Sep 2024 which I think is just a bit before I got my Prime IPFire system.
Comment 4 Adolf Belka 2026-01-31 20:46:31 UTC 
Patch to fix this has been merged into CU200

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=42732fe154b38287278355fd300e878f0786a8fa
Comment 6 Adolf Belka 2026-02-06 15:07:00 UTC 
Patch has been updated to also remove any existing HTCAPS or VHTCAPS entries.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=fe9d3554182d541996af8df59acaf8a66cca0d81