<slh64>
Mangix: for ax210 you want the latest kernel you can get (I'm even wary about v5.15), when I started using it in january (then current stable mainline kernel on desktop linux) kernel/ firmware were not stable, sometime in march/ april it got better (it's fine on v5.18 and v5.19)
<slh64>
admittedly, my main woes were with 6 GHz (wasn't even available for ETSI before mid january and even then remained fragile until march/ april)
goliath has quit [Quit: SIGSEGV]
* stintel
should read backlog on ax210
<stintel>
I have 4 of them :P
<stintel>
waiting for pigtails before I can use them though (besides the one in my old xps13)
digitalcircuit has quit [Server closed connection]
digitalcircuit has joined #openwrt-devel
<\x>
ax210 ap mode in 6GHz coming?
<\x>
:D
<\x>
2.4 work always
<\x>
5ghz can now be done with lar-friendlyness patch from tildearrow
<\x>
hostapd patch
robimarko has joined #openwrt-devel
paper__ has quit [Server closed connection]
paper_ has joined #openwrt-devel
Misanthropos has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Misanthropos has joined #openwrt-devel
<slh64>
\x: it's in cliebt use only for me. 6 GHz doesn't need dfs though
<xback>
hauke: Thanks for the kmod-wwan package. It cleans mhi support nicely :y
goliath has joined #openwrt-devel
PaulFertser has quit [Server closed connection]
PaulFertser has joined #openwrt-devel
<stintel>
wew, first attempts at a CI pipeline with woodpecker ci (on codeberg) are not very confidence inspiring
mrnuke has quit [Ping timeout: 480 seconds]
<aparcar[m]>
ynezz: thanks for the list, looking at it labgrid seems to be the best. I'm wondering how it could be setup in a distributed setup, will do a bit more research
hauke has quit [Server closed connection]
hauke has joined #openwrt-devel
<stintel>
aparcar[m]: did you give codeberg CI a go alread ?
<aparcar[m]>
stintel: yes, however they don't allow self hosted runners
<aparcar[m]>
we'd need to run our own CI stack there...
<stintel>
did you happen to try matrix with when ?
<stintel>
it's completely ignoring my conditionals
<stintel>
so it's trying to run apt-get on centos and yum on debian :/
<aparcar[m]>
heh
<aparcar[m]>
no I didn't sorry
<aparcar[m]>
woodpecker right?
<aparcar[m]>
did you try to run your own instance of that?
<stintel>
no just ci.codeberg.org
Harm__ has quit [Server closed connection]
Harm__ has joined #openwrt-devel
<aparcar[m]>
you're working on it to add some openwrt feature or just of general interest?
<stintel>
I looked into running own woodpecker instance but it doesn't support kubernetes (it can be deployed on it though)
<stintel>
currently I'm trying to set up CI for vallumd
<stintel>
at some point I had Agolo CI with a local Gitea, but I don't want to maintain a public gitea and CI stuff :P
mrnuke has joined #openwrt-devel
<stintel>
so I'm trying to redo that on codeberg CI
owrt-snap-builds has quit [Server closed connection]
owrt-snap-builds has joined #openwrt-devel
<stintel>
hurricos: so I was cleaning up iptables and some other stuff from my m300 config earlier today, and I found that I had CONFIG_NO_STRIP... based the bsap3040 config on that one, explains why the images were so huge
<stintel>
from ~150MB to < 20MB :P
<\x>
<slh64> \x: it's in cliebt use only for me. 6 GHz doesn't need dfs though
<\x>
but isnt it still no-IR on 6GHz bands?
floof58 has quit [Ping timeout: 480 seconds]
<slh64>
can't check right now, I'm a few dozen km away from it
stintel has quit [Read error: Connection reset by peer]
stintel has joined #openwrt-devel
xdarklight has quit [Server closed connection]
xdarklight has joined #openwrt-devel
stintel has quit []
stintel has joined #openwrt-devel
larsc has quit [Server closed connection]
larsc has joined #openwrt-devel
wigyori has quit [Server closed connection]
wigyori has joined #openwrt-devel
zorun has quit [Server closed connection]
zorun has joined #openwrt-devel
trivalto has quit [Quit: Page closed]
DLange has quit [Server closed connection]
DLange has joined #openwrt-devel
* russell--
was just reading https://openwrt.org/toh/tp-link/eap225 and, sigh, found again the meme that /proc/mtd said anything valuable about flash layout ... it does not. usually the valuable information is reported in dmesg (e.g. dmesg | grep 0x)
danitool has joined #openwrt-devel
<russell-->
well, that's weird, i just flashed a meraki mr24 with a newish firmware (as of today) and i'm not seeing dhcp on the lan interface, uci says: dhcp.lan.dhcpv4='disabled'
StifflersMagic has quit [Server closed connection]
StifflersMagic has joined #openwrt-devel
* russell--
checking for interactions with my uci-defaults tweakings
<russell-->
nope, removed all my uci-defaults, still seeing dhcp.lan.dhcpv4='disabled'
<f00b4r0>
i understand the rationale for using dhcp on these devices (even though I may not like it), but I sure hope it doesn't mean that running failsafe requires a dhcp server :P
<f00b4r0>
I can't seem to find the answer in the base-files package
borek has joined #openwrt-devel
<russell-->
empricism++
<russell-->
empiricism, even
Misanthr- has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
floof58 has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
<stintel>
does anyone know what platform the U6-Enterprise-In-Wall is based on ?
schwicht has joined #openwrt-devel
rua has quit [Quit: Leaving.]
<takimata>
Mangix: oh, so you get the problem too? are you able to reproduce it, and maybe even capture it like jow suggested? because ever since I restarted the LAN interface on the AP yesterday, I ... just can't reproduce it anymore.
<takimata>
which is an additional level of heisenbugginess.
<jow>
takimata: maybe roaming plays a role?
<jow>
is the AP providing multiple SSIDs?
<robimarko>
stintel: Looks like FCC internal images are confidential until late november for SWX-U6EPIW
<takimata>
jow: it does, but my clients don't roam between SSIDs, they only use one or the other.
<takimata>
jow: my initial thought was that the AP has to run for a certain time, but that would not apply to the ppl who have the problem with the AP on the SSH server itself, they reboot all the time in between.
<stintel>
robimarko: would be nice to know if mtk or qca :)
<stintel>
but I guess we play the waiting gamwe
<robimarko>
I kind of bet on QCA
<robimarko>
All of the newer AX stuff was QCA
<takimata>
jow: I since restarted the AP, then restarted the apm821, and it still doesn't show the misbehaviour. I'm tempted to not just reboot the AP but actually to remove power from it.
schwicht_ has joined #openwrt-devel
schwicht has quit [Read error: Connection reset by peer]
srslypascal is now known as Guest342
srslypascal has joined #openwrt-devel
bluew has quit [Quit: Leaving]
Guest342 has quit [Ping timeout: 480 seconds]
mcbridematt has quit [Remote host closed the connection]
<takimata>
(I shrunk it down to "-e ether src <client-mac> or ether dst <client-mac>")
<takimata>
(since device itself is obviously the host always.)
<takimata>
also not using switch0 interface, the apm821 has no switch. :)
Guest349 has quit [Ping timeout: 480 seconds]
<takimata>
hope it is good data.
<jow>
br-lan
<jow>
I guess
<f00b4r0>
jow: another mt76 device. *sigh*
<jow>
f00b4r0: looks very broken atm
<f00b4r0>
(re issue #10435)
<jow>
we shouldn't release it like that
<f00b4r0>
i agree
<jow>
takimata: this was on br-lan?
<f00b4r0>
but the bug is definitely intricate. AFAICT current 5.15 is immune, but as you could see on the m-l, on the switch driver side, backports don't fix it
<jow>
takimata: dropbear only recnetly started to use this DSCP class
<takimata>
jow: haha, okay ... I have only a vague idea about what that means but I'm happy you know. :)
<jow>
takimata: that nfatables rle basically resets the DSCP class to 0 (none) in all outgoing packets
<hurricos>
oh hi!
<takimata>
jow: ah, okay.
<hurricos>
reading.
<jow>
*nftables rule
<takimata>
jow: so ... we found the reason? fixable?
<jow>
takimata: a clue rather
<hurricos>
\x: it can handle newer radios, not really relevant though. The processor is quite slow. If you want to swap cards go for an ap3825i / hiveap330 / bsap2030
<jow>
nbd: any idea why mt76 would fail to forward frames carrying a non-standard DSCP class?
<takimata>
jow: problem is, one probably can't fix this on MT76 side ... it seems to go way back, at least to 21.02, so possibly large install base.
<\x>
yeah hurricos i have got a little experience on adding a newer radio, i have added an ax radio to ipq4019, cpu not quite happy even when overclocked, its usable but not in its full potential
<takimata>
I mean it should be fixed probably, but that will not do any good for any older install.
<jow>
takimata: if DSCP really is the problem, then you could use similar nft rules to force the problem with other protos, e.g. http
<jow>
nft add rule inet fw4 changetos tcp sport 80 ip dscp set af21 counter
<nbd>
jow: what DSCP classes are affected?
<jow>
nbd: af21
<jow>
dropbear recdently begun using af21 for interactive sessions and apparently this triggers "SSH stalls" when an mt76 wifi is involved somewhere along the network path
<jow>
takimata: actually nft flush chain inet fw4 changetos; nft add rule inet fw4 changetos tcp sport 80 ip dscp set af21 counter
<takimata>
jow: hmm. LuCI/uhttpd still works though. is that previous rule setting it to 0 still?
<takimata>
ah.
<jow>
yeah, the old rule catched traffic before
<takimata>
and, yup, LuCI stopped working.
<jow>
issue the flush
<jow>
does it immediately staret working again?
<takimata>
yes.
<jow>
okay, so it's not about any stale offload entries otr the like
<jow>
it affects packets individually
<jow>
probably some kind of DSCP->WMM queue mapping stuff
<jow>
nbd would you agree?
<nbd>
AF21 should map to BE
<nbd>
but not the same TID as regular BE
<nbd>
tid 3 instead of 0
<nbd>
sw tx queueing is per tid, so maybe there is an issue there
<jow>
takimata: okay so we can generalize the problem; it is not SSH specific but affects any network connection using DSCP markings which map to certain queues in the mt76 wifi driver
FLD has quit [Server closed connection]
<jow>
takimata: could also affect stuff like voip clients, torrent clients, any piece of software that uses DSCP markings (by default or user uspplied)
FLD has joined #openwrt-devel
<jow>
and it only affects some DSCP classes, not all
valku has quit [Remote host closed the connection]
<takimata>
mh, I believe I understand.
<takimata>
so ... where do we go from here? make dropbear not use these markings?
<jow>
that would be a short term cludge
<dwfreed>
clients also set markings
<jow>
the nft rules above (or some variations of them) could be uses to mangle packets in a way that such "faulty" DSCP classes are not sent/forwarded
<jow>
but it will not be a complete fix
<takimata>
considering we can't really fix the mt76 install base out there.
<jow>
not sure of e.g. dropbear even has an option to alter the DSCP marking behaviour
<jow>
worst case is that we'd need to patch it
<takimata>
(e.g. mt76 on 21.02 is affected, possible even earlier ones.)
<hurricos>
jow: Would the default nft rules only apply if /etc/init.d/firewall is enabled?
<jow>
hurricos: yeah
<hurricos>
OK, got it. Ooh.
<hurricos>
That sounds like reason enough to patch, at least until a 21.02.4 release comes out, assumedly with backports for mt76 fixes
<hurricos>
"assumedly" because I don't know if we backport that far
<hurricos>
patch dropbear that is
<hurricos>
ssh is important :|
<takimata>
so can I help with anything yet? (insert ralph wiggum "I'm helping" meme here)
<jow>
I'm out of my league, this is something nbd has to look into
<jow>
or someone else deep enough into mac80211/mt76
<takimata>
brb, pesky work stuff.
minimal has joined #openwrt-devel
<hurricos>
I notice that when I have two AP VIFs on one PHY and assign dissasoc_low_ack differently on both of them, only the last one applies
<hurricos>
Or at least, I THINK that's the case. I'll pick this up tomorrow after the AP config has flushed, trying not to kick users.
<hurricos>
which suggests that all BSSes should have explicit configuration
<hurricos>
which OpenWrt doesn't do: the first VIF doesn't get a bss= entry
<hurricos>
or at least I don't see one in /tmp/run/hostapd-phy0.conf
clayface has quit [Server closed connection]
clayface has joined #openwrt-devel
schwicht_ has quit [Read error: Connection reset by peer]
schwicht has joined #openwrt-devel
schwicht has quit [Read error: Connection reset by peer]
schwicht has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
mkresin has quit [Server closed connection]
mkresin has joined #openwrt-devel
<\x>
jow: ethernet post status view is very nice, I miss this ever since DSA happened. but maybe can add naming feature? lets say lan1 have small box underneath can put like "myPC"
owrt-2102-builds has quit [Server closed connection]
<\x>
or maybe in the tooltip
owrt-2102-builds has joined #openwrt-devel
<\x>
this is very good, i no longer have to go to bridge vlan filtering to see port status
<stintel>
guess it doesn't like LTO and/or fortify-source
<stintel>
that also means something is broken in my attempt to add a config option to enable LTO globally: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=commitdiff;h=f871cd7a5c787a9d4222986f5d7c53a1251e293b
<aparcar[m]>
nice work, but looks like it's rejected?
<minimal>
not exactly
swegener has quit [Quit: leaving]
<minimal>
as I said udev is modular, you can drop in rules
swegener has joined #openwrt-devel
<minimal>
so I added support for symlinks for device mapper to mdev and was told that those links don't exist with udev - that's because they are provided by drop-in rules from the lvm2 package
<minimal>
so currently am trying to work out how to potentially implement drop-in rules for mdev
<minimal>
so I need to rewrite that MR to add some of the symlinks that base udev provides and then separately look at how to handle the rest
<stintel>
might be able to create a hotplug.d rule that creates those links maybe?
tohojo has quit [Server closed connection]
tohojo has joined #openwrt-devel
<aparcar[m]>
mhh I guess hotplug would be the openwrt flavor of this...
<minimal>
stintel: ah, so procd/hotplug.d is the openwrt equivalent of mdev then
<stintel>
yeah
hanetzer1 has joined #openwrt-devel
<stintel>
I actually did something like that for domoticz, iirc
<minimal>
aparcar[m]: for some of the by-* symlinks you'll see on a typical udev machine you'd need to have things like blkid and some other programs installed
<rsalvaterra>
aparcar[m]: I'll merge the nf_conntrack backport later this evening. :)
<aparcar[m]>
rsalvaterra: thanks!
<rsalvaterra>
Sorry for the absence, right now I'm on holidays in Algarve. ;)
<aparcar[m]>
stintel: do you know a way to manually trigger those hotplug events? seems a bit hard to debug
<aparcar[m]>
rsalvaterra: it's not holidays if we know where you are
<stintel>
holidays? what's that?
<aparcar[m]>
that's the spirit
<stintel>
I just travel and work
<stintel>
:P
<stintel>
aparcar[m]: sorry, don't know if that is possible, or how
<rsalvaterra>
stintel: That thing when you went to Greece(?). :P
<stintel>
rsalvaterra: oh, I was working there also
<stintel>
I bought a Dell 34" ultrawide to take with me when I'm traveling, combined with a ducky mechanical keyboard and roccat mouse, laptop suddenly becomes an almost-workstation
<rsalvaterra>
Connection has been rather iffy here too. I think I stabilised it, but it's been one heck of a jury-rig.
<stintel>
it works quite comfortably
<rsalvaterra>
Nice!
<stintel>
yeah I'm super happy with it
* rsalvaterra
has his mind set on an Apple silicon-based system, in the future…
<stintel>
and I'm working with UK, their 9:00 is my 11:00, so I can get up at 8:00 grab a coffee, drive to the kite station, kite for ~90 minutes, go back "home" and start work ;)
<aparcar[m]>
stintel: you can call udevtrigger
<aparcar[m]>
:dance:
<stintel>
\o/
<rsalvaterra>
Running Linux, of course.
<stintel>
parteeeeeeh
<aparcar[m]>
uh kiting...
<stintel>
something wrong with that? :P
<aparcar[m]>
no it's my next mission after having no more waves around me 🙂
<stintel>
ahhh
<stintel>
could also look into Wind Foiling
<stintel>
Wing* Foiling oops
<stintel>
and I heard the Canary Islands are quite good for kiting
<stintel>
that reminds me I should plan my next trip
<stintel>
I've been home for almost a week, high time ;)
<rsalvaterra>
aparcar[m]: Good luck getting rid of electromagnetic ones… xD
<stintel>
:D
<aparcar[m]>
rsalvaterra: can't surf those
<aparcar[m]>
so I got /sys//devices/pci0000:00/0000:00:04.0/vir
<aparcar[m]>
tio0/block/vda/vda1/, where is my uuid?
<rsalvaterra>
Are you sure? :P
hanetzer2 has joined #openwrt-devel
<stintel>
aparcar[m]: I suspect it is generated on some device property
hanetzer1 has quit [Ping timeout: 480 seconds]
<jow>
aparcar[m]: you need to obtain the uuid using tools like blkid
<aparcar[m]>
jow: no other way? I'd like to have that by default available on OpenWrt
<jow>
nope
<aparcar[m]>
sad.jpg
<jow>
placement and formatting of the uuid is filesystem specific
<aparcar[m]>
I see, no chance here
<jow>
so you need a tool understnading various filesystem / superblock / metadata formats
<stintel>
hmmm, I thought even unformatted disk has a uuid ?
<mangix>
takimata: yeah that bug is weird. only affects dropbear and not openssh
<mangix>
I have 0 idea why.
<takimata>
Mangix: we found out in the meantime.
<mangix>
oh?
<takimata>
scroll back about 7-8 hours today, it's the DSCP af21 marker dropbear sets since 2022.82, MT76 doesn't like it very much.
<mangix>
seems fishy. I don't get the issue with mt7915 DBDCV
<mangix>
*DBDC
romany0 has joined #openwrt-devel
<mangix>
but I do with my RT3200
<takimata>
I reproduced the issue when I set af21 on port 80 traffic through nft, suddenly http "stopped working".
<takimata>
(and by "I", I mean after getting instructions here)
<mangix>
takimata: one workaround when I was using my RT3200 was to ssh to a machine connected through ethernet and then connect to the router
<mangix>
DBDC and non DBDC use different firmwares
<takimata>
yup, did the same dance via my edge router.
<mangix>
this is with 5ghz, right?
<takimata>
nope, also happens on 2.4
<takimata>
both are MT76 in my case, though, so it's not super surprising.
<mangix>
hmmm then it's not a firmware issue
<mangix>
maybe it has to do with the whole hardware offload that nbd implemented
<takimata>
yeah, I can't make any qualified comment on any of that. :(
<mangix>
same here
<takimata>
it's a delicate issue for sure.
<mangix>
anyway, I'm completely happy with mt7915 DBDC
<takimata>
part of the problem will be that this bug hits as far back as 21.02 (running on my AP), so if the MT76 driver is to blame and can be fixed, it will be hard to roll out the fix.
<mangix>
21.02 supports RT3200?
robimarko has quit [Quit: Leaving]
<takimata>
no, but there's loads of devices running MT76 on 21.02
<takimata>
anyway, that's neither here nor there, not my decision and certainly not my area of expertise (as far as I even have one.)
<takimata>
(the high-level side of programming is where I live.)
<mangix>
takimata: mt7915 dbdc also runs mt76 and doesn't have this issue
<mangix>
I doubt other devices have the issue
<mangix>
rt3200 and e8450 are a bit...special
<takimata>
yeah, the "fun" part is that I couldn't reproduce it when the SSH server was running the same 22.03.0-rc6 on an R6220, a MT7621 machine.
<takimata>
although the issue is somewhat intermittent, I might have just missed the window when it hit.
<hurricos>
takimata: sounds like only when packets are forwarded
<takimata>
no no, the R6220 was still just a client machine, it didn't do wifi, that was still done by the same AP.
<mangix>
I'm confident this is only an mt7915 issue
<takimata>
I just had it lying around unused, so I decided to slap on 22.03-rc to test.
minimal has quit [Quit: Leaving]
Borromini has quit [Quit: Lost terminal]
<hurricos>
Apart from the closed-core OpenIPC, can anyone recommend IP camera firmware?
Snuupy has joined #openwrt-devel
bluew has joined #openwrt-devel
<hurricos>
Ouch. The ecosystem is littered with giants that decided to make their code nasty as fuck
<hurricos>
unupstreamable, that's for sure.
<hurricos>
No point doing so anyhow -- it's all userspace device driver implementations, and they're bulky because it's *video*
karlp has quit [Quit: server upgrades.....]
Piraty has quit [Remote host closed the connection]