schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rmilecki has joined #openwrt-devel
<enyc>
hauke: I'd pefer the xrx200 note explicit about how this may be fixed within 23.05 series or that being ruled out at this stage, myself.
<enyc>
r.e. xrx200/hhv5a/etc routers
schwicht has joined #openwrt-devel
<slh64>
enyc: so far it's not fixed upstream/ mainline or in master either, until it is, no one knows if it will be fixed within a reasonable timeframe (at all) - and xrx200 has already held back branching 23.05 for a considerable time (it was one of the last major blockers, until it got demoted to no-longer-blocking, as there was no immediate fix in sight)
<slh64>
if it can be fixed in master before 23.05.0-final, it will be fixed for 23.05 as well - if it can't be, ... well... look at mvebu in 22.03.x
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<enyc>
slh64: Hrrm, mvebu switch in wrt3200acm now sorted?
schwicht has joined #openwrt-devel
danitool has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<slh>
enyc: master and 23.05~, yes - 22.03.x, no - and by now it's safe to assume that it won't be for 22.03.x
schwicht has joined #openwrt-devel
gladiac has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tapper has joined #openwrt-devel
gladiac has quit [Quit: k thx bye]
<enyc>
slh: fine =) no problm with 23.05 for wrt3200acm =) ... trying to encourafe friend uwho uses one to test for everybody's benefit =).
<slh>
testing is always needed, but at least the switch issues should be resolved (in master and 23.05~), those were 'just' a bug with kernel 5.10
<enyc>
slh: If i'm understanding correctly, xrx200 switch driver issue is actually quite commonly used router type, anything we can do to get people who can help interested / aware , reach to right communities with people in the know used to coding / modifying those things?
<mrkiko>
enyc: I would try writing in the ML, lantiq socs are very apreciated and used in the VDSL world of course
<mrkiko>
enyc: that said, for switch testing the vdsl thing isn't needed so ...
<enyc>
mrkiko: I thought they were well appreciatied... are you in a good position to write a message there? if so please do so ......
<mrkiko>
enyc: let me check if i have some xrx2000 supported devices
<enyc>
mrkiko: I have set up HHv5a (lantiq xrx200) as all sorts of wifi client and 5 gig switch port configs and all sort ....
<slh>
enyc: yes, it is a common platform - but it still needs fixing, upstream/mainline and for OpenWrt
<mrkiko>
enyc: well, I don't have a clear idea on what's the current issue so I'm not in a good position to write the message for now, but if I have some devices I may get a clearer idea
<enyc>
slh: can you do anything to appeal for releavan help upstream as best as possible? -- only thing been taken out for 23.05 at the moment ... etc...
<mrkiko>
enyc: I have the 7412 which has a single port if I'm correct
<slh>
at the moment, no, that's beyond by abilities (and time); disclaimer, I'm not an OpenWrt developer and can't/ don't speak for the project
<enyc>
especially if somebody with nice organized set of references ...... can just put it to relevant places ...?
<enyc>
or collect the rfes about the problem into a wiki page that can be pointed at ?
<Mangix>
csharper2005: sure. mt7915+mt7621 works great for me currently.
T-Bone has joined #openwrt-devel
f00b4r0 has quit [Read error: Connection reset by peer]
minimal has joined #openwrt-devel
<enyc>
slh: basically if you could collate together *just* the relevant bits from openwrt-bug and upstream-bug/thread (directly, ont intiderctly) and clear-info on remaining-issue that would be helpful. If directed how best to, I would happly build/test and domnstrate the "it is" [the "it is" evidence needs clarifying/confirming anyhow....]
embargo has quit [Ping timeout: 480 seconds]
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
<hauke>
djfe: or someone else: which devices support 2.5G or more and should be named in the release notes?
<slh64>
dl-wrx36, qhora-301, nbg7815
<slh64>
the later twi even 10GBASE-T
<slh64>
s/twi/two/
<slh64>
(the effective throughput won't reach that though, it would require NSS offloading for that)
schwicht has quit [Ping timeout: 480 seconds]
<enyc>
mrkiko: I discovered a certain FritzBox! 7530 or so non-lantiq has DSL support too...
finger has joined #openwrt-devel
<mrkiko>
enyc: yeah sure, I ried that out and it works :D
<mrkiko>
vrx518
<enyc>
mrkiko: any better/worse than using HHv5a lantiq xrx200 and similar ??!?
<mrkiko>
enyc: not enough experience, but vrx518 supports 35B profile + vectoring
<mrkiko>
hauke will probably be muuuch more informed :D
<schmars[m]>
Just tried once or longer? Only reason i havent put openwrt on my home dsl fritzbox yet is that i havent seen reports from others yet
<hauke>
mrkiko: I added the fritzbox 7530 to the release notes ~30 minutes ago
<\x>
ipq40xx also do not forget got moved to DSA
goliath has joined #openwrt-devel
<schmars[m]>
i think there have also been significant developments in LuCI regarding Lua/JS/ucode, right?
<mrkiko>
enyc: schmars[m]: well, my experience with the 7530 was very good, it worked as expected. the only reason why I am not using it currently, is because the stock fw performs little bit better in vdsl terms and Iam using it as pppoe bridge only
<schmars[m]>
cool cool, thanks
<mrkiko>
hauke: schmars[m]: that said, I let it run for some time and it was pretty stable for me, also because ath10k works well on 7530 - on my experience at least
<mrkiko>
hauke: thanks a lot
<enyc>
mrkiko: with separate USB-ath10k plugged in ?
slh64 has quit [Remote host closed the connection]
slh has quit [Ping timeout: 480 seconds]
slh has joined #openwrt-devel
schwicht has joined #openwrt-devel
<mrkiko>
enyc: usb-plugged ? Why The fritz!box 7530 has ath10k
<djfe>
PR stage still but might be added: Netgear RAX120v2 (5gbit/s)
<\x>
wrx36
<djfe>
see 12:35:26
schwicht has quit [Ping timeout: 480 seconds]
<djfe>
slh64 mentioned some :)
<djfe>
(that's CEST time)
<\x>
sorry
<djfe>
no worries ^^
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
raenye has joined #openwrt-devel
<Habbie>
any idea why many packages, such as the various boost-* libs, say `but incompatible with the architectures configured` in `docker run openwrt/rootfs:aarch64_cortex-a53-master` ?
<Habbie>
the control file inside, say, the boost-atomic package does say "Architecture: aarch64_cortex-a53"
<Habbie>
oh wait, is it because libstdcpp6 does not exist?
<Habbie>
and the long-standing opkg bug where it reports the wrong reason for failure?
<Habbie>
ok, both aarch64 and aarch64_cortex-a53 find libstdcpp6 here - but for a53, that's wrong
FLD has quit [Ping timeout: 480 seconds]
<enyc>
mrkiko: OH I thought I saw another brand qualcomm but now I realise, Atheros is now under former company, if not always was!
schwicht has joined #openwrt-devel
finger has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
<hauke>
mrkiko: I was told that the performance difference between OpenWrt and FritzOS on the 7530 are not cuased by the DSL FW, but by some something else
<hauke>
but she also does not know what exactly
<hauke>
blocktrron: which Wifi 6e device is supported?
<hauke>
Slimey: Missing commit message. Please describe your changes
<Slimey>
i dont know what that means tho
<Slimey>
hm ok how do i fix
<raenye>
Slimey: see git --amend
<raenye>
lets you fix the last commit message (and/or changes). Then you could git push (or maybe git push -f is needed) to github
<ukleinek>
git commit --amend
<raenye>
right, sorry
<ukleinek>
and don't use git push -f, but git push --force-with-lease
<raenye>
what's the difference?
<ukleinek>
raenye: git push --force-with-lease fails if the remote end doesn't match your remote tracking branch. So prevents you overwriting changes that happend since your last push
<ukleinek>
It's more relevant on shared repos, still I think push -f is a bad (i.e. dangerous) habit
<raenye>
ukleinek: thanks for the heads up
<raenye>
ukleinek: are you familiar with dts? some parts seem like voodoo to me
<raenye>
mostly "I copied this line from a different device, not sure what it does and if it is needed"
<ukleinek>
raenye: I think I cannot honestly answer "no" :-)
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<raenye>
ukleinek: cannot answer no, as in "am familiar"?
<raenye>
I'm too new here to recognize nicknames
<ukleinek>
raenye: I'm more active in #debian-arm and #armlinux than in here.
<raenye>
I see. Nice to meet you :)
<raenye>
ukleinek: I was struggling to get the ethernet PHY recognize MAC from the mtd partitions
<raenye>
it's available in multiple places
<raenye>
I know there's the preinit fixup route, but it seems to my the lazy way of doing it
<raenye>
*me
<stintel>
Slimey: you need to change the actual commit subject, not the PR title ;)
<blocktrron>
hauke: I have the Predator w6 currently running on 6G upstairs
<Slimey>
This board is an Atheros AR9344 based dual ...
<Slimey>
ath79: add support for Adtran Bluesocket BSAP-192x board
minimal has quit [Quit: Leaving]
<ukleinek>
raenye: with /* in line 194 it's obvious it doesn't work ...
<ukleinek>
raenye: also it's often the bootloader that applies the mac address and linux just picks it up (either from the dtb (modified by the bootloader to contain the mac address)) or from HW)
<ukleinek>
raenye: also lanmac being a child of "u-boot,env" looks strange
<Slimey>
ok sent updated PR
<raenye>
ukleinek: the bdcfg partition has the lan MAC too, for tftpboot
<raenye>
(I tried some versions and commented out everything that didn't work)
<ukleinek>
raenye: sorry, I'm out here
goliath has quit [Quit: SIGSEGV]
<raenye>
10x anyway
<raenye>
ukleinek: any idea about the mib-poll-interval line? I suspect it has to do with link LEDs, which the device doesn't have
<raenye>
or about whether reset-gpios is actually needed for something
<jow>
Ansuel: it's doing board.json lookups over and over and tries to rename the phy on every find_phy() call
<Ansuel>
i feel like to fix that thing we will have to open a can of worms...
<Ansuel>
from what i know the bug is there from a long time
<Ansuel>
also i need to understand what was the idea of that commit in the first place thanks for the link!
rmilecki has quit [Read error: Connection reset by peer]
<jow>
a cleaner design would probably be renaming the phys once, as early as possible
rmilecki has joined #openwrt-devel
<jow>
and ditch any rename-on-access logic in mac80211.sh
Guest2487 has quit [Remote host closed the connection]
<Ansuel>
jow something like a preinit script or the change done in the hotplug script right from the start
<jow>
rabiit hole indeed
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jow>
mac80211 hwsim seems inoperable too
<jow>
Fri Jun 9 21:41:01 2023 daemon.err hostapd: Driver does not support configured HT capability [LDPC]
<jow>
this used to work just fine a while back
schwicht has joined #openwrt-devel
raenye has quit [Ping timeout: 480 seconds]
<hauke>
aparcar[m]: the attanded-sysupgrade needs some specail handling for the OpenWrt 22.03 to 23.05 upgrade because we replaced wolfssl with mbedtls
<hauke>
I think you should detect this and then switch from wolfssl to mbedtls
<hauke>
including ustream-ssl and hostapd
Danct12 has joined #openwrt-devel
<jow>
Ansuel: there's been some LuCI specific bugs indeed, for historical reasons it ignored netdev names starting with wifi[0-9]
<jow>
Ansuel: with that phy rename path, we might see wireless ifnames like `wifi5g-ap0`
<Ansuel>
mhhh are we still affected from those problem with wifi[0-9]
<jow>
however enabling/disabling still worked as expected in my tests
<jow>
so I tried for an hour or so to reproduce this with mac80211_hwsim and a handcrafted board.json to force this phy rename logic
<jow>
it uncovered some cosmetic luci issues but starting and stopping the radio from the ui worked
<Ansuel>
did you at least had the problem with the error in the log reported?
<jow>
which error? there's a lot of errors
<Ansuel>
Bug: PHY is undefined for device
<jow>
nope, don't see that one here
<jow>
I also noticed that in the reporters case the phy's aren't actually renamed
<djfe>
I should've paid attention to IRC ^^
<djfe>
thx for taking a look jow
<djfe>
PHY is undefined is one error, but I think it's caused by "WARNING: Variable 'data' does not exist or is not an array/object"
<jow>
it's the same issue
<jow>
just two error messages printed in the same code path
<jow>
you're absolutely sure that 4d323303e7e5743f541e3b41dfb2ac1627e8d96d introduces the regression?
<djfe>
that's what it does correctly, but somehow the phy stays online (ssid keeps being broadcasted and wifi led stays turned on, the led is controlled by the phy)
<\x>
i can test
<\x>
like this
<\x>
uci set wireless.radio0.disabled=1 ; uci commit ; wifi reload
<jow>
posted a new command sequence
<\x>
led goes off on my 40xx and the ap is out
<djfe>
ipq40xx is not affected by the bug
<djfe>
will test the new sequence
<djfe>
\x that runs fine, the issue only happens when you use the buttons in LuCI. Only confirmed targets so far: mt7621 and ipq806x
<jow>
you can also compare the output of `ubus montitor` (on a second shell) while using the LuCI buttons vs. the ubus uci command sequences
<jow>
they should be very similar (minus the `ubus_rpc_session` attribute used by LuCI)