<hurricos>
pkgadd: Don't forget though. 11ax has interference. One single 11ad channel is 2160MHz wide (`iw reg get`)
<hurricos>
shibboleth: Cool! You can get QCA9462+wil6120's for like $10, but you need the wil6110 for the actual RF. Found that out the hard way last year :'(
<olmari>
Borromini, xback: thank you, I was yet to found it myself from mail :)
<rsalvaterra>
olmari: What's your ath10k hardware?
<olmari>
c7 v2 in this case
<rsalvaterra>
That's QCA9880, right?
<olmari>
yep
<xback>
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
<rsalvaterra>
You want a htt variant.
<rsalvaterra>
Actually, I asked greearb_ for a -ct-htt diet variant, months ago, but he probably forgot about it… :)
<olmari>
rsalvaterra: that what I extrapolated from the mailinglist xback linked, too :)
<xback>
greearb_: for Dynack to function, it is required to have proper TSF available and readable in the ath10k driver. Is it feasible?
<xback>
greearb_: dynack is currently ath9k bound, but it could be moved to mac80211 generic so ath9k and ath10k can share the code
blogic_ is now known as blogic
<olmari>
2018 (the mail date)... Have I really been not thinking, or looking, anything ath10k FW related.. damn =)
<xback>
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)
<rsalvaterra>
xback: It would be nice to have dynack in all drivers, if possible… :)
<olmari>
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
<xback>
keep in mind it only brings advantages when distance is >5km :-)
<olmari>
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
<olmari>
xback: yep, something like that I did remember
<rsalvaterra>
xback: Good for long range ubnt stuff. :)
<olmari>
So, I guess main thing to say at this moment is thank you all for making and keeping openwrt happend :)
<olmari>
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 😀 )
<rsalvaterra>
olmari: Thanks, but not any time soon… :(
* rsalvaterra
is wating for his COVID-19 test result…
<rsalvaterra>
*waiting
Tapper has quit [Ping timeout: 246 seconds]
<ldir>
Oooh exciting!
<rsalvaterra>
Huh…?
Darkmatter66 has quit [Max SendQ exceeded]
<Borromini>
ldir is a positive thinker
<rsalvaterra>
Given how my sense of smell is completely bonkers, I'd say "positive" is the most likely result…
<Borromini>
rsalvaterra: it's not fun. went through it myself
<rsalvaterra>
Borromini: Ouch… :(
<olmari>
Is ldir more exited about proper more conformant "springy" swab stick or prefer the hard one sticked through nostril as exiting? ;P
<Borromini>
wife somehow still thinks i didn't have it (two negative tests, but even the pcr test still has a 33% 'false negative' rate)
<olmari>
Unless comment was for something historical ;)
<Borromini>
IP packets are being routed more slowly after brexit ;)
* Borromini
hides
<nitroshift>
rofl Borromini
* nitroshift
hides behind Borromini
<xback>
Borromini: probably an extra firewall got installed accross the channel ..
<rsalvaterra>
Borromini: To me, right now, everything smells like vomit. I kid you not.
Darkmatter66 has joined #openwrt-devel
<Borromini>
xback: hehe
<Borromini>
rsalvaterra: that sucks. i didn't smell anything. and of course taste suffers too. hope you aren't seeing any other side effects.
<rsalvaterra>
Just joint/muscular pain and low fever, easy to manage. No cough or trouble breathing, thank God.
Tapper has joined #openwrt-devel
<Borromini>
fingers crossed!
<rsalvaterra>
A friend of mine feels everything smelling of seafood. Lucky girl. Guess I got the short end of the stick. :P
nlowe has joined #openwrt-devel
<Borromini>
:P
<olmari>
rsalvaterra: hey.. cheap eating... Straight from trash and tastes as good as prime steak ;)
<rsalvaterra>
olmari: Oh, my…!
* olmari
hides behind nitroshift
<rsalvaterra>
You guys are sick. Please, go on. :P
victhor has joined #openwrt-devel
<Borromini>
and here i thought finland was more or less okay in the corona crisis :P
<olmari>
How else we would survive around here? ;)
<Borromini>
xD
victhor has quit [Read error: Connection timed out]
victhor has joined #openwrt-devel
Tapper has quit [Ping timeout: 264 seconds]
<Borromini>
blogic: could the rtl838x-poe package be brought into the tree? or is it too early for that?
<blogic>
Borromini: erm, we can do that i guess
<Borromini>
:)
<nlowe>
Awesome, the rtl838x is pretty exciting, going to grab a GS108T and GS110TPP for some testing
<Borromini>
nlowe: keep an eye on the revisions though
<nitroshift>
quick question: is mt76 still a good buy?
<Borromini>
gs180t is only v3 supported afaict
<Borromini>
nitroshift: i'd say yes, personally.
* ldir
collects a whole load of packets piled up at the border - again - silly idea this brexit
<nitroshift>
thanks Borromini
<nitroshift>
was looking at a d-link dir-2660
<Borromini>
nitroshift: although there's no real triple radio devices on the market apparently
<Borromini>
i have the dir-878 a1 :)
<nitroshift>
Borromini, i don't need triple radios
<ldir>
rsalvaterra: talking of things smelling of vomit - parmesan cheese in the 80's from those round dispensers brought out on special occasions.
<nitroshift>
hell, even the 2 radios on wrt3200acm's are overkill for me
<Borromini>
:)
<Borromini>
i have a poor man's mesh situation atm, but just using a wds with mt76
<ldir>
rsalvaterra: whatever you have, covid or not, hope it's not horrible...or more importantly...deadly
Tapper has joined #openwrt-devel
<ldir>
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.
<Borromini>
it feels like someone's drilling into your brain.
<Borromini>
it goes up *that* far
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #openwrt-devel
<ldir>
Ewwwwww - I hope I never have to take a test - and can fall on a set of needles containing vaccine soon.
<Borromini>
UK seems to be doing that quite well, vaccinating
* Borromini
looks at belgium
<Borromini>
at least our numbers are down, but that won't help with 700 people getting a vaccine every week >_>
<ldir>
Unfortunately I'm 3 months outside of falling into any 'special case' vaccine category... not quite old enough
<ldir>
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.
* ldir
goes to pay tax bill
<Borromini>
:P
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
<Borromini>
death and taxes, they say
Darkmatter66 has joined #openwrt-devel
<rsalvaterra>
ldir: Well, parmesan cheese, *is* made with vomit. :P
<Borromini>
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.?
<rsalvaterra>
And yeah, the swab is horrible, but there are worse things… ;)
<Borromini>
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
<blogic>
Borromini: mine is 128mb
<blogic>
they are all 128
<blogic>
not seen any 64mb ones
<Borromini>
blogic: you got a gs1900-8hp as well?
<Borromini>
it's a bit weird for smallnetbuilder to misread chips, i'd think.
<Borromini>
svanheule[m]: told me the memory node has been moved out of the rtl838x.dtsi either way though, in the upstreaming effort
<blogic>
correct
<Borromini>
so shall i put it in the shared dtsi for each lineup? e.g. dgs-1210 and gs1900?
<blogic>
probably best to do so
<Borromini>
alright, thanks
<Borromini>
would you mind reviewing the realtek/gs1900 v2 patches i'm sending in? Can I cc you?
<blogic>
when did you send it ?
<blogic>
ah, when they arrive
<blogic>
just ping me once they are posted
<Borromini>
i sent a v1 but already marked it as superseded
<Borromini>
alright, will do
agb[m] has quit [Quit: Bridge terminating on SIGTERM]
svanheule[m] has quit [Quit: Bridge terminating on SIGTERM]
aparcar[m] has quit [Quit: Bridge terminating on SIGTERM]
pgwipeout[m] has quit [Quit: Bridge terminating on SIGTERM]
akira25[m] has quit [Quit: Bridge terminating on SIGTERM]
nick[m]1 has quit [Quit: Bridge terminating on SIGTERM]
lnslbrty has quit [Ping timeout: 256 seconds]
fblaese has quit [Quit: Bridge terminating on SIGTERM]
olmari has quit [Quit: Bridge terminating on SIGTERM]
voltagex has quit [Quit: Bridge terminating on SIGTERM]
decke[m] has quit [Quit: Bridge terminating on SIGTERM]
MatMaul has quit [Quit: Bridge terminating on SIGTERM]
JuniorJPDJ has quit [Quit: Bridge terminating on SIGTERM]
lnslbrty has joined #openwrt-devel
Floppe has quit [Remote host closed the connection]
Floppe has joined #openwrt-devel
voltagex has joined #openwrt-devel
gch98121332897 has joined #openwrt-devel
gch9812133289 has quit [Ping timeout: 264 seconds]
<nbd>
for mt76 i prefer changes to be sent to linux-wireless directly
<ynezz>
I would do that, but the upstream code is ok
<ynezz>
I mean, I've checked code in 5.4 branch
<olmari>
Did archer c7 (or chipset, or owrt in this env) support VHT160?
Tost has quit [Ping timeout: 264 seconds]
<olmari>
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 :)
<ynezz>
nbd: IIUC the code in that mt76 repo is used in OpenWrt and is different then in upstream
<rsalvaterra>
olmari: No.
<nbd>
ynezz: there are some pending changes in mt76.git that aren't upstream yet
<olmari>
rsalvaterra: thank you
<nbd>
ynezz: but aside from those changes, i keep mt76.git mostly in sync with my upstream tree
<nbd>
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
<olmari>
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 :)
<ldir>
xback: pong
<xback>
ldir: I noticed you did some work on hostapd-basic etc
<xback>
I was playing around with 802.11r etc and tried playing with the bgscan modules
<xback>
could it be that a build flag is missing in the 4 templates?
<ynezz>
nbd: ok, thanks for the info
<xback>
I think #CONFIG_BGSCAN=y should be added next to the module selection
<ldir>
xback: I have absolutely no idea - that was a lifetime ago.
<olmari>
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
<xback>
802.11r works fine
<olmari>
cool :)
<xback>
but to perform a lot better the bgscan modules are required on clients
<olmari>
sorry for the kinda stupid Q's, but curiours carl is curipous :P
<olmari>
xback: ah, that the talk is referring to, thank you for explaining
<ldir>
I vaguely remember there was a desire to have 802.11'foo' support but not to have a size penalty for small devices.
<olmari>
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
Ultrasauce has quit [Quit: Ultrasauce]
<rsalvaterra>
ldir: I'd be happy if I could get airtime policy enforcing to work…
<rsalvaterra>
… I mean, everything's in place, but I always see all stations with an airtime weight of 256…
<olmari>
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
zkrx has quit [Ping timeout: 240 seconds]
<ldir>
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
<rsalvaterra>
ldir: Terrible performance, really? What driver/firmware were you using? O_o
<olmari>
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
Ultrasauce has joined #openwrt-devel
<mrkiko>
ldir: ath10k-based?
<rsalvaterra>
olmari: 802.11w (and WPA3 Personal) work just fine with ath10k-ct and the -ct-htt firmware.
<ynezz>
hm, I just gave c7v4 with 19.07.5 to my 13y nephew and he's so happy with that
<jow>
ynezz: when can we expect his first patches? :)
Tost has joined #openwrt-devel
<olmari>
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
<ynezz>
jow: after he finishes that minecraft :p
<rsalvaterra>
jow: Don't promote child labour… :P
<jow>
it's not labor, it's "fun"
<jow>
*labour
<mrkiko>
ynezz: does he/she play with openwrt as well?
<olmari>
..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....
<olmari>
(say, Inteno)
<olmari>
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
<rsalvaterra>
Speaking of patches, is the x86 dead code/data elimination patch good to go as is, or does it need more massaging?
<olmari>
(like on inteno I
<olmari>
..I'm most irritated that they blatantly use openwrt but blatantly ignores rest of OSS stuff (be it BRCM deal in itself)
<ynezz>
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
<ynezz>
was quite excited about the more verbose/advanced user interface, so lets see where it goes :p
<rsalvaterra>
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. :)
hsp has quit [Quit: WeeChat 3.0]
<mrkiko>
ynezz: oh, awesome!!!!
<mrkiko>
olmari: yes, I had some experiences in this sense with Netgear BCM device - the one I sent about in the mailing list
<rsalvaterra>
ynezz: He needs to learn the ways of the terminal… ]:)
<mrkiko>
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.
<mrkiko>
rsalvaterra: he will he will :D
<mrkiko>
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
<mrkiko>
now faiting with CFE as usual :D
<olmari>
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"
_lore_ has joined #openwrt-devel
<olmari>
I mean I am not saying 1th9k or now ath10k is automatically crap etc, but all the best stuff is kept highly NDA
<mrkiko>
olmari: ehehe yes, fw
<mrkiko>
BTW, was curious when I see the AD7200 with the wilocity driver not mach80211-based.
<mrkiko>
there's a very good reason why a common wi-fi stack exist, still remember the time when this wasn't the case.
hsp has joined #openwrt-devel
<olmari>
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
<olmari>
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
<olmari>
said*
<mrkiko>
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,
<mrkiko>
cleanness and overall care as openwrt guys have.
<olmari>
...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
nitroshift has quit [Quit: Gone that way --->]
<olmari>
mrkiko: I love openwrt.. I hate OEM's exploiting owrt... I love many OEM's wifi performance/working wellness...
<mrkiko>
olmari: yes, I understand
opal has quit [Ping timeout: 240 seconds]
<olmari>
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
opal has joined #openwrt-devel
<olmari>
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"
<olmari>
for given OEM it would not change an thing... they cna keep making good device as-is
<mrkiko>
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).
<olmari>
I don't see how could any chip MFG lose in being better for OSS-community
<olmari>
the Inteno and rest of device-OEM's can keep doing as they are now, they are not affected directly
<mrkiko>
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
<mrkiko>
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
<mrkiko>
I agree with you in any case - would be very very nice to have openwrt run on many devices.
<olmari>
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
<olmari>
in such sense device mfg situation would not change... nor chip OEM either...
<mrkiko>
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.
<olmari>
those who does care about owrt would keep byuing those device, benefittinh both device and chip MFG at least until every one does same
<olmari>
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
<ldir>
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.
<olmari>
Just to tell it aloud, nothing news there in itself
<olmari>
I mean it is even mentioned in owrt wiki/documents/whatever the wireless settings page is
<greearb_>
whoever pinged me, it ran out of my buffer...
_lore_ has quit [Read error: Connection timed out]
_lore_ has joined #openwrt-devel
<olmari>
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
<olmari>
some functions needs to be moved from ath9k to, say, mac80211, or something
zkrx has quit [Ping timeout: 272 seconds]
<olmari>
I think that covers majority of "concerns" that folks were pinging you with
<greearb_>
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.
<olmari>
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)
<Borromini>
greearb_: i think it was xback
<mrkiko>
noltari: are you around??
<greearb_>
I know who did it, not sure their irc handle though
<mrkiko>
greearb_: using your -ct firmware on FRITZ!BOX 7530, 2.4 ghz only, no problems so far
<greearb_>
good deal. Based on github ath10k-ct bugtracker, it is pretty stable, but there are probably some power-save bugs somewhere.
opal has quit [Ping timeout: 240 seconds]
<rsalvaterra>
greearb_, still no diet -ct-htt wave 1 firmware? :)
<greearb_>
the kind of bugs that happen after several days and only in some situations
kakaka has quit [Ping timeout: 240 seconds]
<greearb_>
I can build you a diet one if you want...will add it to my list of things to do
<rsalvaterra>
Yes, please! No rush, but it would really nice-to-have. :)
<mrkiko>
greearb_: I'll let you know if something happens
<mrkiko>
greearb_: thanks!
<Borromini>
greearb_: what do you mean?
<greearb_>
Borromini, about what comment?
<Borromini>
'i know who did it, not sure their irc handle though'
opal has joined #openwrt-devel
<greearb_>
I know who to ask about dynack in ath10k-ct, via email
<mrkiko>
real person->irc nick mapping I guess
gch98121332899 has joined #openwrt-devel
<Borromini>
greearb_: koen vandeputte
gch9812133289 has quit [Ping timeout: 246 seconds]
gch98121332899 is now known as gch9812133289
<mrkiko>
hi gch9812133289 ! Still grateful for your help with the R6220 that time of the 5.4 transition
<greearb_>
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.
gch9812133289 has quit [Read error: Connection reset by peer]
gch9812133289 has joined #openwrt-devel
* mrkiko
googles about CFE boot loader, but finds links about the Common Final Exam
<mrkiko>
LOL
kakaka has joined #openwrt-devel
brainslayer89 has joined #openwrt-devel
<olmari>
actually... wpa3/2 sae mixed makes intel ac wifi not see/report ssid at all... wpa2 alone does... meh
<olmari>
there is always something :P
valku has joined #openwrt-devel
<Borromini>
olmari: windows client?
<olmari>
Borromini: debian buster, kernel 5.9
<Borromini>
oh. i just use wpa3. bullseye and 5.9
<Borromini>
not sure how much userland support you need besides a recent wpa-supplicant
<olmari>
Borromini: well, iwlist scan does not even show the network, while other devices are connected happily (thus network works)
brainslayer89 has quit [Remote host closed the connection]
<PaulFertser>
olmari: iw dev wlan0 scan is better but it's unlikely to affect the outcome of course
<nlowe>
For LuCI, how do I make a listvalue item dependent on another listvalue item having been selected?
<nlowe>
Trying to work out how to put a dependency in the o.value(...)
Tapper has joined #openwrt-devel
victhor has quit [Ping timeout: 264 seconds]
zkrx has quit [Ping timeout: 272 seconds]
<karlp>
o.depends right?
<karlp>
o.depends("option", "req_value") is what I've got in some stuff
<karlp>
oh, for individual list values? not sure...
<jow>
should not work different than normal depends
Tapper has quit [Ping timeout: 240 seconds]
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
<karlp>
so o = s.option(ListValue...); o.value("blah", "wop"); special = o.value("extra", "extra2"); special.depends("otheroption", "othervalue") ?
<xback>
greearb_: thanks for checking regarding dynack. feel free to let me know if the customer decides to share it
<xback>
greearb_: _lore_is also interested in getting it mainline (please correct me if i'm wrong _lore_)
<olmari>
"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 =)
<olmari>
not that on purely AP it makes much difference, or would it?
<olmari>
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 :)
Tapper has joined #openwrt-devel
<xback>
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 ;-)
<hurricos>
olmari: never. archer c7 is QCA9880v1 and v2 -- v1 being bad silicon. The only VHT160 support was in 99XX series
<olmari>
hurricos: That would indeed explain it :)
<greearb_>
xback, I think that cannot work for a mobile environment?
<nlowe>
karlp: That gives me "TypeError
<nlowe>
Cannot read property 'depends' of undefined"
<nlowe>
I don't seem able to assign o.value(...) to a variable, then call depends(...) on it and have it work
<karlp>
yeah, that was what I was checking with jow, I wasn't sure abotu list items either.
<karlp>
entire lists ,sure, but not indiv items
<hurricos>
olmari: For every one of those good commercial experiences there's a meraki eol experience too
<hurricos>
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 ...
<nlowe>
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
<olmari>
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
<hurricos>
And what firmware exists that you can rebuild it and turn a mesh AP into a 4-drive NAS with iSCSI capability?
<hurricos>
cisco comes close in terms of long-lasting. no doubt about it
<olmari>
well for me talk is more or less specifically AP use only in this context :)
<karlp>
nlowe: just put (requries WPA3) in the description an dmove on with your day :)
<hurricos>
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
<hurricos>
will last long past our tech boom, long past running out of natural resources to continue building these devices for nothing
<olmari>
hurricos: yes.... all that will not help me tackling incoming calls about "me wifi broken" or something alike ;P
<hurricos>
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
<hurricos>
olmari: speaking of, testing procd-ujail and procd-seccomp now.
<olmari>
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 (:
Tapper has quit [Ping timeout: 265 seconds]
nlowe_ has joined #openwrt-devel
dottedmag has left #openwrt-devel [#openwrt-devel]
<dangole>
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
<hurricos>
dangole: umdns seems easier to test, but transmission-daemon will do more syscalls due to file io I'd expect
<dangole>
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)
dirkSt has joined #openwrt-devel
DirkS has quit [Ping timeout: 260 seconds]
dirkSt has quit [Client Quit]
DirkS has joined #openwrt-devel
hurricos1 has joined #openwrt-devel
hurricos has quit [Ping timeout: 272 seconds]
hurricos1 has left #openwrt-devel [#openwrt-devel]
hurricos1 has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
victhor has quit [Read error: Connection reset by peer]
victhor has joined #openwrt-devel
<mangix>
aparcar[m]: dedekeh is handling that. no idea qhat happenwd.
<mangix>
that is, it's a workaround for lua being broken.
Borromini has quit [Quit: Lost terminal]
<aparcar[m]>
So which arch can I use for testing?
<mangix>
archhs
<jow>
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
lmore377_ has joined #openwrt-devel
lmore377 has quit [Read error: Connection reset by peer]
<jow>
dangole: oh, just noticed that iwinfo.git is not using cmake
<dangole>
jow: that's why i was asking...
<mangix>
the arc700 buildbot is amusing to me. it uses uClibc-ng even though it's gone from the tree
<jow>
dangole: only lightly tested, would appreciate if you can give it a spin and push if it works
<jow>
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)
<dangole>
jow: will give it a spin right away, thanks!
<jow>
these changes should make future abi-breaking updates less painful hopefully
<jow>
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
<jow>
(the second patch might need rebasing, my local tree is stale)
aptanet has joined #openwrt-devel
_whitelogger has joined #openwrt-devel
<jow>
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
gch9812133289 has quit [Ping timeout: 264 seconds]
gch98121332893 is now known as gch9812133289
<jow>
which is a precondition for somewhat seamless upgrades to a newer version
<dangole>
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...
<dangole>
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
<dangole>
jow: both patches apply cleanly, will test-build using git-src for iwinfo
<mangix>
jow: is this anything to be worried about? Error relocating /usr/lib/lua/uci.so: lua_objlen: symbol not found
<mangix>
that's from ldd on /usr/lib/lua/uci.so
<jow>
mangix: I guess lua/uci.so does not link liblua and relies on the host program loading it to provide the required symbols
<dangole>
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
<mangix>
it sounds like uci.so should be fixed anyway
<jow>
dangole: out of space can be recovered from, a broken system due to a binary-incompatible libubus.so not so much
<dangole>
jow: very true
<dangole>
jow: and likely that people will just force-overwrite files which are seemingly owned by the library they are trying to install
<dangole>
jow: for libiwinfo parallel installs btw. without force-overwriting files still wouldn't work because of hardware.txt...
<dangole>
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
<mangix>
huh, what is this HIDIOCGRDESC?
<dangole>
jow: ok, test build with completely new checkout and your two patches on top
<aparcar[m]>
jow: are you at some point free to work on the buildbot with me?
<mangix>
what the...
<mangix>
why does man 3 ioctl specity int for the second parameter but man 2 ioctl specifies unsigned long?
<aparcar[m]>
mangix: what arch should I use to compile collectd?
<aparcar[m]>
i'm parsing this as <buildbot>, <feeds patch>?
<enyc>
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?
<dangole>
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)
ivanich has quit [Quit: Konversation terminated!]
<jow>
aparcar[m]: yes, no opinion on the feeds patch
<jow>
aparcar[m]: but makes sense on a first glance. s/float/flood/ though
dangole has quit [Remote host closed the connection]