02:00 <owrt-snap-builds> Build [#457](https://buildbot.openwrt.org/master/images/#builders/7/builds/457) of `armvirt/32` failed.

07:19 <owrt-snap-builds> Build [#422](https://buildbot.openwrt.org/master/images/#builders/40/builds/422) of `ipq40xx/mikrotik` failed.

08:35 <owrt-snap-builds> Build [#381](https://buildbot.openwrt.org/master/images/#builders/71/builds/381) of `bcm4908/generic` completed successfully.

11:57 <owrt-snap-builds> Build [#419](https://buildbot.openwrt.org/master/images/#builders/22/builds/419) of `ipq40xx/generic` failed.

12:59 <owrt-snap-builds> Build [#438](https://buildbot.openwrt.org/master/images/#builders/4/builds/438) of `x86/generic` completed successfully.

13:08 <neggles> hm. that's... problematic. both of the radios on this AP are the same chip, and they're both showing up as 5GHz when one is meant to be 2.4GHz (technically I think it's switchable), and the bmi_id for board data is coming up as N/A

13:08 <neggles> ath10k will be the death of me

13:38 <owrt-snap-builds> Build [#411](https://buildbot.openwrt.org/master/images/#builders/50/builds/411) of `mediatek/mt7623` completed successfully.

13:44 <owrt-snap-builds> Build [#423](https://buildbot.openwrt.org/master/images/#builders/9/builds/423) of `lantiq/ase` completed successfully.

14:06 <owrt-snap-builds> Build [#424](https://buildbot.openwrt.org/master/images/#builders/45/builds/424) of `bcm47xx/legacy` completed successfully.

14:06 <owrt-snap-builds> Build [#416](https://buildbot.openwrt.org/master/images/#builders/33/builds/416) of `ipq806x/generic` completed successfully.

14:53 <huaracheguarach> I'm trying to implement Operating Channel Validation in OpenWrt, and I'm trying to think a bit ahead in terms of how this will work with luci. So, if the driver handles sme it needs to support OCV in order for it to work, but if hostapd handles sme it doesn't depend on driver support. It doesn't make a lot of sense to show an option to enable OCV in luci if the driver handles sme and doesn't support it. Is there any

14:54 <Habbie> huaracheguarach, you got truncated after "Is there any"

14:54 <huaracheguarach> Habbie: ah, thanks. Here's the rest: Is there any way to check whether the driver is handling sme?

15:05 <owrt-snap-builds> Build [#416](https://buildbot.openwrt.org/master/images/#builders/56/builds/416) of `kirkwood/generic` completed successfully.

16:38 <huaracheguarach> If I edit a patch to make it apply after a refresh do I have to sign off in the patch header?

18:01 <dwfreed> neggles: my gl-mt1300 is like that, sort of; one radio is dual-band, one is 5g only; luci gets a little confused until they have ssids assigned to them

18:18 <jow> dwfreed: define confused. both shown as "abgn" ?

18:20 <dwfreed> bgn I think? but something like that; device is put away at the moment, so I can't check

18:21 <dwfreed> it's also really borked on 21.02, but works on the snapshot version i updated it to

18:29 <jow> ok

18:31 <dwfreed> if I had more time I would properly debug it, but unfortunately I do not

18:31 <dwfreed> but on 21.02, netifd reports it cannot find the phy for radio1; using iw manually works fine, however

18:32 <dwfreed> radio0 is dual-band, and radio1 is 5ghz only

19:00 <hurricos> Err, does anyone know how different the https://www.zyxelguard.com/GS1900-24HP.asp is from the GS1900-24HP v2?

19:20 <hauke> svanheule: What is the status on the realtek patches you send in December? I saw there was a discussion about waiting some more time till adding this into upstream kernel.

19:20 <hauke> and how to handle SMP

19:21 <svanheule> hauke: I don't think Birger and I agreed on how to proceed

19:21 <svanheule> hauke: I've sent that extra SMP patch to upstream, and it was accepted with a small additional change

19:21 <hauke> ok

19:21 <hauke> are the realtek patchs already upstream?

19:21 <svanheule> hauke: so I've got SMP working on RTL8390/RTL9300 with a mainline kernel, /but/ I don't have it working properly with the IRQ driver yet

19:22 <svanheule> some are: gpio, watchdog

19:22 <svanheule> and IRQ and SPI

19:22 <svanheule> but the realtek IRQ driver needs some fixes, and the maintainer was being picky on how I should implement them >_>

19:23 <hauke> ok

19:23 <svanheule> see https://lore.kernel.org/all/cover.1641739718.git.sander@svanheule.net/

19:23 <svanheule> haven't gotten a reply on the latest version since 2022-01-09

19:24 <svanheule> so I'm working on it, but I don't have much help atm :-/

19:24 <hauke> svanheule: ok then I will not apply your patches to OpenWrt for now

19:24 <hauke> and wait till this is sorted out

19:24 <svanheule> hauke: Ok. I might have a call with Birger this week, we can discuss it then.

19:26 <hauke> ok

19:33 <svanheule> hauke: I'll need to send another version of that series anyway, so I'll mark the current patches with "changes requested"

19:43 <hauke> svanheule: thanks

20:51 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html

21:15 <slh> hurricos: probably not too many differences, but possibly only 64 MB RAM

21:18 <neggles> dwfreed: iw gets confused as well, I think because it’s not finding the board data in board-2.bin

21:27 <neggles> jow: both radios show as nac, there’s no indication that one is meant to be 2.4GHz capable :/

21:31 <owrt-snap-builds> Build [#458](https://buildbot.openwrt.org/master/images/#builders/7/builds/458) of `armvirt/32` completed successfully.

21:36 <nlowe> hostapd / wpa-supplicant 2.10 has released with security fixes for SAE - there's also hash to element support that can be enabled

21:37 <nlowe> hash to element aims to remove the fragility to timing side channel attacks that otherwise have to be carefully controlled with constant time operations

21:59 <hurricos> slh :D thanks, I'll go buy

22:03 <slh> hurricos: the zyxel gs1900 switches are all very similar

22:23 <hexa-> https://w1.fi/security/2022-1/sae-eap-pwd-side-channel-attack-update-2.txt

22:54 <hauke> is someone working on a hostapd 2.10 update for OpenWrt master?

23:10 <rsalvaterra> hauke: No, but the that side channel attack seems like the perfect incentive. :P

23:15 <rsalvaterra> hauke: The hostpad makefile points to a specific commit, not version 2.9. Should we keep doing the same, point at the 2.10-tagged commit?

23:16 <nlowe> With hostapd 2.10, I suggest considering also setting sae_pwe to 2 in the hostapd.conf to enable both hunting-and-pecking loop (timing side channel fragile) and hash-to-element (not fragile)

23:16 <nlowe> Windows 11 will use hash to element if offered

23:26 <hauke> rsalvaterra: we normally used a git hash because there was no release for a long time

23:26 <hauke> the harder part is adapting the patches and tetsing this

23:26 <rsalvaterra> That was my suspicion too.

23:28 <neggles> i wouldn’t think that sidechannel attack is particularly important for OpenWRT in most use cases; if an attacker is able to run code that can make those measurements, they can probably just go read /etc/config/wireless

23:28 <hauke> rsalvaterra: openwrt 19.07 uses hostapd 2.9 later we used some master snapshot

23:28 <slh> you can't depend on regular or timely hostapd releases, so sticking to the v2.10 git hash would be a good idea

23:28 <hauke> slh: I agree

23:28 <rsalvaterra> I agree too.

23:28 <neggles> (that’s not a reason to not update though)

23:29 <rsalvaterra> And indeed, whoever gets to rebase the patches is in for a bad time… :P

23:29 <slh> of course not, that was merely about the package version indicator

23:29 <hauke> as there is a version now it would be nice to use it or the git hash of the version

23:30 <neggles> ah sorry I was continuing my earlier message, not commenting on git hash vs tag

23:30 <rsalvaterra> cff80b4f7d3c0a47c052e8187d671710f48939e4

23:36 <neggles> hmm, I can get one of these QCA9990s to come up, presumably the 5GHz one, but not the other, and hotplug doesn’t seem to be doing the caldata extraction from the ART

23:39 <rsalvaterra> And our second hostapd patch is already proving to be a pain.

23:39 <rsalvaterra> Rats…

23:39 <rsalvaterra> The world moved a lot since last time.

23:41 <rsalvaterra> I think I'll skip this one and leave it for someone who understands the code better than me (I'm looking at it for the first time).

23:42 <slh> there are two major/ painful patches, first of all the multi-call binary (wpad) patches, then the unmerged mesh patches...

23:42 <rsalvaterra> slh: The multicall thingy is actually quite trivial, imho.

23:45 <rsalvaterra> In concept, I mean. But I guess you're referring to the changes hostapd/wpa_supplicant require.

23:46 <rsalvaterra> I wonder why we carry so many hostapd patches… aren't they upstreamable at all? :/