GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
robimarko has joined #openwrt-devel
<xback>
djfe: I have the same issue
<xback>
it's a hostapd issue as I make configs for that app directly
<xback>
it doesnt seem to care a lot what channels are defined
<xback>
was going to ask upstream about this
stintel has quit [Ping timeout: 480 seconds]
<f00b4r0>
auto + channels definitely works for me in 22.03
<xback>
f00b4r0: ACS + chanlist technically works, as the AP starts, but when defining a chanlist .. hostapd still tends to use channels which are not defined
<f00b4r0>
no I mean it *works* :)
<xback>
even after 100 restarts?
<xback>
meaning that it selects a channel from the list each and every time
<f00b4r0>
i haven't tried that far but I have occasional DFS channel switches and so far so good, afaict
<xback>
i've tested this in an RF chamber with a specific test country code (XA) which has DFS disabled on alle channels etc
<f00b4r0>
client of mine is using the feature in 21.02, I'll ask if they've seen oddities
<xback>
and after 100 reboots, it chose a channel which was not specified in the chanlist for about 30% of the time
<f00b4r0>
xback: I'm assuming this is running master?
<xback>
f00b4r0: yes
<xback>
there are some other issues too still in master .. but still investigating those
<f00b4r0>
hence me pointing at older versions.
<f00b4r0>
"could it be something new?" is what I'm trying to say here :)
<xback>
could very well be
<f00b4r0>
i've also noticed that in 23.05, the reported rates in ubus calls have switches from kbps to kbps*10
<xback>
but I want to avoid that people test it 1 time and conclude it works if a correct channel was chosen by random :-)
<f00b4r0>
(which blew up some of my code :)
<xback>
aah, that didn't bother me as I fetch those directly through netlink
<f00b4r0>
xback: I haven't tested 100 times, but I've been running the configuration for $time, where $time is many months
<xback>
ok, clear
<xback>
f00b4r0: I also noticed that wifi tends to disconnect once in a while
<robimarko>
f00b4r0: I have a feeling that upstream hostapd changed the stat format
<f00b4r0>
robimarko: *nod*
<robimarko>
As ubus code did not change
<xback>
AP / STA setup, single SSID, background scanning disabled, etc
<f00b4r0>
xback: I've seen that too, but couldn't track it down
<xback>
it then just reports this: wlan1: deauthenticated from 78:9a:18:07:c8:01 (Reason: 7=CLASS3_FRAME_FROM_NONASSOC_STA)
<f00b4r0>
i'll check logs next time it occurs, I don't remember exactly what was going on
<xback>
and sometimes also this: wlan1: deauthenticated from 78:9a:18:07:c8:01 (Reason: 3=DEAUTH_LEAVING)
<xback>
without any reason why it should deauth ..
<f00b4r0>
client has some devices where wifi apparently "hangs", requiring cycling (wifi down/wifi up) to start accepting clients again
<xback>
f00b4r0: yes, also noticed that here since the latest bump
<f00b4r0>
that's been a long standing issue for them (19.07 or before AIUI)
<xback>
currently making a build with maximum hostapd in it to get debug logs ..
<xback>
the stup here is 5x wapac ipq40xx, WDS mode, each having 8 wapac ipq clients (with a network behind each) in wds mode
<stintel>
25|13:15:27 [OFTC] -!- #openwrt-devel Cannot join channel (Need to be identified and verified to join this channel, '/msg NickServ help' to learn how to