**** BEGIN LOGGING AT Wed Jan 06 02:59:58 2021 Jan 06 03:14:45 for 11ad we need to add adhoc mode. the driver already has parts of it. Jan 06 03:22:55 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 98.1% packages reproducible in our current test framework.) Jan 06 08:22:40 aparcar[m]: thanks for the details. how to let the imagebuilder generate a new keypair? Jan 06 08:46:47 build #34 of realtek/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/realtek%2Fgeneric/builds/34 Jan 06 08:50:25 yay working realtek build <3 Jan 06 09:06:50 xback: that should happen automatically Jan 06 09:21:57 aparcar[m]: there seems to be an error there :-) Jan 06 09:22:26 it's pretty easy to simulate, create an Imagebuilder, unpack it, try to run command make package_index Jan 06 09:22:50 if you remove the "> /dev/null" you'll see the error Jan 06 09:23:52 hmm... I know difference betweem ath10k and -ct firmware, but what is 3rd variant -ct-full-htt? Jan 06 09:24:23 xback: I'll check it out thanks! Jan 06 09:28:36 I'm again kinda at loss that is which one the better variant =) Jan 06 09:29:04 olmari: htt is one you only need in very specific cases afaik Jan 06 09:29:53 olmari: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d15b09aab8a2aedeac2a6fb1e872ae975c9baa42 Jan 06 09:30:55 Borromini, xback: thank you, I was yet to found it myself from mail :) Jan 06 09:31:09 olmari: What's your ath10k hardware? Jan 06 09:31:27 c7 v2 in this case Jan 06 09:32:22 That's QCA9880, right? Jan 06 09:32:26 yep Jan 06 09:32:47 greearb_: About a year ago, I worked closely with Lorenzo to get Dynack into shape on ath9k. We were thinking to do the same effort for ath10k Jan 06 09:32:47 You want a htt variant. Jan 06 09:33:27 Actually, I asked greearb_ for a -ct-htt diet variant, months ago, but he probably forgot about it… :) Jan 06 09:33:36 rsalvaterra: that what I extrapolated from the mailinglist xback linked, too :) Jan 06 09:33:45 greearb_: for Dynack to function, it is required to have proper TSF available and readable in the ath10k driver. Is it feasible? Jan 06 09:34:22 greearb_: dynack is currently ath9k bound, but it could be moved to mac80211 generic so ath9k and ath10k can share the code Jan 06 09:35:38 2018 (the mail date)... Have I really been not thinking, or looking, anything ath10k FW related.. damn =) Jan 06 09:36:19 greearb_: I would focus on AP/STA for now. but it can also easily be extended for IBSS (just using other types of MGMT frames) Jan 06 09:37:32 xback: It would be nice to have dynack in all drivers, if possible… :) Jan 06 09:40:07 as an power user perspective I'd love dynack too everywhere possible, but at least everywhere possible... Sadly I ca'nt offer much/any help developing such, so babble babble :D Jan 06 09:41:17 keep in mind it only brings advantages when distance is >5km :-) Jan 06 09:41:43 The age old issue... an full day has 24h and after dayjob and other nonprofits and hobbies and bla there is no time to dive into openwrt in any meaningfull manner Jan 06 09:42:01 xback: yep, something like that I did remember Jan 06 09:42:07 xback: Good for long range ubnt stuff. :) Jan 06 09:45:13 So, I guess main thing to say at this moment is thank you all for making and keeping openwrt happend :) Jan 06 09:46:15 Visit Finland after human malware is over and get your free beer =) (but please don't come by hundreds at same time, goldmine isn't bottomless sadly 😀 ) Jan 06 09:46:43 olmari: Thanks, but not any time soon… :( Jan 06 09:46:53 * rsalvaterra is wating for his COVID-19 test result… Jan 06 09:46:57 *waiting Jan 06 09:47:48 Oooh exciting! Jan 06 09:48:18 Huh…? Jan 06 09:52:21 ldir is a positive thinker Jan 06 09:53:44 Given how my sense of smell is completely bonkers, I'd say "positive" is the most likely result… Jan 06 09:54:18 rsalvaterra: it's not fun. went through it myself Jan 06 09:54:43 Borromini: Ouch… :( Jan 06 09:54:44 Is ldir more exited about proper more conformant "springy" swab stick or prefer the hard one sticked through nostril as exiting? ;P Jan 06 09:55:01 wife somehow still thinks i didn't have it (two negative tests, but even the pcr test still has a 33% 'false negative' rate) Jan 06 09:55:13 Unless comment was for something historical ;) Jan 06 09:55:34 IP packets are being routed more slowly after brexit ;) Jan 06 09:55:37 * Borromini hides Jan 06 09:55:42 rofl Borromini Jan 06 09:55:57 * nitroshift hides behind Borromini Jan 06 09:56:44 Borromini: probably an extra firewall got installed accross the channel .. Jan 06 09:56:49 Borromini: To me, right now, everything smells like vomit. I kid you not. Jan 06 09:57:14 xback: hehe Jan 06 09:57:44 rsalvaterra: that sucks. i didn't smell anything. and of course taste suffers too. hope you aren't seeing any other side effects. Jan 06 09:58:32 Just joint/muscular pain and low fever, easy to manage. No cough or trouble breathing, thank God. Jan 06 09:59:32 fingers crossed! Jan 06 10:00:19 A friend of mine feels everything smelling of seafood. Lucky girl. Guess I got the short end of the stick. :P Jan 06 10:04:08 :P Jan 06 10:06:36 rsalvaterra: hey.. cheap eating... Straight from trash and tastes as good as prime steak ;) Jan 06 10:07:15 olmari: Oh, my…! Jan 06 10:08:15 * olmari hides behind nitroshift Jan 06 10:10:44 You guys are sick. Please, go on. :P Jan 06 10:20:14 and here i thought finland was more or less okay in the corona crisis :P Jan 06 10:20:16 How else we would survive around here? ;) Jan 06 10:20:39 xD Jan 06 10:32:06 blogic: could the rtl838x-poe package be brought into the tree? or is it too early for that? Jan 06 10:32:31 Borromini: erm, we can do that i guess Jan 06 10:33:46 :) Jan 06 10:36:28 Awesome, the rtl838x is pretty exciting, going to grab a GS108T and GS110TPP for some testing Jan 06 10:37:19 nlowe: keep an eye on the revisions though Jan 06 10:37:28 quick question: is mt76 still a good buy? Jan 06 10:37:36 gs180t is only v3 supported afaict Jan 06 10:37:49 nitroshift: i'd say yes, personally. Jan 06 10:37:53 * ldir collects a whole load of packets piled up at the border - again - silly idea this brexit Jan 06 10:37:55 thanks Borromini Jan 06 10:38:18 was looking at a d-link dir-2660 Jan 06 10:38:21 nitroshift: although there's no real triple radio devices on the market apparently Jan 06 10:38:30 i have the dir-878 a1 :) Jan 06 10:38:39 Borromini, i don't need triple radios Jan 06 10:39:11 rsalvaterra: talking of things smelling of vomit - parmesan cheese in the 80's from those round dispensers brought out on special occasions. Jan 06 10:39:11 hell, even the 2 radios on wrt3200acm's are overkill for me Jan 06 10:39:49 :) Jan 06 10:40:07 i have a poor man's mesh situation atm, but just using a wds with mt76 Jan 06 10:40:38 rsalvaterra: whatever you have, covid or not, hope it's not horrible...or more importantly...deadly Jan 06 10:42:19 mrs ldir has had to take a test...swab up the nose...before she went for a very minor operation. All came back clear. She said the test was VERY unpleasant and that I'd probably go mental. Jan 06 10:42:41 it feels like someone's drilling into your brain. Jan 06 10:42:49 it goes up *that* far Jan 06 10:46:43 Ewwwwww - I hope I never have to take a test - and can fall on a set of needles containing vaccine soon. Jan 06 10:48:00 UK seems to be doing that quite well, vaccinating Jan 06 10:48:03 * Borromini looks at belgium Jan 06 10:48:22 at least our numbers are down, but that won't help with 700 people getting a vaccine every week >_> Jan 06 10:49:50 Unfortunately I'm 3 months outside of falling into any 'special case' vaccine category... not quite old enough Jan 06 10:52:05 Borromini: and don't worry, you may think the 'UK' is doing well but rest assured we'll cock it up big time in some entirely predictable & avoidable way but our Boris will blunder into the disaster anyway. Jan 06 10:52:28 * ldir goes to pay tax bill Jan 06 10:52:37 :P Jan 06 10:52:48 death and taxes, they say Jan 06 10:58:41 ldir: Well, parmesan cheese, *is* made with vomit. :P Jan 06 11:00:03 blogic: i sent in a patch for realtek target, but i'm reworking it. should i be moving the memory node into the top dts for each device? or e.g. keep it in the common dtsi for all the d-links e.g.? Jan 06 11:00:10 And yeah, the swab is horrible, but there are worse things… ;) Jan 06 11:01:44 blogic: my zyxel gs1900-8hp has 128 MiB ram e.g. but smallnetbuilder reviewed that hardware in 2013 and they said they had a 64 MiB one. so i'm not sure if for the gs1900 series it should be in the common gs1900 dtsi i'm creating Jan 06 11:02:09 Borromini: mine is 128mb Jan 06 11:02:13 they are all 128 Jan 06 11:02:18 not seen any 64mb ones Jan 06 11:03:25 blogic: you got a gs1900-8hp as well? Jan 06 11:03:40 it's a bit weird for smallnetbuilder to misread chips, i'd think. Jan 06 11:04:10 svanheule[m]: told me the memory node has been moved out of the rtl838x.dtsi either way though, in the upstreaming effort Jan 06 11:04:21 correct Jan 06 11:04:37 so shall i put it in the shared dtsi for each lineup? e.g. dgs-1210 and gs1900? Jan 06 11:05:05 probably best to do so Jan 06 11:05:53 alright, thanks Jan 06 11:06:13 would you mind reviewing the realtek/gs1900 v2 patches i'm sending in? Can I cc you? Jan 06 11:07:21 when did you send it ? Jan 06 11:07:32 ah, when they arrive Jan 06 11:07:40 just ping me once they are posted Jan 06 11:07:42 i sent a v1 but already marked it as superseded Jan 06 11:07:45 alright, will do Jan 06 13:04:33 blogic: they patches are on patchwork (three total; ipv6 issues with my mail server mean they're not neatly grouped together, sorry) Jan 06 13:04:38 s/they/the/ Jan 06 13:12:46 * russell-- wonders if there is anything controversial about https://patchwork.ozlabs.org/project/openwrt/patch/87r1nh1cbt.fsf@husum.ptp/ that might be an obstacle to merging Jan 06 13:21:18 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.1% packages reproducible in our current test framework.) Jan 06 13:38:49 nbd: can you please check https://github.com/openwrt/mt76/pull/490 and give me ack? I'll then merge/update the package, thanks Jan 06 13:42:25 ynezz: the suggested change on the mailing list looks a little different: https://www.spinics.net/lists/arm-kernel/msg865397.html Jan 06 13:43:33 Hauke: ah, wasn't aware about that Jan 06 13:43:50 ldir: ping Jan 06 13:44:00 for mt76 i prefer changes to be sent to linux-wireless directly Jan 06 13:45:05 I would do that, but the upstream code is ok Jan 06 13:45:27 I mean, I've checked code in 5.4 branch Jan 06 13:45:42 Did archer c7 (or chipset, or owrt in this env) support VHT160? Jan 06 13:46:14 I do remember it used not to, but that's years ago.. I mean I realise it can still be HW issue not to, but wanna confirm way or another :) Jan 06 13:46:34 nbd: IIUC the code in that mt76 repo is used in OpenWrt and is different then in upstream Jan 06 13:46:36 olmari: No. Jan 06 13:46:54 ynezz: there are some pending changes in mt76.git that aren't upstream yet Jan 06 13:47:03 rsalvaterra: thank you Jan 06 13:47:13 ynezz: but aside from those changes, i keep mt76.git mostly in sync with my upstream tree Jan 06 13:47:52 and when i pick up changes by other people, i pick them from the list into my upstream tree first and merge them from there to mt76.git Jan 06 13:47:55 I'm doing one device fro m0 and updating any base/basic configs and knowlege for current stuff, both generally and obviously an bit device wise :) Jan 06 13:48:04 xback: pong Jan 06 13:49:49 ldir: I noticed you did some work on hostapd-basic etc Jan 06 13:50:09 I was playing around with 802.11r etc and tried playing with the bgscan modules Jan 06 13:50:25 could it be that a build flag is missing in the 4 templates? Jan 06 13:50:30 nbd: ok, thanks for the info Jan 06 13:50:49 I think #CONFIG_BGSCAN=y should be added next to the module selection Jan 06 13:51:26 xback: I have absolutely no idea - that was a lifetime ago. Jan 06 13:51:52 should 11r work with current master or not? (assuming wpad-full-openssl and rest of drivers etc proper?) I'm exactly doing that too as we speak, or compiling away and so on Jan 06 13:52:04 802.11r works fine Jan 06 13:52:13 cool :) Jan 06 13:52:29 but to perform a lot better the bgscan modules are required on clients Jan 06 13:52:32 sorry for the kinda stupid Q's, but curiours carl is curipous :P Jan 06 13:53:02 xback: ah, that the talk is referring to, thank you for explaining Jan 06 13:53:44 I vaguely remember there was a desire to have 802.11'foo' support but not to have a size penalty for small devices. Jan 06 13:56:12 I currently seem to have problems with _some_ clients (end devices) problems connecting to required_mode ac while HW is otherwise perfectly capable of doing ac, I wonder how to try troubleshooting that later today.. I mean it could very well be just FU with such device, but could as well try looking Jan 06 13:58:44 ldir: I'd be happy if I could get airtime policy enforcing to work… Jan 06 13:59:18 … I mean, everything's in place, but I always see all stations with an airtime weight of 256… Jan 06 13:59:24 without that requrement the oddball device connects fine with ac speeds too, so in those senses all ac stuff works... but such stuff hinders me from doeing multiple APs with same SSID, accepting only devices withing tech capable Jan 06 14:02:54 the reality is that I got so annoyed with terrible 5GHz wifi performance on my archer c7v2's that I mothballed them and went commercial - I only play with openwrt on my non-wireless APU2 Jan 06 14:05:50 ldir: Terrible performance, really? What driver/firmware were you using? O_o Jan 06 14:06:02 well, 11w has gave terrible results for me, relating to c7 or not in itself.. and then things like this one, which might or might not relate to owrt at all.. when it's working, it has worked very well, but it does need me to not do "one SSID to rule em all" etc, but that's life Jan 06 14:06:35 ldir: ath10k-based? Jan 06 14:06:51 olmari: 802.11w (and WPA3 Personal) work just fine with ath10k-ct and the -ct-htt firmware. Jan 06 14:07:17 hm, I just gave c7v4 with 19.07.5 to my 13y nephew and he's so happy with that Jan 06 14:07:41 ynezz: when can we expect his first patches? :) Jan 06 14:08:03 rsalvaterra: I know they should, and also that they might or might not relate to owrt side also, I will be playing around with that too today.. there is not oftentimes I a able to do so Jan 06 14:08:13 jow: after he finishes that minecraft :p Jan 06 14:08:25 jow: Don't promote child labour… :P Jan 06 14:08:39 it's not labor, it's "fun" Jan 06 14:08:44 *labour Jan 06 14:09:11 ynezz: does he/she play with openwrt as well? Jan 06 14:10:31 ..I also feel the irritation as I have also realised that oftentimes commercial stuff just... well.. in some senses works better... and that occasionally those devices even are based on openwrt, but has some propietary BCM stuff going on on wifi, etc.... Jan 06 14:10:37 (say, Inteno) Jan 06 14:11:29 then there are cisco and whatnot real expensive stuff, again, wifi stuff works awesomely, while otherwise we could have any opinion from the rest of stuff Jan 06 14:11:35 Speaking of patches, is the x86 dead code/data elimination patch good to go as is, or does it need more massaging? Jan 06 14:11:42 (like on inteno I Jan 06 14:12:22 ..I'm most irritated that they blatantly use openwrt but blatantly ignores rest of OSS stuff (be it BRCM deal in itself) Jan 06 14:12:23 mrkiko: well, he was able to flash and configure it by himself as it's youtube generation and there was some videos on that topic Jan 06 14:13:11 was quite excited about the more verbose/advanced user interface, so lets see where it goes :p Jan 06 14:14:07 ldir: I noticed one thing that can improve the networking performance of the APU is increasing the PCIe payload size. Pass pci=pcie_bus_perf in the kernel command line. :) Jan 06 14:17:44 ynezz: oh, awesome!!!! Jan 06 14:18:05 olmari: yes, I had some experiences in this sense with Netgear BCM device - the one I sent about in the mailing list Jan 06 14:18:40 ynezz: He needs to learn the ways of the terminal… ]:) Jan 06 14:18:57 olmari: but then, OpenWRt with it's system architecture is invaluable to me, being blind I can admin my devices without faiting the web interface. And can't stand to see proprietary module with wifi stack kinda integrated in the device itself. Jan 06 14:19:20 rsalvaterra: he will he will :D Jan 06 14:20:48 Looking at the Netgear D6400, my impressio nwas they did some interesting stuff in hw and not in sw, with bcm special hw. I can still be wrong, since I am judging only by dmesg. that said, makes sense due to the slow BMIPS processor Jan 06 14:21:12 now faiting with CFE as usual :D Jan 06 14:22:48 mrkiko: I love openwrt too... which makes me especially sad or "mad" that folks exploit it this way they do... I know "smooth good wifi" is very possible with owrt... "just don't tell it to OSS guys" Jan 06 14:23:35 I mean I am not saying 1th9k or now ath10k is automatically crap etc, but all the best stuff is kept highly NDA Jan 06 14:24:14 olmari: ehehe yes, fw Jan 06 14:24:46 BTW, was curious when I see the AD7200 with the wilocity driver not mach80211-based. Jan 06 14:25:16 there's a very good reason why a common wi-fi stack exist, still remember the time when this wasn't the case. Jan 06 14:25:50 I can accpet that, say, Cisco makes good working stuff, assuming no foul play happends there etc (I don't know that), but indeed I so hate BCM policies, and who knowswho else toys around such way Jan 06 14:27:03 fortunately on most places I am affecting things, I can have openwrt router and then AP's separately... while most places still has owrt AP's too, I feel occasionally that maybe commercial would work better there, and that is by no means owrt fault but exactly what is sid Jan 06 14:27:07 said* Jan 06 14:28:36 well, given the fact that if you build a device around BSP, you are yourself limited to what you can do in a sense, because you don't have so much freedom to play with stuff like the kernel (at least for what I guess / think) due to the proprietary stuff and non-proprietary stuff that still isn't maintained / updated, that I as a user can't demand from the vendro to have the same level of support, Jan 06 14:28:42 cleanness and overall care as openwrt guys have. Jan 06 14:29:05 ...now jsut tested ac with no "required_mode ac", works now on the intel wifi computer too... and 11w requred, wpa3/2 sae/psk, all devices connect and no speed loss experienced.. so.. those part works Jan 06 14:30:14 mrkiko: I love openwrt.. I hate OEM's exploiting owrt... I love many OEM's wifi performance/working wellness... Jan 06 14:30:42 olmari: yes, I understand Jan 06 14:31:07 I know OEM can't care and do that kind of stuff geenrally owrt can, but chip MFG's should not be such assholes about OSS, which t all stems from Jan 06 14:32:10 I'm not saying some OEM even should care in that sense, but chip MFG and NDA's etc.. those should care more... let openwrt be good on there too instead "we no tell you" Jan 06 14:32:29 for given OEM it would not change an thing... they cna keep making good device as-is Jan 06 14:33:20 olmari: agree; but probably if you are a manifacturer you care about selling parts, not about advantages for your users, especially when yhey're long term advantages. With commerical devices then I unintentionally managed in some circumstances to break their operation, e.g.: intensive use of NAT or Wi-Fi (both actually). Jan 06 14:34:12 I don't see how could any chip MFG lose in being better for OSS-community Jan 06 14:34:58 the Inteno and rest of device-OEM's can keep doing as they are now, they are not affected directly Jan 06 14:35:27 Because when you pay the device you pay the software as well. The vendor would like to think that then the device is EOL, you simply buy another. Because from now on, any CVE is - to say, persistent. With OpenWRt it's not like that. And even old hardware can work really well Jan 06 14:36:30 yeah, I agree with you, they could keep doing what they do now but at least not stop openwrt from improving on their device. But probably here plays the fact that Inteno has no right to tell you anything about BCM stuff Jan 06 14:37:16 I agree with you in any case - would be very very nice to have openwrt run on many devices. Jan 06 14:38:59 if user does not care about openwrt, which we have to assume 99.9% of wold does not, they'll just keep buying what they do Jan 06 14:39:33 in such sense device mfg situation would not change... nor chip OEM either... Jan 06 14:40:03 about devices... I had a very little experience, and can assure you it's not easy out there. Because manifactuer cares about you only with volumes that are high enough. Jan 06 14:40:18 those who does care about owrt would keep byuing those device, benefittinh both device and chip MFG at least until every one does same Jan 06 14:41:29 I know this all stems to chip MFG stuff, average device MFG in that sense wouldn't even care, nor it is kinda relevant even now that I think of it.. but yeah... I'm claming down now... xD Jan 06 14:44:14 rsalvaterra: I can't remember, it was probably 1.5 years ago. It would have been the ct version. But basically I found packet loss quite high and it affected facetime calls, to the extent that switching to 2.4 Ghz improved the calls dramatically. Popular opinion here was that is was my fault for using Apple kit. Jan 06 14:46:28 nbd: I have this pull request for the mt76 tools: https://github.com/openwrt/mt76/pull/485 Jan 06 14:46:35 should this also go to the mailing list? Jan 06 14:49:19 also I can confirm that mediatek wifi does not like 11w, still/yet/ever... tho mixed wpa3/2 and 11w optional is fine in this situation Jan 06 14:49:38 mediatek client, Cosmo communicator phone Jan 06 14:49:56 Just to tell it aloud, nothing news there in itself Jan 06 14:50:15 I mean it is even mentioned in owrt wiki/documents/whatever the wireless settings page is Jan 06 14:51:18 whoever pinged me, it ran out of my buffer... Jan 06 14:53:07 greearb_: 😀 (not me who pinged) I think first they were wishing co-operation to maybe try starting to enable dynack for ath10k(-ct I presume), and then they even wished possibility of doing it generally Jan 06 14:53:33 some functions needs to be moved from ath9k to, say, mac80211, or something Jan 06 14:53:53 I think that covers majority of "concerns" that folks were pinging you with Jan 06 14:54:05 in dense form Jan 06 14:55:01 this channel is logged, https://freenode.irclog.whitequark.org/openwrt-devel/2021-01-06 looks like you can see who pinged if you just search your name Jan 06 14:55:09 the dynack code has been done but not by me. I'm not sure if a paying customer wants it to be kept private or not...I'll ask. Jan 06 14:57:11 greearb_: well I don't know did the wishful part knew such exists in ath10k, but was more of thinking "we have it in ath9k, let's go from there", but already existing one would obviously be more easy in some regards (at least ath10k specifically) Jan 06 14:57:52 greearb_: i think it was xback Jan 06 14:58:14 noltari: are you around?? Jan 06 14:58:41 I know who did it, not sure their irc handle though Jan 06 15:00:21 greearb_: using your -ct firmware on FRITZ!BOX 7530, 2.4 ghz only, no problems so far Jan 06 15:01:01 good deal. Based on github ath10k-ct bugtracker, it is pretty stable, but there are probably some power-save bugs somewhere. Jan 06 15:01:23 greearb_, still no diet -ct-htt wave 1 firmware? :) Jan 06 15:01:28 the kind of bugs that happen after several days and only in some situations Jan 06 15:01:53 I can build you a diet one if you want...will add it to my list of things to do Jan 06 15:02:57 Yes, please! No rush, but it would really nice-to-have. :) Jan 06 15:03:57 greearb_: I'll let you know if something happens Jan 06 15:04:01 greearb_: thanks! Jan 06 15:04:17 greearb_: what do you mean? Jan 06 15:04:46 Borromini, about what comment? Jan 06 15:04:58 'i know who did it, not sure their irc handle though' Jan 06 15:05:28 I know who to ask about dynack in ath10k-ct, via email Jan 06 15:05:32 real person->irc nick mapping I guess Jan 06 15:07:59 greearb_: koen vandeputte Jan 06 15:08:59 hi gch9812133289 ! Still grateful for your help with the R6220 that time of the 5.4 transition Jan 06 15:11:22 actually, from what I recall, setting ack distance should work in -ct wave-1 firmware/driver for years now. But not wave-2 at the moment. Jan 06 15:20:15 * mrkiko googles about CFE boot loader, but finds links about the Common Final Exam Jan 06 15:20:19 LOL Jan 06 15:30:28 actually... wpa3/2 sae mixed makes intel ac wifi not see/report ssid at all... wpa2 alone does... meh Jan 06 15:30:35 there is always something :P Jan 06 15:58:54 olmari: windows client? Jan 06 15:59:13 Borromini: debian buster, kernel 5.9 Jan 06 16:00:22 oh. i just use wpa3. bullseye and 5.9 Jan 06 16:01:01 not sure how much userland support you need besides a recent wpa-supplicant Jan 06 16:10:42 Borromini: well, iwlist scan does not even show the network, while other devices are connected happily (thus network works) Jan 06 16:15:14 olmari: iw dev wlan0 scan is better but it's unlikely to affect the outcome of course Jan 06 16:16:31 For LuCI, how do I make a listvalue item dependent on another listvalue item having been selected? Jan 06 16:17:57 Trying to work out how to put a dependency in the o.value(...) Jan 06 16:50:25 o.depends right? Jan 06 16:51:23 o.depends("option", "req_value") is what I've got in some stuff Jan 06 16:51:34 oh, for individual list values? not sure... Jan 06 16:55:48 should not work different than normal depends Jan 06 17:10:40 so o = s.option(ListValue...); o.value("blah", "wop"); special = o.value("extra", "extra2"); special.depends("otheroption", "othervalue") ? Jan 06 17:13:24 greearb_: thanks for checking regarding dynack. feel free to let me know if the customer decides to share it Jan 06 17:14:08 greearb_: _lore_is also interested in getting it mainline (please correct me if i'm wrong _lore_) Jan 06 17:15:17 "Enable packet steering across all CPUs. May help or hinder network speed." Any insights on this in general way and then archer c7 specifics perhaps =) Jan 06 17:15:37 not that on purely AP it makes much difference, or would it? Jan 06 17:16:14 I know I can just test stuff, that is not the point, but to know if there has been any insights when such thing is implemented :) Jan 06 17:18:59 greearb_: I can confirm that setting ack distance is working nicely for a long time now in wave1, but logically, doing it dynamically using frame timing give the perfect tradeoff between speed/distance ;-) Jan 06 17:21:42 olmari: never. archer c7 is QCA9880v1 and v2 -- v1 being bad silicon. The only VHT160 support was in 99XX series Jan 06 17:23:08 hurricos: That would indeed explain it :) Jan 06 17:24:04 xback, I think that cannot work for a mobile environment? Jan 06 17:27:22 karlp: That gives me "TypeError Jan 06 17:27:22 Cannot read property 'depends' of undefined" Jan 06 17:29:16 I don't seem able to assign o.value(...) to a variable, then call depends(...) on it and have it work Jan 06 17:31:12 yeah, that was what I was checking with jow, I wasn't sure abotu list items either. Jan 06 17:31:29 entire lists ,sure, but not indiv items Jan 06 17:33:39 olmari: For every one of those good commercial experiences there's a meraki eol experience too Jan 06 17:36:40 for me, the value of openwrt is in maintaining devices way past 'commercial eol'. Everything from sturdy-built "made to last forever" hardware whose vendors drop support after 7y (Meraki outdoor devices) to the cheapest of devices ... Jan 06 17:37:07 karlp: I was looking how we could have the cipher list items (TKIP, TKIP/AES mixed) be dependent on WPA3 not having been chosen, sadly not possible it seems Jan 06 17:37:12 hurricos: mm... well... these always exist... I have old cisco draft-N somewhere, while device itself is EOL long ago, UI is horriblest shit ever... cisco CLI part and especially the wifi it provides is miles ahead in general workings Jan 06 17:37:19 And what firmware exists that you can rebuild it and turn a mesh AP into a 4-drive NAS with iSCSI capability? Jan 06 17:37:40 cisco comes close in terms of long-lasting. no doubt about it Jan 06 17:38:06 well for me talk is more or less specifically AP use only in this context :) Jan 06 17:38:09 nlowe: just put (requries WPA3) in the description an dmove on with your day :) Jan 06 17:38:13 but the very-long-run of functional technology will be people or teams who both know how to manage and to develop their own hardware Jan 06 17:38:57 will last long past our tech boom, long past running out of natural resources to continue building these devices for nothing Jan 06 17:39:36 hurricos: yes.... all that will not help me tackling incoming calls about "me wifi broken" or something alike ;P Jan 06 17:41:30 lol this is true, no doubt. But without OpenWrt those questions would be answered by, "just buy another one." It's only because of OpenWrt that more people can learn how rather than simply offloading that Jan 06 17:48:25 olmari: speaking of, testing procd-ujail and procd-seccomp now. Jan 06 17:49:38 hurricos: nice! While dangole_ will be to more interested in results.. or I mean I am too, but he is the dev, I was tester.. or would have been should effing device be enywhere at hands, literally (: Jan 06 18:05:06 dangole: https://paste.c-net.org/VisibleBoggling Jan 06 18:05:32 tested procd-ujail + procd-seccomp on mpc85xx (aerohive 330) Jan 06 18:05:44 that's a screenlog.0 of the test. Jan 06 18:05:48 nice! Jan 06 18:06:00 can you install umdns, because that uses seccomp filter setup in procd/ujail? Jan 06 18:08:21 have any quick rec to test ntpd? I don't want to install sntp on my debian host Jan 06 18:08:31 an openwrt ntp client maybe? Jan 06 18:09:30 * mrkiko stuck at "ERROR: A JFFS2 directory entry for vmlinux.lz was not found." Jan 06 18:10:05 hurricos: `cat /proc/$pid/status` with $pid being the PID of /usr/sbin/ntpd would be interesting Jan 06 18:10:14 oh Jan 06 18:10:17 hurricos: that should show correct capabilities applied Jan 06 18:11:48 I don't see any CAP_* Jan 06 18:12:15 hurricos: should be lines like "CapEff: 0000000002000400" Jan 06 18:12:26 (all of them should have that value) Jan 06 18:12:29 Oh! Jan 06 18:12:33 yes. Jan 06 18:12:45 and NoNewPrivs: 1 Jan 06 18:13:08 Yep. Pastebinning it Jan 06 18:13:29 https://paste.c-net.org/ArgonAerobics Jan 06 18:13:44 very good. testing seccomp as well would be great, you either need umdns or transmission-daemon to test that. i expect that the existing syscall whitelists will not cover everything and/or some calls are named differently on PPC Jan 06 18:15:39 dangole: umdns seems easier to test, but transmission-daemon will do more syscalls due to file io I'd expect Jan 06 18:15:45 lemme get a sata drive Jan 06 18:16:32 Can someone help me out find the direct link to download Netgear D6400 GPL source code? I am here - https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL Jan 06 18:20:54 ok, found - http://www.downloads.netgear.com/files/GPL/D6400-GPL_Src_ful_V1.0.0.22_1.1.22.zip Jan 06 18:24:04 dangole: no dice: https://paste.c-net.org/KaiserFaith Jan 06 18:24:49 hurricos: so now you need to /etc/init.d/transmission stop ; /etc/init.d/transmission trace Jan 06 18:25:23 hurricos: that will give you a file in /tmp containing the syscalls emitted up till then once you do /etc/init.d/transmission stop Jan 06 18:25:47 hurricos: then you can diff that with what is in /etc/seccomp/transmission-daemon.json and add the missing ones Jan 06 18:25:49 dangole: https://paste.c-net.org/LewisSpades Jan 06 18:25:56 oh Jan 06 18:26:55 what's the name of the file I expect? Jan 06 18:28:29 dangole: ping Jan 06 19:20:00 mangix: if you want to see more arc700 issues please check here https://buildmaster.aparcar.org/#/builders/30/builds/2/steps/43/logs/stdio Jan 06 19:48:52 jow: can you take a look at iwinfo.git and rpcd.git, i believe that all your comments have been addressed, apart from SOVERSION (and there i'm not sure what's the best way to introduce that) Jan 06 21:42:35 aparcar[m]: dedekeh is handling that. no idea qhat happenwd. Jan 06 21:44:08 aparcar[m]: https://github.com/openwrt/packages/pull/14426 wants merge access Jan 06 21:47:57 aparcar[m]: https://github.com/openwrt/packages/pull/14205#issuecomment-755629813 is complaining about https://patchwork.ozlabs.org/project/openwrt/patch/20210102235625.264305-1-rosenp@gmail.com/ not being merged. Jan 06 21:49:00 it's 4 days old what do people expect Jan 06 21:49:12 packages feed speed Jan 06 21:50:20 let's give my buildbot a bit of time to compile this Jan 06 21:52:41 mangix: how do I test your patch? Jan 06 21:52:58 compile collectd Jan 06 21:53:08 there's another package that fails without it Jan 06 21:53:10 hold on Jan 06 21:53:15 for what arch? Jan 06 21:53:23 I tried to compile collectd and it worked just fine Jan 06 21:53:27 any arch with glibc Jan 06 21:53:34 glibc is the key Jan 06 21:53:47 asterisk is the other one Jan 06 21:54:06 it was fixed in https://github.com/openwrt/telephony/pull/604 but I feel that this is the wrong place to fix Jan 06 21:55:02 that is, it's a workaround for lua being broken. Jan 06 21:57:12 So which arch can I use for testing? Jan 06 21:57:25 archhs Jan 06 22:03:39 dangole: my idea was to expose the SOVERSION attribute as cmake option, so that we can pass it via -DIWINFO_VERSION=$(ABI_VERSION) from the OpenWrt Makefile Jan 06 22:04:29 dangole: oh, just noticed that iwinfo.git is not using cmake Jan 06 22:07:59 jow: that's why i was asking... Jan 06 22:11:59 the arc700 buildbot is amusing to me. it uses uClibc-ng even though it's gone from the tree Jan 06 22:13:06 jow: all the cool kids use meson... Jan 06 22:27:54 dangole: git format-patch --stdout HEAD^ | curl -F "sprunge=<-" http://sprunge.us Jan 06 22:28:11 dangole: sorry, correction: http://sprunge.us/A2jeXD + http://sprunge.us/dBDEeX Jan 06 22:28:54 dangole: only lightly tested, would appreciate if you can give it a spin and push if it works Jan 06 22:33:31 and mid term we should think about turning libiwinfo into a thin convenience wrapper around nl80211 and make it use flexible data structures internally (blobmessages or heap allocated structs/array) Jan 06 22:35:00 jow: will give it a spin right away, thanks! Jan 06 22:35:25 these changes should make future abi-breaking updates less painful hopefully Jan 06 22:35:52 at least opkg will complain loudly or simply install a newer copy next to the existing one when libiwinfo is upgraded to an incompatible version Jan 06 22:36:43 (the second patch might need rebasing, my local tree is stale) Jan 06 22:39:48 we should adopt similar soversion changes to libubus, libuci etc. Jan 06 22:40:46 while we track the ABI version in the package metadata we're not actually shipping libraries with appropriate sonames there, preventing opkg from installing different versions at the same time Jan 06 22:41:02 which is a precondition for somewhat seamless upgrades to a newer version Jan 06 22:42:00 jow: jup, right now this obviously fails due to file collisions -- also preventing users from *accidentally* installing several versions of the same library and running out of space... Jan 06 22:42:52 jow: but yes, the opkg distribution should still be as useful as possible, people run that in containers, VMs and all sorts of rather rich hardware where a few megs of storage are not the problem Jan 06 22:43:24 jow: both patches apply cleanly, will test-build using git-src for iwinfo Jan 06 22:43:53 jow: is this anything to be worried about? Error relocating /usr/lib/lua/uci.so: lua_objlen: symbol not found Jan 06 22:44:21 that's from ldd on /usr/lib/lua/uci.so Jan 06 22:45:46 mangix: I guess lua/uci.so does not link liblua and relies on the host program loading it to provide the required symbols Jan 06 22:46:19 mangix: that's just the symbols inside the lua executable uci.so is using. at the time uci.so is loaded, those are already present, hence not a problem Jan 06 22:47:04 it sounds like uci.so should be fixed anyway Jan 06 22:47:06 dangole: out of space can be recovered from, a broken system due to a binary-incompatible libubus.so not so much Jan 06 22:47:18 jow: very true Jan 06 22:48:01 jow: and likely that people will just force-overwrite files which are seemingly owned by the library they are trying to install Jan 06 22:48:46 jow: for libiwinfo parallel installs btw. without force-overwriting files still wouldn't work because of hardware.txt... Jan 06 22:50:04 jow: thought about extending hardware.txt format to have to option to state FDT compatible string instead of idVendor, idProduct, ... only relevant for a number of WiSoCs though, so I decided it's not worth it Jan 06 22:54:02 huh, what is this HIDIOCGRDESC? Jan 06 22:54:40 jow: ok, test build with completely new checkout and your two patches on top Jan 06 23:03:54 jow: are you at some point free to work on the buildbot with me? Jan 06 23:05:55 what the... Jan 06 23:06:16 why does man 3 ioctl specity int for the second parameter but man 2 ioctl specifies unsigned long? Jan 06 23:07:13 mangix: what arch should I use to compile collectd? Jan 06 23:07:21 archhs Jan 06 23:10:08 mangix: ❯ ./scripts/dump-target-info.pl architectures | grep archhs Jan 06 23:10:11 unknown to me Jan 06 23:10:49 arc_archs archs38/generic Jan 06 23:11:58 mangix: will arc_archs stay in tree and only arc700 is dropped? Jan 06 23:12:13 up to dedekeh I guess Jan 06 23:12:26 Synopsis wants it to stay Jan 06 23:12:36 the glibc patch for it is small Jan 06 23:14:29 ok Jan 06 23:14:39 I'll have to compile it from ground up, that'll take a bit Jan 06 23:15:20 hmm? the SDK should be enough Jan 06 23:15:38 ack Jan 06 23:17:12 mangix: do you know what in openwrt.git depends on lua? Jan 06 23:17:24 everything Jan 06 23:17:40 convenient Jan 06 23:17:48 i mentioned uci earlier Jan 06 23:21:59 jow: and do you have a comment on http://patchwork.ozlabs.org/project/openwrt/patch/20201227213124.1638854-1-mail@aparcar.org/ ? Jan 06 23:25:47 aparcar[m]: hopefully next week, no Jan 06 23:26:23 i'm parsing this as , ? Jan 06 23:37:33 dangole: OK I have another lantiq to flash here. Can test latest master r.e. your fix to "firstboot"/jffs2reset. Presuming, I should, once going, set some config, then, reboot over serial, and read the messages to reset to defaults on the console and check that (a) funcitonal and (b) no weird errors/messages. Is there anything specific I should try or check/observe otherwise? Jan 06 23:39:06 enyc: I've already tested this excessively on oxnas (also UBI/NAND) and merged to master, so it should just work. Try reproducing what you did last time when it failed and hopefully that should now just work (ie. erasing unmounting ubifs overlay in failsafe) Jan 06 23:55:29 aparcar[m]: yes, no opinion on the feeds patch Jan 06 23:56:06 aparcar[m]: but makes sense on a first glance. s/float/flood/ though Jan 07 00:02:05 jow: thanks :) Jan 07 00:02:35 jow: looks perfect, now got version .so.2020... in filesystem, all users find it there and i pushed to iwinfo.git Jan 07 00:05:40 jow: the second patch will obviously have to go together with a bump to iwinfo git HEAD, i'm about to push that and the bump of (now fixed) rpcd to master Jan 07 00:23:30 Hauke: by chance, are you familiar with irq chip implementations? Jan 07 00:28:56 mangix: how can this sdk be sooo slow? Jan 07 00:29:01 is it arch specific? Jan 07 00:31:05 no Jan 07 00:31:10 it's glibc specific Jan 07 00:31:59 i don't get how it's so slow. just edit feeds/base/package/utils/lua/Makefile Jan 07 00:32:24 then make package/collectd/compile -j X Jan 07 00:35:22 the former fixes the latter Jan 07 00:57:51 dangole: have 2 such devices and getting a new package dependency error trying to install luci pkg which i would normally do ... Jan 07 00:58:32 " * pkg_hash_fetch_best_installation_candidate: Packages for luci-mod-status found, but incompatible with the architectures configured", same for luci-mod-iwinfo .... and "satisfy_dependencies_for: Cannot satisfy the following dependencies for luci:" " * libiwinfo20200105" Jan 07 00:58:49 presumably something not built/available/installable at this instant... Jan 07 01:02:40 enyc: you need to rebuild luci Jan 07 01:07:13 dangole: this is using openwrt master from site, not a custom build Jan 07 01:07:32 used to be able to instal lke that, but in whatevers' going no dev-wise, something has changed and can't install atm Jan 07 01:07:41 enyc: then you have to wait for the buildbot to rebuild luci... Jan 07 01:08:44 dangole: in any case, I can report failsafe -> "firstboot" (WITHOUT doing a mount_root) successfully resets uci settings, clears file from / /etc /root /etc/config that I left there, etc... it says much the same thing about jffs2reset and so-on, but upon reboot actually takes effect, hooray! Jan 07 01:11:42 Was also pleased to see recently that all the ath10k kernel/firmware updates, such that 5ghz working as WPA-*client* works on the HHv5a, wasn't previously the case... =) Jan 07 01:41:18 mangix: how do I test http://patchwork.ozlabs.org/project/openwrt/patch/20210107011431.1412261-1-rosenp@gmail.com/ ? Jan 07 01:50:16 aparcar[m]: on an openwrt device, "ldd /lib/lubvalidate.so" Jan 07 01:51:07 IIRC, there's also the one in InstallDev but I don't remember ldd working there. Jan 07 01:51:27 aparcar[m]: malta also works Jan 07 01:52:12 oho interesting Jan 07 02:24:50 there are actually multiple packages like this... **** ENDING LOGGING AT Thu Jan 07 03:00:55 2021