nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
victhor has quit [Ping timeout: 480 seconds]
victhor has joined #openwrt-devel
victhor has quit []
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<Namidairo>
oh look, my new hardware is here
<stintel>
poidh :)
<Namidairo>
time to test out whether this command injection vuln I speculated is workable or if I'm going to have to overwrite u-boot env and recalculate the crc
<slh>
redmi ax6s or something else?
<Namidairo>
^
<slh>
could be a nice alternative :)
<Namidairo>
256mb memory might be a little tight though
<slh>
yeah, although mt76 should be better at conserving RAM (than ipq**xx)
<rsalvaterra>
… it should improve the VM behaviour under memory pressure, especially when swapping to zram.
<stintel>
yeah that behaviour under pressure could use _some_ improvement :P
<stintel>
when it happens on my laptop it feels like it hard locked
<rsalvaterra>
Tell me about it… my laptop has 2 GiB of RAM, soldered. :P
<stintel>
wtf
<stintel>
I have 8 and its barely usable
<stintel>
speaking about laptops, I need to find a decent black friday deal
victhor has joined #openwrt-devel
<stintel>
<30m of batter life, broken keys on keyboard, just dog slow these days ... time for something new
<rsalvaterra>
I wouldn't say that… my laptop had Eclipse, NetBeans, Firefox, Chromium, and a MySQL running… simultaneously. Without swap.
<rsalvaterra>
(Well, with zram, not disk swap.)
<rsalvaterra>
Last weekend I tried to forward-port the MGLRU patch set to 5.16, but it clashed hard with Matthew's page folios, so I gave up, as my mm-fu isn't that strong. :)
<stintel>
rsalvaterra: lol, the benchmark results are even too cryptical for me :P
<stintel>
!seen rmilecki
<stintel>
I wonder if his mt76 issues got solved
<stintel>
as I'm also hitting stalls with mt7613ben
<stintel>
the thread seems to have lived on on linux-wireless but not xposted to openwrt-devel, let's see what I can find there
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<rsalvaterra>
stintel: I think Borromini has also been battling the MT7613, I don't know if his issues got fixed.
<stintel>
I know about non-working DFS
<stintel>
but that's lower prio than stability issues on a non-DFS channel
<stintel>
but I will be looking into that too
<stintel>
if I can wrap my head around it
<stintel>
I'm working with the same APs he has, afaik, TP-Link EAP235-Wall
<stintel>
cute little thingies, initial impression was: wow, way faster than my QCA crap
<stintel>
so I've unplugged my EAP245 v3 already - while wave 2, gets less than 200Mbps on decent client
<stintel>
the 235 does 600+ on my phone ¯\_(ツ)_/¯
<rsalvaterra>
MediaTek > QCA.
<stintel>
oh you don't need to convince me
<stintel>
I hate QCA with a passion
<stintel>
heck have you seen QSDK ?
<rsalvaterra>
No. It scares me.
<stintel>
just seeing that it's CC based with 4.4.60 ...
hgl has quit [Remote host closed the connection]
<stintel>
it should be illegal to release hardware with such ancient crap
rua has joined #openwrt-devel
<rsalvaterra>
To be honest, all vendor SDKs scare me. :P
<stintel>
that's like 200+ minor revisions behind latest 4.4 LTS
<stintel>
do they backport security fixes? to they inform their clients/partners of that?
<stintel>
I think in both cases it's a simple no
hgl has joined #openwrt-devel
<stintel>
so these things are all accidents waiting to happen
<stintel>
I guess the S in Qualcomm stands for security
<rsalvaterra>
Sometimes I think our entire field is just a single, monstrous hack which happens to "work".
<stintel>
you mean computers in general?
<rsalvaterra>
*sigh*
<rsalvaterra>
Yeah.
<stintel>
and anything related. yeah, I feel ya
<Habbie>
it's sand that thinks
<Habbie>
i'm not sure why we're surprised
<rsalvaterra>
It doesn't think yet, thankfully…
<rsalvaterra>
… and I'm keeping a hammer at hand, for when it starts.
<Habbie>
smart
<stintel>
Habbie: o/
<Habbie>
o/
<stintel>
I live on the 7th floor, I don't need a hammer I can just let gravity fix it ;)
<Habbie>
"i hope there was nobody on that bus" "well, at least nobody we know or care about"
<stintel>
heh
<stintel>
nice timing, 40+ death on a bus fire in Bulgaria yesterday :(
<Habbie>
oh :(
<stintel>
that number vanishes compared to the covid deaths though
<karlp>
yeah, .bg is "winning" that one right now aren't they :(
<stintel>
with maybe 1/3rd of the population fully vaccinated
<stintel>
scroll down to the bottom, not nice numbers
<stintel>
it started very nice here due to insance lockdowns, couldn't even leave the cities unless you could prove it's for work or you live outside of the city - but in the latter case, once out, no coming in
valku has joined #openwrt-devel
<stintel>
and you can actually see that very well in the first part of the graphs
mzvd has joined #openwrt-devel
mzvd has quit []
<Habbie>
bleh
rua has quit [Ping timeout: 480 seconds]
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
rua has joined #openwrt-devel
<nitroshift>
nbd, your mac802111 patch works
<nitroshift>
*mac80211
<nbd>
the one with the aggregation ssn fix?
<stintel>
nbd: you recall rmilecki's stalls with mt7628an? did you fix anything for that?
<nitroshift>
nbd, yes
* nitroshift
sends nbd a case of beer
<stintel>
:)
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<nitroshift>
i'm at work, flashed 2 rango's at home remotely, wife called: "did you do something to the routers? wifi is working a lot better!"
<stintel>
:D
<stintel>
imagine they not combing back
<stintel>
you'd be staying in a hotel for the night ;)
<nitroshift>
stintel, even worse: sleep in the car :))
<stintel>
😂
<nitroshift>
she'd take my credit cards too
<nitroshift>
anyway, time to go home, talk tomorrow :)
<stintel>
give her my regards :)
<nitroshift>
stintel, i will, thanks
<nitroshift>
when do i get to give my regards to yours? :p
hgl has quit [Remote host closed the connection]
<stintel>
in another metaverse
<nitroshift>
rofl
* nitroshift
went that way ----->
nitroshift has quit [Quit: Gone that way --->]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
pmelange has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
<stintel>
interesting, just had a stall, the client showed as associated, the AP disagreed
hgl has joined #openwrt-devel
<nbd>
stintel: still no idea about the 7628an stalls
<nbd>
though a fix that i pushed might help with it
<stintel>
nbd: did you push that recently?
<nbd>
yes
<stintel>
I'm on 398cbb76fa88 ("hostapd: allow hostapd under ujail to communicate with hostapd_cli")
<nbd>
that includes the mt76 fix
<stintel>
ok, just had a stall on mt7613ben
<stintel>
I locked my laptop on the bssid so it's always on that one
<nbd>
yeah, mt7613 still has some lockup issues where the firmware or hw stops sending packets and just keeps them queued up for some reason
<stintel>
directly after association no connection, client showed associated, about 280 pings -> unreachable
<nbd>
i still don't know if that's a driver or firmware issue
<nbd>
i'm waiting for a newer reference driver/fw from mtk
<nbd>
to compare
<stintel>
I see
<nbd>
i will look into those issues again once i get the new code
f00b4r0 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<stintel>
nbd: thanks for the ifno
<stintel>
info*
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
nlowe has joined #openwrt-devel
<dhewg>
nbd: thx for the mesh warning fix. Which reminds me, there's another mesh issue: when one openwrt mesh+sae device reboots, the other gets MESH-SAE-AUTH-FAILURE a few times and finally gets blocked for 5 minutes
<dhewg>
it seems there's a window where the other device sees the mesh but it takes a while unit the peer is ready for action, and the fail happens in between or something like that
<dhewg>
*until
<nbd>
hm, it seems that i just found an old patch of mine for that issue
<nbd>
that i completely forgot about
<nbd>
and apparently never made it to the tree
<nbd>
i'll forward port it and put it in my staging tree, so you can test it
<dhewg>
sound good, thx!
dangole has joined #openwrt-devel
<mirko>
dangole: evening :)
<mirko>
dangole: what did i mess up by merging too fast?
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<dangole>
mirko: I was still using github CI to get builds for all architectures and because that took to long, i was about to split the PR and let mesa, wayland and wayland-protocols go first and then all the rest
<dangole>
mirko: i built it all locally and i believe the one failing arm variant was most likely just CI build hickup. just to verify would have been another hour or two of keeping github CI busy.
<mirko>
dangole: my getaway is that i shouldn't be too excited about MRs in the video feed which for a long term i was the only one caring about
<mirko>
dangole: feel free to merge yourself whenever you feel comfortable
<mirko>
given the current situation: i wouldn't mind a force-push if you think that unmesses(TM) the situation
<dangole>
mirko: nah, don't worry.
<dangole>
mirko: what i would like to see some is to have buildbot or github CI or whatever provide binary builds for the video feed...
<dhewg>
nbd: thanks, will test that one :)
<dangole>
nbd: wow, you may have just fixed the most annoying 802.11s bug in history. libremesh already had userspace watchdog-style workarounds for infinite SEA-AUTH in blocked state ;)
Acinonyx_ has joined #openwrt-devel
<nbd>
dangole: :)
<mirko>
dangole: sounds good, however i too often ran into situations where i couldn't decide on a default set of compile options for graphics stack. it's already hard for desktop distributions, but even more specific on embedded systems. so i'm mainly using the feed for custom builds. but happy about another attempt, maybe wayland makes things easier / more generic here
<dhewg>
I assume that patch is required on all nodes?
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
hgl has quit [Remote host closed the connection]
<nbd>
dhewg: yes
hgl has joined #openwrt-devel
<dangole>
mirko: even just having usable Mesa libs for all platforms would already be nice. and i'm still looking for a good DOOM implementation which runs on KMS/DRI layer (anyone?)
<dangole>
mirko: porting Arcan and using it with Pipeworld would also be a more serious idea, but I haven't found the time for it yet. that would already allow for a useful dashboard and such
<mirko>
dangole: apart from polishing the qt stuff, having kodi with gbm backend runing on AW-H6 is still on my todo
<stintel>
dangole: since you've been working a lot on procd, would it be a lot of work to introduce an option for services to manipulate oom_score_adj?
<stintel>
I had netifd and hostapd being killed on one of my devices yesterday, while it's also running lldpd, snmpd, etc
<stintel>
netifd and dropbear should probably never been killed, hostapd/wpa_supplicant similar, the rest is not that important
<stintel>
so such an option would imo make a lot of sense
<dangole>
stintel: the codepaths to do that exist in ujail, but it's only wired up for OCI containers atm.
<stintel>
yeah I sawy that, so it could be relatively easy is what you're saying ?
<dangole>
stintel: regarding oom_score_adj: we'd either have ujail handle it (wire up ujail cmdline parameters, have service instance handle parameter and pass it to ujail) or copy-paste the implementation to procd and handle it there directly.
<dangole>
stintel: both is not hard to do, it's pretty simple in the end...
<dangole>
stintel: regarding @blogic's path which I have improved a bit: currently we only make use of service_stop_all() for sysupgrade, but could be used for normal shutdown/reboot as well
<nbd>
dangole: btw. i just got around to looking at the service stop change with the vlist_for_each_element_safe
<nbd>
i think that vlist_for_each_element_safe is unnecessary
<stintel>
I can send that out to ML for wider review, adding Closes: FS#609
<dangole>
nbd: but that will flush the service vlist but it will not actually stop anything, right?
<nbd>
if you flush the instances, it will call service_instance_update for each entry, which calls instance_stop
<stintel>
also serious facepalm, wondering why this rpi4 doesn't want to connect to wifi... pretty obvious if no wpad or wpa_supplicant is added in the image
<dangole>
stintel: yes, i believe so, that should do the trick
<nbd>
dangole: so same flow as when instances get removed on stopping the service or reloading it with an empty instances set
<stintel>
dangole: that's cool, I will test it locally and send to ML
<nbd>
stintel: good news. i got a new code drop for 7613 from mtk
<stintel>
nbd: neat :D I poked around a bit, maybe that helped ;)
<rsalvaterra>
It's blocking 5.10 as default for ramips.
<nbd>
stintel: it definitely reminded me to ask mtk for newer code again ;)
<stintel>
nbd: I was poking around at work too, but people are off for thanksgiving or something
<stintel>
but great
<stintel>
blogic also explained me the problem, I took out an rpi4 to try and reproduce it
<stintel>
it's nicer to script 256 assoc/disassoc events than to switch wifi on my phone off and on for 256 times 😂
<dangole>
nbd: btw i noticed mt76 doesn't care about any CRC whatsoever when it comes to reading EEPROM data. is mt76 just not checking it or is there really no integrity data for the wifi eeprom?
<nbd>
dangole: i'm not aware of any integrity data in the eeprom
<stintel>
hmm actualy FS#609 was about sysupgrade, I'll have to investigate how shutdown actually works currently
<nbd>
stintel: pushed an mt76 branch 'testing' with a fw update
<nbd>
will look for more potential fixes later
<nbd>
but it's worth testing already
<stintel>
nbd: that was quick - I'll work on repro script first, test later today and report back
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
nlowe has quit [Read error: Connection reset by peer]
hgl has joined #openwrt-devel
<stintel>
sigh, build a new image, forget to enable wpad
nlowe has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
<dhewg>
nbd: nice, seems to work! both devices updated with said patch, it got blocked as usual but could connect shorty afterwards anyway :)
<stintel>
I will try it too, I think I have a reproducer too
<stintel>
no magic, but on a raspberry pi I'm doing this: while [ $i -lt 256 ]; do ifup test; sleep 10; let i=$i+1; done
<stintel>
:P
<stintel>
it's basically disconnecting and reconnecting a client every ~10s
<Borromini>
:P :P
<stintel>
Borromini: do you also see a load average of 1.00 or higher all the time ?
<Borromini>
my network is cursed, i just setup my first bonded interface on a new toy i'm playing with and my laptop can't talk to it, all the other devices in my network can though >_>
<Borromini>
stintel: often, yes.
<stintel>
I have this on EAP235-Wall and Unifi 6 Lite
<Borromini>
not always, but often
<Borromini>
e.g. this idle EAP235 is close to zero, but it has no clients connected
<stintel>
the U6Lite is idle at my parents' place and: 19:18:00 up 25 days, 20:07, load average: 1.06, 1.03, 1.00
<Borromini>
ok
<Borromini>
hmm no this is my active EAP235
<Borromini>
sometimes a reboot 'fixes' it
<stintel>
interesting, maybe I'm including something that causes it
<stintel>
I've not seen it not happen so far
<stintel>
LOL ping replies of 360s
<Borromini>
is the U6Lite MT7613 as well?
<Borromini>
o_O
<Borromini>
i thought U6Lite was ax?
<stintel>
mt7603e for 2.4
<stintel>
so I'm betting it's SoC related, not wifi
<stintel>
or mt76 in general?
<stintel>
ok, it recovered
<stintel>
starting the loop again
<Borromini>
might be MT76 in general
<stintel>
could try booting a board and unload the driver
<stintel>
actually I have a DIR860L I could use for that
<stintel>
but doing too many things at the same time already :D
<Borromini>
:P
<stintel>
I first tried via hostapd_cli to disassociate a client, nothing happened after doing that 256 times
<stintel>
maybe it has to be an unclean disassoc if something like that exists
valku has quit [Quit: valku]
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
shibboleth has joined #openwrt-devel
<stintel>
Wed Nov 24 19:50:23 UTC 2021 upgrade: Commencing upgrade. Closing all shell sessions.
<stintel>
blogic: dangole: could that be a side-effect of your procd changes ?
<dangole>
stintel: yes, that could be active shell being killed by recent changes
<dangole>
stintel: any negative side effects apart from that message? if this is SSH, did the session close?
dangole_ has joined #openwrt-devel
<stintel>
dangole_: ssh clonnection closed after that, but sysupgrade does that anyway ?
<dangole_>
stintel: the specific message "Command 'call' failed" hints to a ubus call failing... probably we should be iterating over the services in reverse order to not kill ubus first thing (real dependency handling other than event-based startup and reload is out of scope imho)
dangole has quit [Ping timeout: 480 seconds]
<stintel>
dangole_: makes sense
Borromini has quit [Quit: leaving]
<stintel>
hmmm, with this EAP235-Wall being in between my media switch, I'm gonna have to install qosify on the AP and prioritize internal traffic :D
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
nlowe has joined #openwrt-devel
danitool has joined #openwrt-devel
<stintel>
ok, I've tried something uglier to repro the mt76 stall: export i=0; while [ $i -lt 1024 ]; do rmmod brcmfmac; modprobe brcmfmac; ifup test; sleep 6; let i=$i+1; echo $i; done
<stintel>
on the sta, was at ~330 when stall occurred
hgl has quit [Remote host closed the connection]
<stintel>
let's see if that happens again after it recovers
<stintel>
what is weird, my amp, which is behind the EAP235, is buffering spotify all the time
<stintel>
also the load average dropped below 1.00
<stintel>
but only 0.98
hgl has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Namidairo>
isn't the 7915 on the u6lite the dbdc variant
nlowe has joined #openwrt-devel
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
<nbd>
stintel: how's the updated firmwre doing?
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]