raenye has quit [Ping timeout: 480 seconds]
danitool has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
cmonroe has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.)
schwicht has joined #openwrt-devel
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 ?
<enyc> upstream/middle/downstream-bugs relevant, etc?
<enyc> slh: hrrm it seems to be unclear if there is actually an issue-in-practice, interestingly ...
<slh> it is
<enyc> slh: lots of mention of "logs" being issue but not clear if packegts being isforwarded any more, or not
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
f00b4r0 has joined #openwrt-devel
T-Bone has quit [Ping timeout: 480 seconds]
schwicht has joined #openwrt-devel
<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> hauke: 2.5gbit/s: Netgear WAX206, Asus (TUF Gaming) AX4200, Netgear WAX218, Xiaomi AX9000
<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: Commit subject line MUST start with '<area>: ' (This adds support for Adtran BSAP-1920 and BSAP-1925 model of access points.)
<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
<stintel> Slimey: and also add everything from https://github.com/openwrt/openwrt/pull/12850#issue-1748597040 in the commit message
<ukleinek> raenye: that might be driver specific and so not work on each machine
<raenye> ukleinek: the IC is AR8033
<raenye> seems like the same driver as AR8237, which can (?) do it
<raenye> My .dts is here: https://pastebin.com/CxYj5TRE
<Slimey> so start with
<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
<owrt-2203-builds> Build [#256](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/40/builds/256) of `mvebu/cortexa53` completed successfully.
schwicht has joined #openwrt-devel
tlj has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
slh64 has joined #openwrt-devel
djfe is now known as Guest2587
djfe has joined #openwrt-devel
Guest2587 has quit [Ping timeout: 480 seconds]
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
<hauke> OpenWrt 23.05.0-rc1 is announced now
<hauke> lets wait for all the bug reports now ;)
<schmars[m]> nice, congrats! it's really cool to watch all the hard work of the last few months
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
<Znevna> weird that the 2gpbs mt7621 "fix" isn't mentioned
<Znevna> it's kind of a big deal :P
gch981213 has quit [Quit: Ping timeout (120 seconds)]
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Slimey> is it me or does netgear not believe in pussing fcc ids on some equipment
<Znevna> for devices not targeted for the us of a, why bother? :P
<Slimey> hmm odd got these from cdwg
<Slimey> netgear jsg516pe
<Slimey> not sure but might be bcm
<Slimey> 32MiB flash
<tmn505> doesn't FCC certifies "only" devices with radio? Switch doesn't fit that category.
schwicht has joined #openwrt-devel
dannyAAM has quit [Quit: znc.saru.moe : ZNC 1.6.2 - http://znc.in]
dannyAAM has joined #openwrt-devel
<karlp> wat? https://fccid.io/BKEHAC001/ what do you mean?
<karlp> lol, you mean switches.
goliath has joined #openwrt-devel
<Slimey> firmware contains sctring of QCA8513 DAL
<Slimey> nothing about realtek or rtl or brcm
<Slimey> heh wtf music_elite 2020.11.19 21:33:03 QCA QFN_DEMO
lucenera has quit [Quit: The Lounge - https://thelounge.chat]
lucenera has joined #openwrt-devel
<djfe> hauke: addition to release notes, you could mention the addition of the filogic subtarget (Mediatek target)
<djfe> Also like Znevna mentioned: we forgot about this PR, when you were asking for changes for the release notes:
<djfe> awesome that we finally got a release candidate
csharper2005 has joined #openwrt-devel
<csharper2005> Great news. That would be a killer feature for the release - https://github.com/openwrt/openwrt/pull/10042
<djfe> hauke: pls add this to known issues: https://github.com/openwrt/openwrt/issues/11725
<djfe> I just verified: I still can't disable WiFi via LuCI, the radio chip stays online
<csharper2005> djfe: ipq8065 is also affected
<Ansuel> dije wait is that a migration problem?
<djfe> I linked the commit that caused the regression
<djfe> it's because wifi stuff was renamed according to board.json
<djfe> it was present in main for months
<Ansuel> was?
<djfe> it happens on a fresh install (firstboot)
<djfe> *is
<Ansuel> ok
<djfe> has been present in main for months
<Ansuel> cause i have a similar report for it
<Ansuel> we should really sort it
<djfe> I told nbd on here a few months back
<djfe> yes, this should definitely be fixed before the release
<Ansuel> if we are lucky this might be handled in luci with a migration
<Ansuel> but it's bad that the bug happens on firstboot
<Ansuel> on a fresh config
<djfe> during master phase most people probably never noticed it due to not using LuCI
<djfe> it also happens on a fresh install (factory, sysupgrade -n), in-case this isn't clear
<hauke> djfe: added as known issue
<djfe> thx
zer0def has quit [Ping timeout: 480 seconds]
zer0def has joined #openwrt-devel
<djfe> hauke: pls add a new line to the wiki for better readability of "Known issues"
<hauke> djfe: done
<Slimey> is that new? wireless network device configuration advanced settings MUI-MIMO and Enable 256-QAM ?
csharper2005 has quit [Ping timeout: 480 seconds]
<Ansuel> 256 qam ?
<Slimey> oh that was immoralwrt ha
<Ansuel> still need to find time to propose that upstream...
goliath has quit [Quit: SIGSEGV]
f00b4r0 has joined #openwrt-devel
T-Bone has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
<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> in case it helps, here is the commit series that was published on Oct. 14th https://github.com/openwrt/openwrt/commits?after=6892603efa11603c6f365bee1cf94e98336d72aa+104&author=nbd168
<djfe> I ran git-bisect back then, I'm reading https://github.com/openwrt/openwrt/issues/11725#issuecomment-1403270202 myself right now because it's been a while
<jow> I don't see how it can potentially impact your issue, apart from minor timing changes
<djfe> deactivating LuCI in the parent commit worked just fine (I remember testing several times in a row for this commit)
<jow> looking at https://github.com/openwrt/openwrt/commit/4d323303e7e5743f541e3b41dfb2ac1627e8d96d and assuming an ordinary config (no renamed phys, using option path for phy id)...
<djfe> nbd: do you have an idea maybe? :)
<jow> then the only change will be the find_phy() -> [ -n "$path" ] -> [ -n "$phy" ] ... code path
<djfe> "I also noticed that in the reporters case the phy's aren't actually renamed" actually they are renamed
<jow> what's your board.json ?
<djfe> the code works in a way that I boot with "wlan0" and "wlan1" and they are renamed the first time wifi is activated
<djfe> I'll post the board.json in the issue in a few minutes
<jow> if they phys (not the ifnames) are still named phy0 and phy1, they're not renamed
<djfe> ok, I was only talking about the ifnames. My knowledge is limited :)
<djfe> board.json posted
<jow> ok, no renamed phy
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jow> can you post your /etc/config/wireless as well?
Tapper has quit [Ping timeout: 480 seconds]
<djfe> done
<djfe> I'm checking ipq40xx now
<\x> 40xx needs to start from scratch on their wired setup
<\x> its not like pre DSA worked
<djfe> is this related to me? ^^
<djfe> *directed at
<\x> oh you changing ifnames, sorry
<djfe> We are trying to figure out when and why LuCI fails to disable the wifi phy for some targets on main and rc1
<\x> like option disabled '1' ?
<\x> i have ipq40xx and now on rc1, hell i just got my hands wet with it yesterday since i timed my upgrade with a hardware mod ;) https://imgur.com/a/n0Nfh6N https://imgur.com/a/9LCshEY
<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)