06:16 <owrt-images-builds> Build [#116](https://buildbot.staging.openwrt.org/images/#/builders/159/builds/116) of `openwrt-23.05_bcm27xx/bcm2708` failed.

06:30 <quinq> Thanks slh, noted :)

16:11 <hitech95> Ansuel, can you give me help on the patch refresh?

18:03 <jeff___m> Hey Robimarko, thanks for your help earlier. I was looking at the ath11k board-2.bin and only saw about 5 possible board-id values, and was thinking of trying to brute force the correct value while I wait on Compex to fully respond. Can you help me understand what the entry should look like in my DTS? Also, Is there a way to attempt to try QSDK drivers? I have a hard time believing there's not

18:03 <jeff___m> a working driver out there for this board Compex is selling commercially!

18:26 <robimarko> jeff__m: Look at AX9000, its using board variant for ath11k on PCI

18:26 <robimarko> https://github.com/openwrt/openwrt/blob/main/target/linux/qualcommax/files/arch/arm64/boot/dts/qcom/ipq8072-ax9000.dts#L485

18:26 <robimarko> Of course, you PCI node will differ

18:26 <robimarko> You cannot use the propriatery driver as its closed source

18:27 <robimarko> Also, it would not have helped as it uses the same BDF as well

18:28 <PaulFertser> Aha, I told you it's not qcom,board-id for property name :)

18:29 <robimarko> There is no way to override the detected board-id, there was a long time ago but its really not needed

19:48 <mrkiko> hi all!! Moving home, so not regularly at PC these days

19:48 <philipp64> Ansuel: what woudl be involved in adding CI/CD regressions for PR #13765?

19:56 <Ansuel> philipp64 not a chance to have that in openwrt core... that is way i was thinking for a C tool... (as that would permit to move it in a separate repo and run test on it)

19:57 <Ansuel> or we can consider a meme repository with a single shell script ahahah

19:58 <philipp64> not following... you're saying there's no way it will make it in?

19:59 <Ansuel> no I was referring to introducing regression test for ipcal.sh

20:00 <philipp64> ah. I thought all of that was in a separate repo

20:00 <Ansuel> to do regression test we need to move the script to a separate repository

20:00 <philipp64> I guess all we really need is a sufficient sample using the old script, capture the output, then test the output of the new script and do a blind compare...

20:01 <philipp64> hm...

20:02 <Ansuel> philipp64 if we really want... an idea might be find an equivalent tool

20:02 <Ansuel> create a script for testing and compare the results

20:02 <Ansuel> of your shell script with the tool

20:03 <philipp64> well, the script that it replaces (in AWK) was the equivalent tool...

20:03 <philipp64> I suppose we could also write some perl tests with Net::IP or Net::CIDR::Lite

20:03 <Ansuel> i would love to test them also with something external

20:05 <Ansuel> for testing I would just check the feature we are implementing, abuse for loop and run it on everything by comparing the result of one script and the other

20:07 <philipp64> Uh... that's a lot of permutations

20:09 <philipp64> I also fixed a couple of misdesign features in the original script... like you can take any number of decimal numbers in a dotted quad... and the `start` parameter to ipcalc.sh isn't an integer offset but another [partial] dotted quad that gets added to `ipaddr`... sigh.

20:09 <philipp64> i.e. 4.0 and 1000 are the same...

20:10 <philipp64> that's anything but intuitive.

20:10 <Ansuel> yes that is why testing the new script with the old one might problematic

20:10 <Ansuel> (btw i'm checking the web and love how there are various version of ipcalc tool in every kind of language... but not a single good tool written in C)

20:11 <philipp64> well, if there was anyone who relied on the old brokenness we'd want to shake that out.

20:12 <philipp64> Ansuel: there's the one from Redhat: https://gitlab.com/ipcalc/ipcalc

20:13 <philipp64> the output is a bit harder to parse though, so whatever optimization we get from compiled code goes away with having to run awk or sed over it to mangle it...

20:13 <Ansuel> yes but i wanted something more simple

20:13 <Ansuel> also it's too big

20:13 <philipp64> no, I take that back, it does have a `env` output format...

20:14 <Ansuel> so the use would be call the command

20:14 <Ansuel> and get the output from ENV

20:14 <philipp64> yeah, they've integrated MaxMind geoip into it... that's new.

20:14 <philipp64> yeah, it's mostly mean to be used from init.d wrapper scripts.

20:15 <philipp64> Got the new version running on my sandbox router (the internet-purgatory I put my teenage kids into).

20:16 <philipp64> Who owns base-files these days? jow? nbd?

20:17 <philipp64> Still holding my breath on PR #13530...

20:17 <mrkiko> philipp64: what does the sandbox router do ? Log stuff?

20:18 <philipp64> The kids have their own VLAN, Wifi SID, traffic shaping, public IP, and I point their nameserver at the Cisco family-safe stuff...

20:18 <philipp64> It's a router I can test stuff on without taking the whole house down. Both my wife and I work online.

20:18 <mrkiko> philipp64: thanks

20:19 <philipp64> It's implemented as an x86_64 VM on KVM...

20:19 <philipp64> which is why you'll never see me making a fuss about fitting stuff into a ridiculously small amount of DRAM...

20:20 <philipp64> At some point we need to gather the last WRT54G's and have a bonfire to cleanse our souls...

20:21 <Ansuel> :( the good old days

20:21 <Ansuel> anyway that ipcalc tool can be a good way to test your shell script

20:21 <Ansuel> still very tempted to create a c project and see how big it would be

20:22 <Ansuel> (having a c project = we can introduce test and fuzzing)

20:22 <mrkiko> well, I don't think it's such a simpler matter - oldhw phaseout and so on ... especially in those time when we start to get environmentally conscious. But the hw industry works that way

20:33 <philipp64> mrkiko: well, it could be a figurative bonfire. I've already inhaled enough mercury and lead for one lifetime...

20:34 <mrkiko> philipp64: don't worry, I think I understand your point of view and I kind agree. But then I sometimes realize how much some low-end hw is diffused and so ... I think it's a pity to let it go

20:35 <philipp64> the flip side is it's a pity to slow down or stop progress for that remaining 0.001% of the installed base...

21:19 <jeff___m> robimarko: I see the example sent, but couldn't find the ath11k-calibration-variant field in the board-2.bin file and dont understand the lookup that takes place using cal variant given that field, hmm

21:22 <jeff___m> I'm trying to understand the lookup to explore the dataset for potential variants that may be correct

21:27 <mrkiko> philipp64: and what I disagree upon is exactly that percentage... :D

23:02 <jeff___m> I found https://github.com/openwrt/firmware_qca-wireless/tree/main, which seems to be where the matching BDF files are, but I still don't understand the connection between ath11k's core.c where calibration variant is read, to what file it's actually searching for the BDF variants, and where those variants are actually stored

23:34 <jeff___m> I'm waiting on Compex to hopefully give me a BDF file, but seriously - how do any of these vendors expect people to use their hardware with no driver compatibility, it's like they don't even test them. I don't understand. No flashed board IDs is clearly a widespread problem with ath11k devices