<f00b4r0>
blocktrron: I'm not sure. I upgraded (remotely) from 18.06 to 19.07, that broke the config (due to changes in usbmuxd) so I got the router to me, fixed the config then dnsmasq started acting up, not delivering leases on br-lan. I "fixed" that by ticking "force even if other dhcp detected",
Vinay is now known as vrpatil
<f00b4r0>
but I didn't perform a final cold boot test after that, which turns out to be a mistake because now that the router is back at its location, it's not connecting. The phone (iPhone) shows a connection being shared but the router doesn't get link it seems and the small watchdog script (taken from wiki) keeps resetting the iface (seen on the phone cycling state)
<f00b4r0>
iphone running iOS 13 I should mention.
<Borromini>
wasn't there an issue with iOS 13 tethering a while ago? one that got fixed (at least in master)
<rsalvaterra>
Kernel guys (and aparcar[m]), one question: we're on a zstd-all-the-things (or as many as possible) rampage, aren't we? Or have I misinterpreted?
<Borromini>
f00b4r0: sensing hardware ;)
<f00b4r0>
:)
mattsm has quit [Remote host closed the connection]
mattsm has joined #openwrt-devel
<aparcar[m]>
rsalvaterra: what is zstd again?
<rsalvaterra>
aparcar[m]: The compression algorithm? :P
<Borromini>
aparcar[m]: facebook made it ;)
<aparcar[m]>
Sorry just kidding. What's your plan?
<rsalvaterra>
Well, sometimes Facebook does one or two nice things… :D
<rsalvaterra>
I backported my upstream patch to select the default compression algorithm for zram, breaking it's current strict dependency on lzo. This means it can default to zstd now.
<aparcar[m]>
We're mostly on a "let's have a release soon" rampage so if you introduce sone ground breaking zstd changes please wait a bit
<rsalvaterra>
And lzo can be completely deselected.
<rsalvaterra>
Oh. I wager kernel patches aren't on the menu, then… :P
<Borromini>
:P
<rsalvaterra>
And this probably warrants some LuCI zram section changes, but I don't do LuCI…
<aparcar[m]>
rsalvaterra: some people do. I'm happy to review patches and also we got a experimental flag which can be used to disable such things for a release. However if you can please test and fix DSA 🙄
Tapper has joined #openwrt-devel
<rsalvaterra>
DSA? It's working fine here. Or do you mean in LuCI?
dedeckeh has joined #openwrt-devel
<aparcar[m]>
rsalvaterra: good question. I need to run now but from what I know mostly DSA is missing
<Borromini>
nbd: git bisect pointed to the latest commit included in the 2021-01-27 bump, but with or without that, i am seeing no issues (pushed tens of gigabytes over the radio). I am seeing very bad performance though with latest master (which has two mac80211 fixes). Could the mac80211 patches play a role here? radio hasn't died yet but bitrate is all over the place (between 300-ish to 0)
<Borromini>
latest openwrt master, that is.
feriman has joined #openwrt-devel
rsalvaterra1 has joined #openwrt-devel
nitroshift has quit [Remote host closed the connection]
nitroshift has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 272 seconds]
ivanich has quit [Quit: Konversation terminated!]
<nbd>
Borromini: what was the openwrt version that you were seeing no issues with (with the 2021-01-27 bump)?
<Borromini>
nbd: cbedb5de75
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
<nbd>
Borromini: can you test if reverting openwrt commit 84fa59b5a80f8522239755d75d7ae51855c47fd2 makes a difference?
<Borromini>
nbd: will do.
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
<Borromini>
nbd: sorry for the noise about the bitrates. wife was sitting in the room where the AP is and that seemed to cause a lot of interference (a floor up)
<Borromini>
i'll keep an eye on the message 73 timeout but so far it hasn't popped up yet.
<Borromini>
well nevermind, i was on the wrong AP it seems. will revert 84fa59b5a80f8522239755d75d7ae51855c47fd2 and report back
<stintel>
russell--: different category, that's more of an RPi clone
<stintel>
the unmatched is kind of a desktop board, and I happen to have an empty mini ITX case lying around, and I'd like to play with RISC-V and not be frustrated by it being too slow for really playing around
<stintel>
and since restaurants and malls etc are closed, travel is restricted, ...
<stintel>
one can only game so much :P:
noltari_ has quit [Quit: Bye ~ Happy Hacking!]
<stintel>
although I'm trying to reach Battle Pass lvl 100 this season on CoD Black Ops Cold War
noltari has joined #openwrt-devel
<stintel>
but I might order a beaglev or alternative too at some point
<stintel>
if you come across a Pi Zero W clone that is RISC-V based, please let me know :)
<svanheule[m]>
stintel: obviously the next Raspberry Pi will the the Pi V ;-)
<stintel>
:P
<karlp>
Borromini: "too bad about gigabit ether" means what? you wanted 10G or what?
<stintel>
I did :P
<stintel>
but doesn't make sense on this kind of board
<Borromini>
:P
<Borromini>
karlp: 2,5Gb would be nice
<Borromini>
stintel: why not? (just curious, not familiar with it)
<karlp>
si 2.5G really that common to be worthwhile? is it really going to be prevalent? it seems like such a halfway state?
<Borromini>
seems like 2,5 is the next affordable thing in the years to come
<stintel>
yep, and compatible with multigigabit devices
<stintel>
so you can have multigbe switch with "expensive" 10Gbe fileserver, cheaper 2.5GbE clients
FooDeas has joined #openwrt-devel
<Borromini>
lots of high and mid-end x86 boards already come with 2,5 Gbit NICs it seems
<Borromini>
stintel: you gonna turn yours into a file server?
<grift>
there is probably no nice way to say this but instead of trying to reach level 100 in CoD you could also offer you help to others who could use help, maybe then one wouldnt have to critizise others for reluctantly prioritizing due to lack of time and resources
dorf has joined #openwrt-devel
feriman has quit [Quit: WeeChat 3.0]
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
<stintel>
grift: I spend enough time on my day job, all time and effort spent on open source is voluntary, doesn't pay any bills, etc
dedeckeh has joined #openwrt-devel
feriman has joined #openwrt-devel
caravel has quit [Quit: Konversation terminated!]
<karlp>
grift: correct, there's no nice way to have tried saying that :)
<rsalvaterra>
grift: For a lot of us, OpenWrt is a (useful) hobby which we do for fun. Speaking for myself, I already have $dayjob. If this starts to smell like work to me, I'll fuck right off. :P
<grift>
yes and how would you like it if i would critize your work becaus of that?
<grift>
because thats exactly my point
<grift>
what i do is also my hobby but i get blamed that i dont do the work for others as well
<rsalvaterra>
I don't mind being blamed if things break for changes *I* made voluntarily, and I have the responsibility to fix them.
finsternis has joined #openwrt-devel
<rsalvaterra>
That's just common sense, I believe.
<grift>
i guess so. i guess next time ill shrug it off with: "ok thats my bad, i will address it when i get to it"
<grift>
some things arent fixed that easily
<rsalvaterra>
Well, if I break something, I try to fix it ASAP, of course.
<grift>
well thats what i said "when i get to it"
<rsalvaterra>
I can't speak for everybody else, but that works just fine for me. :)
<grift>
so i guess that means that when you add that zram lzo functionality you will also address the luci integration
<grift>
because we might not have the luxury to say "i dont do luci"
<dorf>
if you're dealing with a sense of entitlement from user x, tell user x you accept donations for accelerated development. or patches :)
<ynezz>
grift: BTW what's the context? I don't follow here...
<grift>
well obivously my selinux policy changes are very intrusive and fragile so i have to prioritize my work
<grift>
and so one afternoon i mentioned the i focus first on the stuff i use
<grift>
but people interpretted as saying that i dont care for users (or something)
PtitGNU has quit [Remote host closed the connection]
<ynezz>
it just needs time, you'll learn to ignore it :)
<grift>
but i was just saying "well because i cant do it all in reasonable time alone anyway i will focus on my own use case first
xback has joined #openwrt-devel
<grift>
i almost did ignore it
<grift>
slip of the tongue i suppose
<ynezz>
AFAIK it's optional, right?
xback has quit [Client Quit]
<grift>
sure
nitroshift has quit [Quit: Gone that way --->]
xback has joined #openwrt-devel
PtitGNU has joined #openwrt-devel
<stintel>
you were calling very common stuff "exotic", insinuating it's not worth your time, and this is my main problem. if something is in openwrt.git, and selectable via menuconfig, it's not exotic, it's supported, and should not be ignored
<grift>
stintel: patches accepted (i have to prioritize, its a huge task, i do it when i get to it (if i dont get any help before that)
<stintel>
grift: sure, just keep in mind that openwrt is very customizable, it's actually one of the reasons I'm using it over something like dd-wrt, and I'm sure many people are using it for the same reason. so if someone has a problem with e.g. libmbedtls, which is in openwrt.git but not enabled by default, while testing your selinux policy stuff, then at least don't call it exotic
<grift>
stintel, the policy is also customizable ...
<grift>
ok i wont call it exotic anymore promise
<grift>
how about "optional" sound better?
<stintel>
yes :)
<grift>
i was just saying the first priority is the stuff that is a default and is not really considered optional
<grift>
eventually obivously i would love to address all, but thats not going to happen any time soon especially if no one else cares
<stintel>
I might have misread that, so maybe just a miscommunication
<grift>
probably also in part my fault
<grift>
i might have been trying to incentivise other to get involved too much
<stintel>
communication is hard sometimes, we have similar issues on company slack :)
<stintel>
if I ever manage to finish all my other WIP I might spin an image with SELinux enabled for one of my test devices
<grift>
that would be appreciated, thanks
<stintel>
but my stuff is so customized that it's going to break almost everything, and right now motivation for doing anything is pretty low
<grift>
if you dont use luci then things might just surprise you
<grift>
luci integration is the hardest part
<stintel>
did I suggest to have something like $packagename-selinux for per-package policy? might make more sense than using a single policy package
<stintel>
I think I did but I don't remember
<grift>
yes but that is not possible because the policy is loaded from squashfs
<grift>
ie the lower layer
<stintel>
so it wouldn't work for anything installed via opkg install ..
<grift>
so if you would do that and you would reboot then your $packagenaame-selinux would be ignored
<grift>
in theory everyhing works with opkg, you just cannot alter the policy at runtime
Tapper has quit [Ping timeout: 240 seconds]
<grift>
its probably more understandable if you give it a whirl when you find a dead moment
<stintel>
I honestly considered it, on my spare ERL
<stintel>
but I probably got distracted by something random on my todo list
<stintel>
or random breakage of something in my infra
luke-jr has quit [Remote host closed the connection]
<stintel>
anyway, back to powershell for a bit :P
<stintel>
before anyone asks: no, it's *not* for fun ;)
luke-jr has joined #openwrt-devel
<grift>
for the record i dont mind having fun, "all work and no play makes jack dull"
<grift>
i was just a bit touched by your critisism
<stintel>
well let's consider it sorted, no hard feelings
<grift>
alright
<FooDeas>
Simple question: Should I just close and reopen pull requests so they will get attention after months?
voxadam has quit [Ping timeout: 260 seconds]
<stintel>
FooDeas: ping @maintainer ?
Tapper has joined #openwrt-devel
<dorf>
are we back to why luci renders all the markup with js again? :)
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
Borromini has quit [Ping timeout: 246 seconds]
<dorf>
jow: give us some static html to play with!
decke has quit [Quit: Leaving.]
luke-jr has quit [Remote host closed the connection]
luke-jr has joined #openwrt-devel
<FooDeas>
stintel: I don't know who exactly may be maintaining this module in OpenWrt.
<stintel>
FooDeas: is it openwrt.git or one of the feeds ?
<FooDeas>
stintel: openwrt.git
<stintel>
I automatically expected a feed because github PR, forgot there are also github PRs for openwrt.git
<stintel>
FooDeas: well you pinged one of the team members already (adschm), maybe you can ping other team members that previously commented, we don't have target maintainers anymore so there's no maintainer to ping, one other option is to git send-email --to openwrt-devel@lists.openwrt.org, it gets more love than github afaik
dedeckeh has joined #openwrt-devel
<FooDeas>
stintel: Thank you very much for your assessment! Have a nice evening!
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
vrpatil has quit [Quit: Ping timeout (120 seconds)]
<rsalvaterra>
nbd: cautiously optimistic news, I'm able to access my dad's laptop on the 5 GHz band (MT7615).
<rsalvaterra>
It's still not obvious to me which commit might have fixed the broadcast issue.
<nbd>
interesting
<nbd>
one candidate is 84fa59b5a80f8522239755d75d7ae51855c47fd2
<nbd>
it fixes a bug where mac80211 was doing rate table updates on stations that had not been uploaded to the driver yet
<rsalvaterra>
I thought you might say that, and I was already looking at it. ;)
<nbd>
this bug specifically affects 7615 and not the other chips
<nbd>
earlier chips upload the station before assoc and newer chips don't use software rate control
<rsalvaterra>
Software rate control. You mean minstrel_ht, right?
<nbd>
yes
<nbd>
i found it while developing some code to allow user space to control minstrel
<rsalvaterra>
I see. So, starting with the 79xx series, rate control is done in hardware, right?
<rsalvaterra>
Anyway, I need to test this more thoroughly, since I have the feeling that sometimes I was be able to connect, only to lose connection after several hours (due to ARP ageing, possibly?)…
<Borromini>
nbd: i have hammered the mt7613be radio, it seems the message timeout issue only pops up when there's no clients connected). so i'm redoing the bisect.
danitool has joined #openwrt-devel
muhaha has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 272 seconds]
dedeckeh has joined #openwrt-devel
opal has quit [Remote host closed the connection]
opal has joined #openwrt-devel
linzst_ has joined #openwrt-devel
linzst has quit [Ping timeout: 240 seconds]
Borromini has quit [Ping timeout: 240 seconds]
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 264 seconds]
ivanich has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 240 seconds]
Acinonyx has joined #openwrt-devel
Borromini has joined #openwrt-devel
dorf has joined #openwrt-devel
Strykar has quit [Quit: /quit]
Strykar has joined #openwrt-devel
dedeckeh has quit [Ping timeout: 248 seconds]
linzst_ has quit [Quit: Leaving]
<Hauke>
ynezz: thanks for writing the advisory
shibboleth has joined #openwrt-devel
zkrx has quit [Ping timeout: 246 seconds]
<grift>
seconded
zkrx has joined #openwrt-devel
ashkan has joined #openwrt-devel
<Hauke>
nbd: I am having problems with my iwl8265 to connect to my MT7603E/MT76x2E since January, the iwl8265 needs pretty long to connect and sometimes it looses the conenction and then it needs abour 5 minutes to connect again. I didn't had this problem with OpenWrt from 5. Dezemebr, but have it at least in 96017a60138bdf97d2f1f7e7b519b4ad6ff13b88 from mid of January. Is this a known problem or should I try
<Hauke>
to bisect it?
ivanich_ has joined #openwrt-devel
<Hauke>
MT7603E/MT76x2E is inside a Xiaomi Mi Router 3G and iwl8265 inside a T480
<Hauke>
this is OpenWrt master + debian stable (kernel 4.19)
<Hauke>
scanning on iwl8265 also does not see my wifi
ivanich has quit [Read error: Connection reset by peer]
ivanich_ has quit [Read error: Connection reset by peer]
kontaxis has quit [Remote host closed the connection]
kontaxis has joined #openwrt-devel
black_ant has quit [Ping timeout: 258 seconds]
<blocktrron>
Hauke: I've had similar issues (8265 / T470). Connecting to MFP networks would often time out, Some 2.4 GHz networks not visible in search.
<blocktrron>
However, this also occured with APs running vendor firmware (AVM / Aruba).
<pkgadd>
intel ax200 is also far away from perfection (current stable kernels)
<blocktrron>
These issues were not there with a 7265 / AX200, so i went along there. Not to say that it might not be mt76 related, just sharing my experiences there
<blocktrron>
pkgadd: try an AX210 where bluetooth disappears from the USB bus as soon as iwlwifi comes up :P
<Hauke>
all my clinets are now on the 2.4GHz Wifi which is strange
* Borromini
has an 8260AC and eternal issues with BT on Linux but not so much with WiFi
<pkgadd>
blocktrron: hehe, actually I've been looking for ax210 - because of 6 GHz support, but my biggest worry in that regard would be overzealous regdom settings rendering that feature useless
<Hauke>
I think the 5GHz is borken, I will have a look in the next days
<Hauke>
pkgadd: Is 6Ghz already allowed in the EU?
<Hauke>
I think the FCC approved it some time ago for the US and I am sure it will also be approved by the EU soon
<blocktrron>
Hauke: i would stay away from now, as it is not even capable of HE in it's current state
<Hauke>
I thought 6GHz wifi should be HE only
<blocktrron>
I have the second one I've ordered from china still around, if you are interested i can send it to sou for the amount I've got it from aliexpress
<blocktrron>
It only does VHT on 5 GHz
<Hauke>
what second one?
<blocktrron>
Ordered two (for both notebooks) but only installed one into my spare one, discovered it's current state and stayed away for my main machine
<Hauke>
blocktrron: no I do not really need a ax210
<Hauke>
I do not have any other 6GHz devices
<blocktrron>
That's what I was thinking to myself after using one for 5 minutes :P
<pkgadd>
Hauke: iirc, it should come available in summer (I'm not in a hurry to buy an ax210 (actually with desktop-PCIe adapter), but given the sources of these devices, I worry about region code clashes nevertheless)
<Hauke>
often there are engineering samples sold on ebay and aliexpress, they will work as long as Intel and their customers also use engineering samples, but then they remove support for them from the drivers later
<Hauke>
some people complained about this for older generations
<pkgadd>
yep, that as well
rmilecki has quit [Ping timeout: 256 seconds]
<zorun>
ynezz: thanks!
<zorun>
stintel: where did you buy the Unmatched?
<stintel>
zorun: mouser (pre-order)
<Hauke>
stintel: do you already have it?
<stintel>
Hauke: (pre-order) ;-)
<stintel>
ETA early march
<zorun>
oh ok, I thought it was more widely available already