mzvd has quit [Read error: Connection reset by peer]
rua has joined #openwrt-devel
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
ekathva has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
mzvd has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
kistlin has joined #openwrt-devel
mzvd has joined #openwrt-devel
csharper2005 has joined #openwrt-devel
Tapper has joined #openwrt-devel
mzvd has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
goliath has joined #openwrt-devel
mzvd has joined #openwrt-devel
mzvd has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
<jow>
nbd: while testing an unrelated bug report, I noticed that `option macaddr` in `config device` sections referring to wlan devices is not applied
mzvd has quit [Read error: Connection reset by peer]
<jow>
nbd: I suppose this is due to special handling of wireless netdevs in netifd... I wonder whether config device for wifi netdevs is not supposed to work in general or if it is only specific settings such as macaddr which are not supported
mzvd has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
mzvd has quit [Read error: Connection reset by peer]
<Habbie>
stintel, on github, you can click the paper icon for a rich diff
<Habbie>
ignoring that feature, i agree that non-prettified is better for reviews
pepe2k has quit [Quit: Leaving]
<stintel>
interesting, didn't know that github feature
<stintel>
but yeah we dinosaurs with git send-email ...
<Habbie>
it's similar to the fight i sometimes have with people - i expect one sentence per line in markdown and .rst
<Habbie>
because anything else makes diff useless
<stintel>
ok I pushed hostapd ubus methods doc patch as is
<csharper2005>
stintel: is it better to send commits to OpenWrt using send-email? Do they get more attention?
<stintel>
depends on who you ask :)
<stintel>
I definitely pay more attention to the ML, github is a horrible mess of 1000s of irrelevant notifications so I stopped looking at them
Battista has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
<csharper2005>
stintel: I have a 1 year old pending ramips new device PR which was firstly reviewed by Adrian. What do you think, does it make sense to send it to ML?
<f00b4r0>
i used to think m-l was better, but my current score shows my PRs having been accepted much quicker than my email submissions :)
<f00b4r0>
stintel: btw, out of curiosity, is your qoriq-5.15 branch ready for testing? :)
Battista has quit [Remote host closed the connection]
<stintel>
f00b4r0: sure, running it in prod
<f00b4r0>
nice
<f00b4r0>
I'll give it a spin
<stintel>
csharper2005: it might, I honestly don't know if it will get more attention. I'd probably try pinging Adrian about it
minimal has quit [Quit: Leaving]
<csharper2005>
stintel: thanks. I hope he's all right. I haven't seen him on gh for several months...
<stintel>
I was just checking, he seems to be MIA indeed
<stintel>
I actually mailed him beginning of February, with a follow-up at the end of February, did not get any response
mzvd has quit [Read error: Connection reset by peer]
<karlp>
where was he based?
<stintel>
Germany afaik
<f00b4r0>
correct
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
mzvd has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
<stintel>
rsalvaterra: since you poked me about MBO, would you mind giving your feedback on the new approach ?
Battista has joined #openwrt-devel
valku has joined #openwrt-devel
<rsalvaterra>
MBO?
<stintel>
08|10:52:20< rsalvaterra> stintel: MBO only for -full? Seems desirable in other variants too. What's the size impact?
<rsalvaterra>
Oh!
<rsalvaterra>
Sorry, I was out of context. :P
Battista has quit [Read error: Connection reset by peer]
<stintel>
no worries :P
<stintel>
I have logs :P
<rsalvaterra>
Me too, but I'm lazier. :P
* rsalvaterra
hides
<stintel>
haha
Gaspare has joined #openwrt-devel
<rmilecki>
nbd: i see, thanks a lot for debugging that
<rmilecki>
nbd: i'll commit a fix as I get home, unless you have a moment to do that
<stintel>
one question I still have is: in the current form, on all these half-assed WiFi6 devices (2.4 11n + 5 11ax), this would enable MBO on 5G but not on 2.4. not sure if that makes sense
<stintel>
so maybe we should have some "global" flag, that enables MBO for all BSSes by default on 11ax capable APs
<rsalvaterra>
Is MBO forbidden in non-ax hardware?
Battista has joined #openwrt-devel
<stintel>
don't think so
<stintel>
I've tested it yesterday on 2 LiteBeam AC so it definitely works fine on non-ax hw
<rsalvaterra>
In that case, I don't see why it shouldn't be globally enabled…
Battista has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
<stintel>
requires 11w to be enabled with WPA2 or higher
<stintel>
pretty sure there is pre 11ax QCA junk out there that will crap itself due to that
ldir_ has joined #openwrt-devel
ldir has quit [Read error: Connection reset by peer]
<ldir_>
rmilecki: nbd: https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=b0f50ab68fca70c9f96db8cb14d172adfde3e7d0 if you can suggest some commit text I'll happily push as this has fixed my build problems (thanks Felix)
ldir_ is now known as ldir
<rmilecki>
ldir: "Flag -fno-plt works for compiling all/most user-space but has to be filtered out for kernel. It breaks its compilation. Filtering used to be done during export in the old code. Do the same when setting KCFLAGS"
<rmilecki>
ldir: feel free to rework/improve that description
<rmilecki>
ldir: i think you're native english, aren't you
<rmilecki>
?
Battista has quit [Ping timeout: 480 seconds]
<ldir>
I am afraid that is the case - native and English :-)
<rmilecki>
ldir: so definitely feel free to reword that description ;)
<stintel>
that's where it was initially disabled I believe
<rmilecki>
ldir: you can add Suggested-by: Felix Fietkau
<ldir>
sure :-)
<rmilecki>
ldir: ah, you did From: Felix, that's enough then :)
<rmilecki>
^^ Ignore that, looked at wrong commit
<rmilecki>
From: Kevin + Suggested-by: Felix Fietkau should be fine
<rmilecki>
ldir: https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commitdiff;h=b0f50ab68fca70c9f96db8cb14d172adfde3e7d0 <- there is sth messed up with spaces I think
<rmilecki>
too many spaces added ahead of KCFLAGS
<ldir>
will fix
<ldir>
screen copy/paste does that sometimes. normally I see it in vi though. Hmmmm
Battista has quit [Ping timeout: 480 seconds]
aiyion_ is now known as aiyion
Battista has joined #openwrt-devel
schwicht_ has quit [Read error: Connection reset by peer]
schwicht has joined #openwrt-devel
Unknown has joined #openwrt-devel
frwol has quit [Quit: leaving]
<rmilecki>
ldir: more standard way would be Fixes: 907d7d7472 ("kernel: support setting extra CFLAGS for kernel compilation")
<rmilecki>
ldir: not that it's really critical or anything ;)
<stintel>
but it's nice ;)
<stintel>
I have a simple script for generating that: echo "Fixes: $(git log -1 --pretty='format:%h ("%s")' --abbrev=12 ${1})"
<ldir>
done
<ldir>
just running a build to triple check
<rmilecki>
ldir: thainks a lot
<f00b4r0>
stintel: convenient! I'll save that :)
<rmilecki>
ldir: wait, it's wrong commit
<stintel>
f00b4r0: :)
<rmilecki>
correct: Fixes: 1d42af720c6b ("kernel: use KCFLAGS for passing EXTRA_OPTIMIZATION flags")
<ldir>
done - again :-)
Battista has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
guidosarducci_ has quit [Read error: Connection reset by peer]
guidosarducci has joined #openwrt-devel
goliath has joined #openwrt-devel
kistlin has quit [Quit: leaving]
<rsalvaterra>
stintel: Right. And mwlwifi too… :(
Gaspare has quit [Quit: Gaspare]
Battista has joined #openwrt-devel
<hurricos>
Habbie: any dice on mpc85xx re luajit?
minimal has joined #openwrt-devel
floof58 has joined #openwrt-devel
mzvd has quit [Remote host closed the connection]
mzvd has joined #openwrt-devel
<Habbie>
hurricos, no - if i knew when it broke, i might consider some bisecting
<Habbie>
hurricos, the only news i have right now is that i can reproduce the build failure locally :)
<Habbie>
hurricos, the good news is that it's only like 10 systems out of the entire openwrt toh
csharper2005 has quit [Remote host closed the connection]
mzvd has quit [Read error: Connection reset by peer]
csharper2005 has joined #openwrt-devel
mzvd has joined #openwrt-devel
ldir has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jow>
Ansuel: ... and in practice the implementation is dumb
<Ansuel>
This is from the commit description
<Ansuel>
The package was marked non-shared, since the arm CPUs may or may not have crypto extensions enabled based on licensing, and there's no run-time detection, unlike x86_64.
<Ansuel>
jow i would wait cotequeiroz feedback and then just revert it... another solution would be enabling it only for arm since it has been tested woth all the different arm64 target
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
Luke-Jr has joined #openwrt-devel
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
philipp64 has quit [Quit: philipp64]
<robimarko_>
I wouldnt revert it, its higly benefical for ARM targets
<robimarko_>
Maybe just disable it on x86
<mrnuke_>
Ansuel, robimarko_: for the ipq807x branch. Is there any chance we can store the ipq-wifi firmware binaries somewhere other than the main openwrt git tree?
<robimarko_>
mrnuke: Why?
<robimarko_>
Its exactly the same as IPQ40xx and other Wawe2 QCA cards
<mrnuke_>
At 128K a pop, that quickly adds up to megabytes of crap most people won't ever need
<robimarko_>
Well, in theory we can but I doubt its worth the trouble
<mrnuke_>
And my argument is it was a mistake to allow binaries for IPQ40xx in the first place
<robimarko_>
mrnuke_: But how would you handle WLAN without BDF blobs?
<robimarko_>
Performance is shit on the generic ones
<mrnuke_>
robimarko_: you store it in a separate place. be it a server, or a git repo that only gets cloned when you build ipq-wifi.
<mrnuke_>
or gets cloned with --depth=1
ekathva has joined #openwrt-devel
<robimarko_>
Well, I mean we can have a separate GIT repo for that
<robimarko_>
Not that I can do anything about it
<Ansuel>
mrnuke_ mhh propose this on the mailing list?
<Ansuel>
your idea is to create a separate git repo and use a ""standardized"" way to download the bin
<Ansuel>
instead of shipping them with openwrt and download all of them
<robimarko_>
Basically, just host it in a separate repo and git clone it
<robimarko_>
Minimal changes
<mrnuke_>
That's a perfectly valid solution, yes!
<Ansuel>
move it to another repo won't solve anything as you would download all the junk everytime
<robimarko_>
Only if you are using ipq-wifi package
<mrnuke_>
It will if I don't build ipq807x stuff
<robimarko_>
Currently you clone them anyway as its part of the main repo
<Ansuel>
i mean considering they won't ever change IMHO just download them directly instead of git clone
<robimarko_>
That would just complicate it
* enyc
meeps... friend here having fun with 22.03-rc4 on WRT3200ACM (using 2 radios, no kmod-mwiflex-sido) ... believes that there is a bug in wifi mac addresses in config, we think, as folow:-
<robimarko_>
As you have to add download step for every one
<Ansuel>
but now that i think about if maybe keep some kind of versioning is needed if they will change
<mrnuke_>
"they won't ever change " -- famous last words :p
<enyc>
- Create a wireless access point on one of the radios. - Create a second wireless access point on the same radio.
<robimarko_>
And they change, it wouldnt be the first time
<enyc>
The first AP gets a `macaddr` line, but the second does not. On the WRT3200ACM at least, this results in the wireless just not coming up at all. The solution is to remove the `macaddr` line from the first AP.
<enyc>
^^ Any $devs recognize this sort of shennaningans in 22.03 at the moment?
<Ansuel>
ok so clone --depth 1 should be enough but again that's something to discuss on the mailing list
<Ansuel>
to decide how to handle it (openwrt hosted repo?)
* mrnuke_
is afraid of mailing lists
<Ansuel>
at worst they will just answer with the scary NAK
<Ansuel>
(also about it I hate the menuconfig mess but no idea if that can be fixed)
Battista has quit [Read error: Connection reset by peer]
<mrnuke_>
What's the menuconfig mess?
Battista has joined #openwrt-devel
Battista has quit [Read error: Connection reset by peer]
minimal has quit [Quit: Leaving]
<Ansuel>
check the state of board file override with menuconfig
mzvd has joined #openwrt-devel
Gaspare has quit [Quit: Gaspare]
Gaspare has joined #openwrt-devel
<robimarko_>
That cannot be better
mzvd has quit [Read error: Connection reset by peer]
<robimarko_>
As you have to make a package for every board
* mrnuke_
learned today that there's a thing called "board file override"
lmore377 has joined #openwrt-devel
<Ansuel>
robimarko_ i wonder why we don't convert it to a single package and install the board based on a selectable config?
<Ansuel>
i mean every other package conflicts with the other soo
<pkgadd>
e.g. on the turris omnia, the wireless cards are replaceable
<pkgadd>
qca9980 by default
<robimarko_>
Ansuel: How would that work
<robimarko_>
You cant select a package config option per device
floof58 has quit [Remote host closed the connection]
<robimarko_>
That is why a package is created so it can be pulled in as the default device package
<pkgadd>
it wouldn't, as all devices are built in one go -different packages, yes - the same package with different content, no
<Ansuel>
you are right... but there must be a way to better handle that instead of the current solution
floof58 has joined #openwrt-devel
<mrnuke_>
Ansuel, robimarko_are you talking about the way ipq-wifi- packages are all conflicting?
<nbd>
rotanid: ping
<nbd>
rotanid: regarding the mesh failure supposedly caused by 33df033b73365487c5bb5a58b77aed04d4ca6ac1 - how did you reproduce the issue?
<nbd>
i can't see how this patch could cause mesh failures, and i can't reproduce the issue myself
Battista has joined #openwrt-devel
floof58 has quit [Remote host closed the connection]
floof58 has joined #openwrt-devel
<mrkiko>
nbd: hi! Did you see my previous messages?
<mrkiko>
nbd: didn't wont to bother, just wondering if they've been lost in the flow
<nbd>
just found it in my log
<nbd>
it's not a known issue
<mrkiko>
nbd: thanks, sorry ...
<nbd>
which version did you reproduce this on?
<mrkiko>
openwrt master, latest mt76 as present ion openwrt's Makefile
<nbd>
you mean 2022-06-02, or the update i pushed today?
<mrkiko>
nbd: oh, didn't know about the updateyou pushed today :D so no, without the today's update
<nbd>
no immediate need to update for mt7622
<nbd>
can you please restart the device and run echo 1 > /sys/kernel/debug/ieee80211/phy0/mt76/fw_debug before connecting the clients?
<nbd>
and see if it prints any messages to the kernel log before it hangs
<mrkiko>
nbd: thanks for the hint; the symptoms I see are that the iPhone gets deassociated and does not reconnect until I "activate" it somehow. But most importantly the mt7622 WMAC kind hangs, and an ifdown/ifup is sufficient to recovery and in the dmesg I can see the messages I pointed out in the ix.io link
<mrkiko>
Ok, I will do so. Maybe I'll do it with the update to be sure or may I lave it alone ?
<nbd>
shouldn't matter if you update or not
<mrkiko>
nbd: thanks. That's fine. Will update you with what I find out then
<nbd>
when you want to test some new stuff, please also test with the airtime fairness change in my staging tree
<nbd>
i'm trying to get feedback on that to see if it improves latency
<mrkiko>
nbd: thanks!
<mrkiko>
nbd: should I consider it ok having messages terminating the the word "impossible"
<mrkiko>
nbd: something strange is happening in my opinion
<hauke>
csharper2005: pong
<mrkiko>
nbd: 1 "impossible" message any second more or less, maybe it's completely normal but I don't know
<csharper2005>
hauke: I need your advice. I have a very old pending ramips PR first time reviewed by Adrian. Adrian last seen on gh many months ago. Now we have necessary upstreamed and and already backported mtd kernel patch and PR is ready. Whom can I ask to merge it?
<csharper2005>
or maybe send it to the ML?
Battista has quit [Read error: Connection reset by peer]
Battista has joined #openwrt-devel
danitool has joined #openwrt-devel
<nbd>
f00b4r0: i plan on updating it soon
shibboleth has quit [Quit: shibboleth]
<nbd>
f00b4r0: can you test the update commit for me if you have some time?
<mrkiko>
nbd: I will anyway wait until an hang happen; in the meantime I am getting the steady stream of "impossible" messages you can see in the paste
<f00b4r0>
nbd: sure, I'll give it a shot tomorrow
<hauke>
csharper2005: currently many PRs are not handled
<rotanid>
nbd: well, the devices run Gluon framework based on openwrt 22.03 branch and everyone can reproduce it by just booting and not having mesh connections, if you wait a few hours, they start to work though. we only reverted your patch and it works fine, so whatever your patch does, it is breaking meshing for us ;) wasn't only me, i was just the first one noticing it
<rotanid>
not sure what would be necessary to test it with plain OpenWrt, maybe copy/paste the 11s interface section or something like this?
<rotanid>
and i'm not even 100% sure if only mesh is affected, can't remember now if i tested a simple client<->AP connection...
<cmonroe_>
mrkiko: regarding the mt7622 wmac log above, were your clients still working ok at that time? i'm debugging an issue right now where ~30mins after the pkt number counter reaches 255 TX queue 2 hangs and most all client traffic (including new authentications) stops. I can clear it by triggering a scan on the phy which seems to be triggering a reset in the wmac firmware.
<csharper2005>
hauke: I noticed this too. It will be great if 400+ users get the official firmware. What can you recommend from your experience?
<cmonroe_>
when it hangs if you check /sys/kernel/debug/ieee80211/phy1/mt76/xmit-queues , Q2 will have 500+ items hw-queued and head/tail pointers will be off by 2.
<mrkiko>
cmonroe_: thanks for the hint! Yes, they are still working right now
<mrkiko>
cmonroe_: if I can I'll check it
<mrkiko>
cmonroe_: well - report it, sorry
<mrkiko>
cmonroe_: BTW, are you using Apple devices?
<cmonroe_>
ok. i suppose worth checking if xmit-queues is stuck and if a scan clears the issue next time should give an idea if it's an identical problem.
<cmonroe_>
yup! i don't see the "impossible" messages until i associate an apple device and then allow it to fall asleep (e.g. turn iphone screen off and set it on my desk for 30 sec). then they start. after that the pkt number counter increases each time a device re-associates until i hit 255 then shortly after Q2 locks up.
<mrkiko>
cmonroe_: ok, can't tell for sure but I guess we havethe same problem
<mrkiko>
cmonroe_: will I find you in IRC stably?
<cmonroe_>
mrkiko: yea, i typically have it open.
<mrkiko>
cmonroe_: wait a moment, trying to reproducethe issue right now
<cmonroe_>
mrkiko: it usually takes me quite a while to reproduce it (a few days).. have you found a quick way to make it happen?
<mrkiko>
cmonroe_: was thining I could do it via control center wi-fi tolling but apparently not
<mrkiko>
cmonroe_: does it increase when deassoc/assoc happens or should I wait for the iPhone to fall asleep and deassociate that way?
bluew has joined #openwrt-devel
<mrkiko>
cmonroe_: ok, found a way to do it
<cmonroe_>
mrkiko: once you see the first "impossible" message i think the count will increase on any dis/assoc
<mrkiko>
cmonroe_: still slow, but ... disabling and re-enabling wi-fi from settings does the trick
<cmonroe_>
mrkiko: once you hit 255 i think the queue lockup almost always happens for me about 30-60 min later (regardless of clients coming/going)
mzvd has joined #openwrt-devel
<mrkiko>
cmonroe_: eh, with a jailbroken iphone you could fully automate this but... you know, hard thing
<mrkiko>
cmonroe_: ok, will let you know
mzvd has quit [Read error: Connection reset by peer]
<cmonroe_>
mrkiko: my macbook triggers the count to go up as well.. not sure about other devices.
<mrkiko>
cmonroe_: me neither. BTW, I started from 15, now I am at 31 :D
<mrkiko>
cmonroe_: but probably playing this way with the iPhone isn't a good thing hardware-wise :D
<mrkiko>
cmonroe_: RT3200 or E8450 as well ? Or mt7621 based device?
<mrkiko>
cmonroe_: and - does this happen even with 5 GHZ interface?
<cmonroe_>
mrkiko: MT7622 wmac 2.4G + MT7615 5G. i've only run into this problem on the 2.4G wmac.. never on MT7615 or MT7915.
<cmonroe_>
mrkiko: so the E8450 5G interface should not have this issue.
<mrkiko>
cmonroe_: agree
ekathva has quit [Remote host closed the connection]
<mrkiko>
cmonroe_: ok, tried with an USB dongle
robimarko_ has quit [Quit: Leaving]
<mrkiko>
cmonroe_: but it doesn't trigger it... so the iPhone is able to do it but the dongle is not
<cmonroe_>
mrkiko: it must be something apple devices trigger, interesting
<mrkiko>
cmonroe_: yes, or maybe broadcom related? Since as far as I can tell most Apple devices use brcm wi-fi chipset
<mrkiko>
cmonroe_: however, if you want you may enable / disable wifi from the mac shell I guess. But even so, don't know if it's healty :D
<cmonroe_>
mrkiko: ah yes, good point.
<mrkiko>
cmonroe_: or maybe it's not relevant but just boring :D
<jow>
Mangix: if only it would get upstreamed instead of being turned into a turris usp
<Ansuel>
jow yhea sad....
<jow>
I mean we know all these problems, we just don't have the resources to improve it
<mangix>
jow: that was a proff of concept
<mangix>
no code was written
<jow>
Mangix: ah okay. So "I figured what your problem is, you just need to do it better" kind of presentation :)
<Ansuel>
well the save apply stuff is a good suggestion
<mangix>
That should be simple enough to do
<Ansuel>
but i guess that was part of a bigger topic related to notification system
<Ansuel>
but yhea the stash part is very simple to do... really just add a dummy 1 sec notification that config has been saved
<Ansuel>
aka ui.addNotification :D it's that simple
<Ansuel>
also we already have in the code things to specify button role... problem is time to develop a good skin
<jow>
as they noted it's not about skinning, that's what we've done for 14 years
<jow>
you need a complete ux concept, workflows etc, then implement those
<jow>
and I'm afraid you'll also need diverging views/logic for mobile and desktop, there's just so much you can do to mangle/hide content with CSS
<Ansuel>
they ended with "we will help the community if luci will like our help" MHHHHHHHHH
<jow>
they could start with PRs implementing the screens in the video, they do look fine
<Ansuel>
let me check if I have minified luci
* mangix
looks at luci git
<Ansuel>
not minified
<Ansuel>
i'm curious how mu ch it will take to add the stashed thing
<jow>
that flash banner?
* jow
only ksimmed through the video without sound, so I can only guess what has been said
<Ansuel>
one of the complain was that some action in luci doesn't give user feedback... example the save button when cliecked doesn't give any banned so the user assume it worked but he doesn't know
<mangix>
just installed luci-app-material. looks quite ugly. It looks like it should be using a different font.
<jow>
Ansuel: well the form flashes :D
<jow>
but sure, slapping an auto-dismiss banner there is trivial
<Ansuel>
anyway a good idea would be adding a css class like "modified"
<Ansuel>
that ass a border so the user can see the modied option in the current view
<Ansuel>
that add*
<jow>
it's surprisingly complex
<Ansuel>
mh really?
<jow>
e.g. is altering the content and altering it back "modified" ?
<mrkiko>
cmonroe_: hang successful
<jow>
it'll not result in a uci change but might be visually highlighted as changed, adding to confusion instead of clarifying state
<Ansuel>
jow can't we just parse the pending modification and check if some of them are present in the view (and add the modified css?)
<cmonroe_>
mrkiko: nice! does xmit-queues report Q2 being stuck?
<jow>
Ansuel: no, you can't reverse-map uci options to form fields reliably
<jow>
sometimes multiple form fields result in one uci option, sometimes fields are virtual and depmndant on the state of others
<jow>
sometimes interacting with a widget might transform the underlying value syntactically but not semantically (e.g. turning space separated values into a uci list)
<jow>
lot's of corner cases
<jow>
but sure, for hand-designed, mobile optimized forms consisting of one slider, two checkboxes nad an input field it is easy to do
<jow>
which brings me back to redefining the netire ux concept
<jow>
so far luci attmepted to expose any possible uci option to the user and somewhat match the dependencies among those and get along with potential under-the-hood manual config changes
<jow>
you could take a radically different course and simply implement workflows "make a guest network", "provide dual band ssid", "carve out one switch port for iptv"
<jow>
etc.
<cmonroe_>
mrkiko: yup, identical issue then. i can send you a scan command that i think should clear the issue if you want to try it. it's not a fix but can be a workaround until we find a fix.
<mrkiko>
cmonroe_: but no particularly interesting messages from firmware
<jow>
then simply rewrite configs as needed, disregarding preeexisting (out of gui) settings
<jow>
that'd allow for a missively simplified ui
<jow>
*massively
<cmonroe_>
mrkiko: right, i didn't see anything interesting when the hang actually occurs. so far only noticed that pkt number=255 is a prerequisite.
<mrkiko>
cmonroe_: I was thinking an "iw dev wlan0 scan" would fix it
<cmonroe_>
mrkiko: yes, that will. i found a less intrusive on-channel scan command that may resolve it as well.
<cmonroe_>
mrkiko: try - iw dev wlan1 scan trigger freq $(iw dev wlan1 info | grep channel | awk '{print $9}') flush
<jow>
Ansuel: you might want to take a look at the pending luci-mod-simple PR
<cmonroe_>
mrkiko: replace wlan1 with your radio. it just gets the frequency from iw dev output and scans on the current frequency only. the firmware should report a hang and then recover.
<jow>
Ansuel: maybe a viable strategy would be expanding that instead of focussing on making the full luci mobile friendly
<jow>
Ansuel: together with a theme optimized for that simple ui
<jow>
need to hit the bed, bbl
<Ansuel>
gn
<mrkiko>
nbd: cmonroe_: can reproduce reliably the hang, disassociating/reassociating iPhones 255 times causes the hang after some minutes. No interesting messages from firmware, logread shows dhcp work, handshakes work, no traffic
<mrkiko>
cmonroe_: can you replace this with the explicit 11 channel' I have no copy paste easily available
<mrkiko>
nbd: cmonroe_: my first dmesg before the scan command is at http://ix.io/40CO
<cmonroe_>
mrkiko: replace the inline bash with the current frequency, e.g. 2437
Tapper has quit [Ping timeout: 480 seconds]
<mrkiko>
ok
<mrkiko>
cmonroe_: prints nothng but neither hangs definitely
<mrkiko>
ok, but a normal scan seems to have did it
<mrkiko>
mgmt/bss.c:3105 crash
<cmonroe_>
mrkiko: identical issue as me. mediatek is looking into it but so far no fix yet. i wrote a little cron job to check queues and scan on hang if you want it.
<mrkiko>
cmonroe_: nbd: and here the firmware hang triggered by "iw dev wlan0 scan" in my case - http://ix.io/40CQ
<mrkiko>
cmonroe_: thanks!
<mrkiko>
cmonroe_: so they know about the issue?
<cmonroe_>
mrkiko: yes.
<mrkiko>
cmonroe_: so changes are we will have to wait for a new firmware rather than for an mt76 update, or both
<cmonroe_>
mrkiko: that's my guess but nbd would certainly know better than me
Tapper has joined #openwrt-devel
torv__ has quit [Ping timeout: 480 seconds]
<rotanid>
nbd: tested it now, AP/STA connection works 33df033b73365487c5bb5a58b77aed04d4ca6ac1 while 802.11s doesn't.