goliath has quit [Quit: SIGSEGV]
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
Tapper has quit [Quit: Tapper]
<owrt-snap-builds> Build [#779](https://buildbot.openwrt.org/master/images/#builders/54/builds/779) of `ramips/mt7620` failed.
ptudor_ has joined #openwrt-devel
ptudor has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
minimal has quit [Quit: Leaving]
danitool has quit [Remote host closed the connection]
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
bluew has quit [Quit: Leaving]
bluew has joined #openwrt-devel
<neggles> hurricos: fwiw the newer watchguard aarch64 stuff is "locked" but in an equally silly / easy to bypass fashion for anything higher-end than a T20
<neggles> the T20 is only a problem because it's eMMC boot instead of m.2 SATA boot
felix has quit []
<neggles> thus one finds oneself binpatching one instruction in the u-boot image on the SPI NOR (they don't have any of the secure boot stuff enabled)
felix has joined #openwrt-devel
matoro has quit [Ping timeout: 480 seconds]
matoro has joined #openwrt-devel
floof58 has quit [Read error: No route to host]
floof58 has joined #openwrt-devel
<Znevna> hauke: they do share some stuff, Asuswrt builds them all in the same section (same dts) only with changed build name https://github.com/SWRT-dev/swrt-gpl/blob/master/release/src-rt/Makefile#L967
goliath has joined #openwrt-devel
valku has quit [Quit: valku]
goliath has quit [Quit: SIGSEGV]
gladiac has joined #openwrt-devel
<mrkiko> good morning to all !!
<Znevna> morning
<mrkiko> Znevna: :)
bbezak4 has joined #openwrt-devel
bbezak has quit [Ping timeout: 480 seconds]
bbezak has joined #openwrt-devel
bbezak4 has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
bbezak0 has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
bbezak has quit [Ping timeout: 480 seconds]
lmahmutov has joined #openwrt-devel
<lmahmutov> hi2all
robimarko has joined #openwrt-devel
<lmahmutov> i have trouble with noname router board based on IPQ8072 + qca8081x2, i added dp5 and dp6 for qca8081, but ethernet device not working, ping not going, only show cable attached and nothing more. Maybe you can help what i lost
<robimarko> Do you by chance have wlan enabled and have not used the stock fw bdf?
danitool has joined #openwrt-devel
<lmahmutov> wlan firmware is not loaded. Only loaded nss-dp drivers
<lmahmutov> this board come to me with custom openwrt based on kernel 5.10 and fully working all intefaces
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
<robimarko> Mildly put that means nothing
<robimarko> What does your DTS looks like?
<lmahmutov> Maybe I didn’t do it correctly, I used your examples and rules for myself
<robimarko> Are you sure that in qcom,port_phyinfo
<robimarko> PHY adresses arent reversed?
<lmahmutov> 24 and 28 ? ..... i dont now ( my knowledge at ipq platform is very weak
<lmahmutov> try to reverse it ?
<robimarko> Well, if you connected the phy correctly via phy-handles
<robimarko> Then those under qcom,port_phyinfo are reversed
<robimarko> Cause, you connected the PHY @28 for DP5 but under the switch you are telling it that the adress is 24
<lmahmutov> i found it.....
<lmahmutov> thnx go to build firmware
lmahmutov has quit [Remote host closed the connection]
floof58 is now known as Guest2868
floof58 has joined #openwrt-devel
Guest2868 has quit [Read error: Connection reset by peer]
lmahmutov has joined #openwrt-devel
<lmahmutov> many thnx Robimarko ! problem resolved )
<mrkiko> What's the expected use of the two 5GHZ interfaces on newer SOCs ? (ipq807 ffor example).
<\x> if dfs isnt working then 36+ and 149+
<mrkiko> \x: ok, so you're expected to place one in low freq zone and the other in high freq. And how do you distinguish what of the interfaces you are expected to use in what zone?
robimarko has quit [Remote host closed the connection]
<\x> depends sometimes it wont matter sometimes it will for xiaomi stuff its like one is 5.2 and one is 5.8
<\x> so youll know which is which
robimarko has joined #openwrt-devel
<\x> mostly the 160MHz radio has to be on 36 but dfs has to work for that
<\x> since it will breach 52+
<mrkiko> \x: thanks for the hints. May I ask you how I can say if "dfs" is actually working?
<\x> just set it to a dfs channel and watch logread -f
<\x> if it says AP is up, see it on your phone or pc with 5ghz wifi
<Znevna> can anyone else look over https://github.com/openwrt/openwrt/pull/11897/files
<Znevna> having lan4 on gmac1 and wan on the switch just looks wrong to me
<mrkiko> \x: thanks
<stintel> neggles: re wg aarch64, what else is there besides T20?
<neggles> stintel: T40, T80, M290, M390, M590, M690, NV5
<neggles> T20 (LS1023A), T40 (LS1043A), T80 (LS1046A), M290 (LS1046A), M390 (LX2084A), M590 (LX2120A), M690 (LX2160A), NV5 (LS1012A)
<neggles> should've lead with that one
<robimarko> mrkiko: Usually they cover different parts of 5GHz
<dhewg> robimarko: can you explain that please? https://github.com/openwrt/openwrt/issues/11902#issuecomment-1408467518
<dhewg> the phy/net relation ship is completely different from what I'm getting on my devices
<robimarko> dhewg: I dont get what you mean
<robimarko> AX3600 has an extra QCA9889 PCI radio
<robimarko> So that is why there are 3 PHY-s
<dhewg> I have multiple phys with multiple wifi nets on each. each net is only exactly under the phy sysfs where it's configured
<dhewg> here we have the same net under 2 phys
<robimarko> Maybe it has to do with the fact that ath11k is registering them both from the same path
<dhewg> Dunno, but that situation explains the bug at least
<dhewg> so is that a ath11k bug or feature? ;)
<stintel> neggles: thanks
<stintel> neggles: lol M690 $22476
<stintel> any of these nearing (or already) EOL?
<neggles> they don't actually cost that much lmao
<robimarko> dhewg: It shouldnt be a driver thing, same thing should be happening with all drivers that register multiple wiphy-s
<stintel> I know I know but still probably ~10k
<neggles> usually it's "hardware's free with 3 years of license" which costs about the same as the hardware
<neggles> so yeah, about that
<neggles> they're relatively new though, probably be another year or two before 3yo ones start popping up
<dhewg> robimarko: a bit weird, but ok, thanks!
bbezak09 has joined #openwrt-devel
<robimarko> dhewg: That needs confirmation though, I dont really have other HW which uses multiple wiphy-s but one driver instance
bbezak0 has quit [Ping timeout: 480 seconds]
<dhewg> yeah, asked on irc, let's see
<dhewg> but those are 3 distinct phys? there's no parent/child relationship or something?
<robimarko> 2 are from ath11k
<robimarko> 1 is from ath10k
<robimarko> But they should be indepent from one another
<robimarko> At least that is my understanding
bluew has quit [Ping timeout: 480 seconds]
<dhewg> Maybe that's all valid and I removed too much code, I just haven't seen that before :)
bbezak09 has quit [Ping timeout: 480 seconds]
<lmahmutov> Robimarko :) can you help me with last trouble? system started correctly and fully working, but only 1 issue, i cannot enable 160mhz on wifi
<lmahmutov> radio is ipq8074
<robimarko> Probably long DFS time
<lmahmutov> how can this be checked? i think problem realy with dfs
<robimarko> What is logread saying?
<robimarko> It will print the CAC time
<lmahmutov> logread only says DFS started and then give hostapd error. daemon.warn hostapd: phy0-ap0: IEEE 802.11 Configured channel (104) or frequency (5520) (secondary_channel=-1) not found from the channel list of the current mode (2) IEEE 802.11a
<robimarko> Did you set country code?
<robimarko> What does iw phy list as allowed channels?
<robimarko> I hope you are using the BDF from stock firmware and not the generic one
<lmahmutov> yes i use from stock firmware (
<lmahmutov> how i need to replace it ? can you suggest me how to change it
<robimarko> You did answer other questions
<robimarko> *did not
<lmahmutov> country set to RU
<nbd> dhewg: regarding your sysfs related questions, it seems like we need to revert some of your changes to iwinfo...
<lmahmutov> https://pastebin.com/9i8i3Gwy iw list
<robimarko> But is the country code set to RU in wireless config?
<robimarko> If its not set then DFS wont work
<lmahmutov> option country 'RU' in wireless config
<dhewg> nbd: yeah, there's a bug alright. The code changes still make sense, but we need this on top https://github.com/openwrt/openwrt/files/10535577/0001-iwinfo-fix-it-maybe.patch.txt (unconfirmed)
<nbd> it's not just one bug
<nbd> there's another flawed assumption
<dhewg> oh?
<nbd> phy names are not always phy%d
<nbd> they can be renamed
<lmahmutov> if i setup channel 36 i get this error hostapd: DFS start_dfs_cac() failed, -1
<nbd> i think it would be better to revert the broken changes, then re-do only the relevant pieces
<dhewg> hm, did I hardcode that?
<mrkiko> nbd: hi!! I was curious to know - why mt7916e in rt3200 generates an interrupts any 10s more or less, while not using wifi
<nbd> dhewg: you did in 'nl80211: simplify iterating over phy's devices'
<dhewg> indeed
<dhewg> that's also the commit that broke tx power
<nbd> mrkiko: maybe some firmware event, not sure
lmahmutov has quit [Quit: Page closed]
<Znevna> hmm, we have broken tx power? :P
<mrkiko> nbd: thanks!
<dhewg> the supplicant patch is on top of that, so if we don't fix it we need to revert both
<robimarko> lmahmutov: no idea
<nbd> dhewg: revert + re-apply might be easier to review, not sure
<nbd> either way, it doesn't matter much to me, as long as the issue is fixed
<dhewg> the supplicant one is nice to have, but it's not a 100% fix anyway, since there's still the wpa code path
<dhewg> so dunno, let's revert both for now to get rid of the bugs
<nbd> we don't have to just revert + update, you can also send a series that re-applys that change after reverting both
<nbd> or you just send an incremental fix
<nbd> i agree that the interface mode related change is useful
<dhewg> ok, let's see about an incremental fix
<dhewg> ifname is easy to set, but when is a phy not phy%d?
<nbd> when it has been renamed
<dhewg> duh :P
<nbd> on the mediatek target i implemented automatic renaming based on entries on board.json
<nbd> the idea is to keep stable predictable phy names, even when the probing order or the device path changes due to kernel or dts changes
<robimarko> lmahmutov: what does iw reg get return?
<slh64> mrkiko: there are also ipq807x devices where two 4x4 5 GHz radios are combined to form one 8x8 5 GHz radio, possible - but not the most common setup (xiaomi ax9000 places both independently on different parts of the band, without overlap - so one radio for everything under ch100, the other for everything above ch100; best for mesh repeating)
<dhewg> oh nice, a usb wifi adapter is sometimes phy0 and sometimes phy2 here
<robimarko> slh64: But that case should be transparent to the user
<slh64> robimarko: I haven't seen the behaviour on OpenWrt/ wirh ath11k yet - not sure how it's exposed to the kernel
<mrkiko> slh64: thanks!
<mrkiko> slh64: in the nbg7815 case, you have 2x 5 ghz radios, I guess 2x2 each, 4x4 togeter
<slh64> mrkiko: that sounds unlikely, I'd expect each of them to be 4x4
<mrkiko> slh64: so, if I understand it correctly, in some devices I might see less interface because they are combined by firmware, so I may have an 8x8 formed by two radios trasparently. did I understand right?
<slh64> mrkiko: as mentioned, I'm not sure how ath11k exposes that to the kernel/ userspace, but yes
<robimarko> slh64: Its not exposes
<robimarko> As far as I can know, its basically 2 PHY-s in parallel
<robimarko> And FW takes care of that, to you as the user nothing changed
<slh64> ah, good
<mrkiko> slh64: robimarko: thanks
<slh64> weird, zyxel advertizes the nbg7815 as one 8x8 radio (so exactly the case mentioned here, two 4x4 radios merged into obe 8x8 radio), so you shouls only see one 5 GHz radio there
<robimarko> Yes, you will see only one WIPHY
<robimarko> For 5GHz
<mrkiko> robimarko: maybe I'm wrong... but I see three of them
<robimarko> mrkiko: On which device?
<mrkiko> nbg7815
<dhewg> nbd: incremental fix: https://github.com/dhewg/iwinfo/commit/60183c215a223bc0f4bfc2e6f6e9b01d8c99e43e I'll throw that in the tx pr too
valku has joined #openwrt-devel
<robimarko> mrkiko: So there is not a third radio?
<mrkiko> robimarko: how may I discover it?
<robimarko> I mean, there isnt a PCI radio?
<robimarko> There shouldnt be as far as I remember
<mrkiko> robimarko: I don't think so
<robimarko> Hm, that makes it interesting
<robimarko> Especially since the allowed channels only overlap partially
<mrkiko> if you need ssh access, drop e a message; I'll just run lspci in a moment
<robimarko> PCI isnt even enabled in DTS, so no need
<mrkiko> no need, from dmesg I'm sure there isn't a pci card
<robimarko> Ok, so max_radios is set to 3 for IPQ8074
<robimarko> This is interesting, so there has to be a WMI call returning the number of WIPHY-s from the FW
<mrkiko> robimarko: "Especially since the allowed channels only overlap partially" -> what do you mean? We are maybe not using the hw in the expected channel ranges?
<robimarko> I mean, if you check the 5GHz allowed channels from the iw phy output you provided
<robimarko> You will see that the 2 5GHz WiPHY-s overlap only in the low 5GHz band
<mrkiko> robimarko: ok
<robimarko> mrkiko: Now, I wonder how they actually use those two in "8x8" mode
<mrkiko> robimarko: because e expect them to overlap perfectly if that's the intended setup. Well, yes - pretty curious
<mrkiko> robimarko: maybe they limit the channels to the ones supported by both radios? Only speculations from my side ... but please don't ask me to go back to stock :D
<robimarko> mrkiko: No, I wont ask you do to so
<mrkiko> :D
<robimarko> I mean, how can you configure 2 separate WIPHY-s to basically act as one?
borek has joined #openwrt-devel
borek has quit [Remote host closed the connection]
borek has joined #openwrt-devel
<stintel> hah looks like M200/M300 EOL has been postponed to 30/06/2023
dangole has quit [Remote host closed the connection]
minimal has joined #openwrt-devel
bbezak has joined #openwrt-devel
borek has quit [Quit: borek]
borek has joined #openwrt-devel
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
gladiac has quit [Quit: k thx bye]
Borromini has joined #openwrt-devel
goliath has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
valku has quit [Quit: valku]
Acinonyx_ has quit [Ping timeout: 480 seconds]
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
borek1 has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
borek1 has quit [Remote host closed the connection]
gladiac has joined #openwrt-devel
cmonroe has quit [Read error: Connection reset by peer]
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
<nbd> dhewg: looks good to me
<dhewg> just got a confirmation that it fixes the issue, so I just sent it
<dhewg> thanks for pointing out the issues, I didn't see those before
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Mathew has joined #openwrt-devel
mcbridematt has quit [Read error: Connection reset by peer]
gladiac has quit [Quit: k thx bye]
<champtar> quick question, with the buildbot 2 phase build, will a DEPENDS:=@(TARGET_imx||TARGET_kirkwood||TARGET_mvebu||TARGET_qoriq) work ?
<champtar> github CI make it seems it'll work
robimarko has quit [Quit: Leaving]
cmonroe_ has joined #openwrt-devel
<dhewg> its used all over the place, so lets assume so :)
<dhewg> did github change something wrt tag tarballs? I get different files/checksums since yesterday, while the content is the same
<tmn505> it was never guaranteed: https://github.com/libgit2/libgit2/issues/4343.
<stintel> github was a mistake :P
<tmn505> if projects would upload those tarballs to releses, that would stay the same
<tmn505> but everyone has went the conveniet way
<dhewg> I can one-up that, in this case precompiled binaries are a release, the source tag tarballs are not
borek has joined #openwrt-devel
<champtar> git 2.38+ doesn't generate the same tgz as before if I follow correctly
<dhewg> do they really create tarballs with git per click?
<tmn505> yes
<champtar> dhewg: they likely have some caching, but you can ask to download any commits, not only tags, so you don't want to store all the generated archive forever
<tmn505> so as the blog says "If you need to rely on a consistent checksum, you may upload archives directly to GitHub Releases." like for example libevent2
<jow> is this affecting the "codeload" facility?
<tmn505> but seem there was big uproar, so it might have been changed to their own implementation for good
<tmn505> codeload is just sever where it's stored, the links from site are redirected to it
<jow> ah right
<tmn505> redirecting
<tmn505> so yes
<KGB-1> 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.)
bluew has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]