<Mangix> interesting
<Mangix> that should be part of 3.4.7
<Mangix> yeah it is
Tapper has quit [Ping timeout: 480 seconds]
hanetzer2 has quit [Quit: WeeChat 3.8]
hanetzer has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
bluew has quit [Remote host closed the connection]
bluew has joined #openwrt-devel
minimal has quit [Quit: Leaving]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
danitool has quit [Ping timeout: 480 seconds]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
floof58 has quit [Remote host closed the connection]
floof58 has joined #openwrt-devel
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #openwrt-devel
valku has quit [Quit: valku]
floof58 has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
floof58 has joined #openwrt-devel
ptudor_ is now known as ptudor
goliath has joined #openwrt-devel
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (98.6% images and 100.0% packages reproducible in our current test framework.)
tlj has joined #openwrt-devel
tlj_ has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
mrnuke has quit [Read error: Connection reset by peer]
tlj_ has joined #openwrt-devel
tlj_ has quit [Remote host closed the connection]
tlj_ has joined #openwrt-devel
tlj has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
enyc has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
enyc has joined #openwrt-devel
goliath has joined #openwrt-devel
goliath has quit []
goliath has joined #openwrt-devel
danitool has joined #openwrt-devel
<karlp> probably making a new pr, rathr than push -f to the old branch?
<f00b4r0> ^
<karlp> they're marked as a first time contributor
<karlp> they closed the old ones at least, rather than leaving them dangling :)
<f00b4r0> they have nfc, quite obviously
<karlp> second one cleans up first one, third one fixes sob line.
<robimarko> I blame Github for people not knowing how to fixup existing PR
<robimarko> As they make it so easy to open or close one
<karlp> who cares? the pr was closed already by the submitter.
<karlp> do you get upset when people don't include the correct in-reply-to and msgid tags in email? it's the same thing.
<karlp> or in this case, if they'd sent as v1, v2, v3 emails even correctly formatted, and threaded? would that make everyones' teeth whiter and take out the garbage for them?
KGB-2 has quit [Remote host closed the connection]
KGB-2 has joined #openwrt-devel
<mrkiko> Obi-Wan: out of curiosity, is there a specific reason why we are not using the latest ath11k ipq8074 firmware? And was wondering if trying a new one can cause permanent issues to the board or something or if I may try
<f00b4r0> stintel: good laugh this morning: I just got visionfive's tracking number for the device I received a month ago ;)
<stintel> LOL
<f00b4r0> in an email aptly titled "VisionFive 2 Shipping Notice"
<Znevna> maybe you're getting an extra one
<Znevna> :P
<f00b4r0> no, the tracking is for the delivered one
<stintel> > According to our shipper, your VisionFive 2 package has been suceesfully delivered.
<stintel> same here :)
<\x> is that the 1 FE + 1 GbE?
<stintel> yeah :(
<stintel> really looking forward to next gen risc-v stuff, the vf2 is almost fast enough to be usable as desktop
<Habbie> like a pi3? or a 4?
nitroshift has joined #openwrt-devel
<nitroshift> morning guys
<stintel> iirc it was going to be more on Pi4 level
<stintel> nitroshift: o/
<nitroshift> stintel, o/
<stintel> neighbour :)
<nitroshift> hell yeah! :D
<stintel> > SiFive's new core to succeed the Performance P550 will reportedly improve performance by 50% and the company says it outperform an Arm Cortex-A78.
<stintel> ah but the announced one is using P550
<stintel> hmm
<stintel> oh well :)
<stintel> will most likely order one when it becomes available, like I did with the hifive unmatched
<Znevna> kek
<nitroshift> that would be spam ^
<nitroshift> stintel, pm for a sec?
<Habbie> ta
<stintel> nitroshift: I slept at your place, you don't need my permission to PM me ;p
<robimarko> karlp: Yes, its annoying as all of the replies and comments in the PR are gone with opening a new one every time
<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.)
<robimarko> mrkiko: Until QCA finally makes regdb.bin public for IPQ8074 2.7 can be used on some boards only
<robimarko> Those with newer BDF-s that have properly populated regulatory info
<mrkiko> robimarko: thanks
<mrkiko> robimarko: now, is the nbg7815 running openwrt master respecting regulatory domains ?
<robimarko> mrkiko: I dont have that device, but it probably has a bit outdated and more restrictive regulatory rules in BDF than the current ones
<robimarko> This is reason number 2 why I have been bothering QCA to make the damn regdb.bin public for all chipsets
<robimarko> So you can update the regulatory rules without having to update the damn BDF, it took them 2-3 years to finally figure out that is crazy
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
<mrkiko> robimarko: asking just to not "hurt" neightbour networks; and asking because sometimes experiencing some issues with Apple devices (that might not be related to firmware at all). In dmesg I can see messages like: at11k C000...peer not found xx:xx:xx......
<robimarko> mrkiko: You are not gonna hurt the neighbors as it does respect regulatory info, its just that its mostly more restrictive than the current rules
<mrkiko> robimarko: good, thanks
<Obi-Wan> mrkiko: I guess the question was not for me?
<mrkiko> Obi-Wan: oops, sorry - mistyped
<robimarko> How does OpenWrt handle HW eMMC partitions currently?
<robimarko> I am not really familiar with that
<stintel> I don't think there's generic support for that
<stintel> git grep -E 'mmcblk.?boot'
<stintel> only mediatek/mt7623 has something related to it
<stintel> I wanted to look into it also, but haven't found the time yet
<robimarko> Thanks, I have a client asking questions about that but I have not had to deal with them so far
<dwfreed> they exist, openwrt does not use them
<dwfreed> you can see them as mmcblk*boot*
<robimarko> Yeah, I know they exist but I did not use them so far
<robimarko> I remember some discussions regarding trying to use them in OpenWrt so I wanted to know the current state
<robimarko> Thanks
<robimarko> dhewg: Can I poke at you regarding the VRX modem driver?
bluew has quit [Ping timeout: 480 seconds]
lmahmutov has joined #openwrt-devel
lmahmutov has quit [Quit: Page closed]
nixuser has quit [Quit: leaving]
Misanthropos has joined #openwrt-devel
<neggles> i am yet to see anything actually make use of mmc bootparts
<neggles> the eMMC standard requires them to exist but only requires them to be 128KiB
<neggles> and it's only mandatory from eMMC 4.1 on up
<dhewg> robimarko: you can try, but jan would be the expert about the driver sources
<mrkiko> and mmc gives me the impression of one of these things you can't play with very much - looking at the mmc tool it seems some things you can do are actually irreversible or something if I understood it right
<neggles> correct
<neggles> you can carve an eMMC up into multiple chunks/LUNs but it's a one-time process
<neggles> and it's not mandatory to support it
<mrkiko> wondering why they did it that way
<neggles> there's a whole bunch of nice features in the eMMC spec, especially eMMC 5.1, but almost nothing is mandatory to implement and the things which are, are usually kneecapped
<dhewg> I know about the pci patch, but I don't have the issue it's fixing. I don't think it's clear when exactly it's happening, might be a hw revision or something like that
<mrkiko> neggles: and I guess that's true especially for router's emmcs - that you're not supposed to touch anyway :D
<neggles> IMO, JEDEC want eMMC to have all the features eUFS has, but the manufacturers don't want things to be mandatory because that drives the price up
<neggles> so you get a chicken-and-egg thing; manufacturers don't want to build in features nobody will use, but nobody can use the features because they can't count on them being there
<neggles> and half the point of using eMMC is the ability to use whichever chip you can get your hands on that meets your capacity/speed/endurance requirements
<robimarko> dhewg: Yeah, about the PCI patch
<robimarko> I really, really dont like it
<neggles> it's also rare for SoC BROMs to implement loading from emmc bootparts, for the same reason, and even when they *do* exist they're usually 4MB which is a bit crap.
<robimarko> And I am not seeing why its required, if its searching for the specific PCI ID, just patch the driver
<neggles> may as well just boot from mmcblk0@64s... 1-bit mmc mode is not significantly harder to implement than bootpart mode
<neggles> Habbie / zorun: heh... it's... https://browser.geekbench.com/v5/cpu/19845773 not... great...
<mrkiko> neggles: infact, I have yet to see a device with emmc but no spi flash to boot from :D
<neggles> oh there's plenty
<neggles> RK356x devices, bunch of allwinners
<mrkiko> neggles: plenty of devices with emmc only ?
<neggles> yup
<neggles> Soquartz for example
<neggles> and even the quartz64s with SPI come with them blank
<dhewg> robimarko: yeah, it's not a beauty by far ;) And maybe your suggestion works, but I still think jan is more competent in that area, so let him try that (noticed the mail)
<mrkiko> neggles: and in that case the bootrom should implement something or simply the flash isn't easily visible from kernel ?
<dhewg> he's got testers that are affected anyway
<neggles> mrkiko: most SoCs released in the last several years - at least ones i've touched/looked at - are capable of booting from SPI NOR, SPI NAND, SD card, or MMC, usually with a handful of different orders configurable via bootselect straps and/or eFuses
<neggles> thing is, if you can boot from an SD card, you can boot from eMMC...
<robimarko> dhewg: My gripe is that we need to keep it pretty much forever so
nixuser has joined #openwrt-devel
<dhewg> I think that's given
<neggles> e.g. rk35xx chips will look for their TPL at offset 0x8000 into the eMMC/SD card
<dhewg> I don't have details on how the hw works, does is it possible that the vrx chip acts differently with another pci id?
<robimarko> dhewg: No idea, that is what I asked basically
<dhewg> It may be a avm custom vrx chip too
<robimarko> Cause, if changing the root device PCI ID "fixes" it
<neggles> mrkiko: oh, right - the quartz64 SPI flash just shows up as /dev/mtd0, but from factory it's blank
<robimarko> Then you can just patch the driver to look for another PCI ID
<dhewg> yeah maybe, but there's also a firmware that might play a role, and we can't change that
<dhewg> assuming binary fw patching is a no-go
<neggles> binpatch all the things!
<neggles> (probably don't binpatch all the things)
<dhewg> xxd|sed -i|xxd -r is always nice
<neggles> you don't need the xxds
<dhewg> I know, but who doesnt love xxd
<neggles> `sed -i 's/\x4C\x4E\x56\x42\x42\x53\x45\x43\xFB\xFF/\x4C\x4E\x56\x42\x42\x53\x45\x43\xFF\xFF/g'`
<neggles> (thinkpad firmware signature check bypass)
<dhewg> heh
<mrkiko> neggles: thanks!!
<mrkiko> neggles: wow, nice
<neggles> even $2 allwinner chips can do all four
<neggles> usually the BROM search order goes SPI NAND -> SPI NOR -> eMMC -> SD -> usb downloader mode
<mrkiko> neggles: but you're clearly referring to allwinner-style bootroms or so, I've never seen a so-friendly router bootrom
<neggles> it depends; there's usually a pin or two on the SoC that control boot options/order, and usually eFuses to lock it down even furhter
<mrkiko> neggles: got it
<neggles> usually qcom router SoCs are locked down to "whatever the manufacturer ended up using"
<neggles> the NXP layerscape chips have more options than you can count...
<mrkiko> neggles: so in reality, the capabilities would be there but not accessible and then you end up having to solder uart and so on
<neggles> I mean, usually you only have one real option anyway, whatever's been soldered to the board
<robimarko> QCA SoC-s boot from whatever is set by the bootstrap pins
<neggles> do the router SoCs have an equivalent of EDL mode? 🤔
<robimarko> Yes
<robimarko> However, bootstrap must be set to USB mode
<robimarko> Or SBL needs to be corrupted
<neggles> IIRC once you've set up secure boot it's all moot anyway, part of that is usually blowing efuses to force exactly one boot option
<robimarko> USB mode should still work as long as SBL is corrupt
<robimarko> But, it wont work if for example U-boot is corrupted
<robimarko> And you need the original signed binaries off course
<robimarko> Plus QSahara etc
nitroshift has quit [Remote host closed the connection]
nitroshift has joined #openwrt-devel
<mrkiko> you need original signed binaries for qsee & friends, but u-boot isn't signed for example in ipq8007x or am I wrong?
<robimarko> You need signed binaries only if secure boot is enabled
<mrkiko> ah, ok
<robimarko> Otherwise you can use use the default prebuilt ones
<robimarko> And U-boot is signed if secure boot is enabled
<robimarko> SBL verifies it
<mrkiko> and what's the role of QSEE in general? I know is secure execution environ,ment or something, but I never understood if it stays somehow resident or not when openwrt is running
<robimarko> Its TrustZone implementation and its always running
<mrkiko> is this the case even in ipq4019 ?
<robimarko> Yes
<mrkiko> uh - didn't know that. But guess we have no driver for that and so talking with it is not as easy at the moment
<robimarko> You are talking with it
<mrkiko> or does it work via SMC or something
<\x> neggles: hah, I know that sed line
<robimarko> Via SCM
<robimarko> On ARMv8 QCA SoC-s QSEE/TZ provides PSCI as well
<robimarko> It does quite a lot of things
<mrkiko> so they covered part of ATF spec via their own stuff in a sense. What do we talk with QSEE for ? to understand it's scope in system architecture
<robimarko> For everything that is "secure"
<neggles> \x: 😆
<robimarko> ATF isnt a spec
<robimarko> You can provide PSCI however you want, even via U-boot directly
<neggles> qcom SoCs are constantly lying to you fwiw
<robimarko> Regarding what?
<neggles> well, maybe not all of them. but ye olde hypervisor
<robimarko> Now they have a fancy new one called Gunyah
<neggles> "you don't have low-level hardware access and you never will" - qualcomm
<mrkiko> robimarko: ok, but in "typcal" openwrt usage, I guess the services we use the most are crypto related. Or do we use it also to access eth/wifi phys or something?
<neggles> "we provide the illusion of low-level hardware access"
<\x> you can say the same to most cpu manufacturers
<robimarko> mrkiko: Not really
<\x> Intel ME, AMD PSP, ARM TZ
<\x> wew
<neggles> eh not really
<neggles> those don't intercept peripherals and for the most part can be disabled or shoved out of the way
<robimarko> In theory all of those should be optional
<\x> AMD one will never be optional, an ARM chip handles memory and pcie training so when x86 comes out of reset, no cache as ram happens, its just yeah, memory and pcie is ready
<\x> so theres no way you can remove that hehe
<neggles> no, but you don't have to interact with it after it's done setting things up
<robimarko> ATF is getting damn hard to ignore though
<neggles> qcom uses their hypervisor nonsense to present semi-standardized MMIO interfaces to hardware/peripherals, at least in android SoCs
<neggles> (and to stop you from being able to read the bootrom)
<robimarko> I would say they have a lite version of that on router SoC-s
<robimarko> But its far from smartphone SoC-s
<neggles> ...and to stop you from working out that HEXAGON, SDM, and the GPU are *not* behind the hypervisor and have full unrestricted unmonitorable access to the entire physical memory map
<neggles> ~you should be afraid of the modem in your phone~
<robimarko> Well, there arent really alternatives
<neggles> robimarko: it's far from the smartphone SoCs *so far*
<mrkiko> eheh yes; but I guess also a bug in ath11k firmware can simply corrupt the memory of my nbg7815 all the way ...
<\x> yeah ril is whats stopping a lot of those msmxxxx-mainline thing to be usable
<robimarko> mrkiko: Nope
<robimarko> Its living in a carved out reserved memory
<robimarko> neggles: So far they did not bother to carry over a lot of relatively old smartphone things
<mrkiko> robimarko: oh! Nice to know. They kinda implemented an IOMMU in a sense
<robimarko> Probably to keep them cheap
<neggles> also because they don't have to hide widevine keys
<robimarko> mrkiko: They did not implement anything, its just a kernel feature
<neggles> the SDX in your average qcom smartphone runs its own I Can't Believe It's Not Linux operating system, is directly exposed to the public internet, and people quite regularly report RCEs on the thing; it is quite possible to remotely exploit an SDX in a persistent fashion that's nearly undetectable, and will not be wiped on a factory reset of the
<neggles> device...
<robimarko> Though, I guess it could still try and use more RAM than mapped
<neggles> (this is why apple keeps the SDX behind a dedicated IOMMU in their devices)
<mrkiko> robimarko: it's a kernel feature but I guess there should be some hw enforcement to make it effective
<robimarko> mrkiko: Not really
<neggles> just the usual buffer overflow prevention stuff
<robimarko> Its kind of you carve out memory space and load it into
<robimarko> It is ioremapped though so in theory it shouldnt be able to overlfow
<robimarko> neggles: Yes, modems are scary
<neggles> attempting to write outside that area should cause a panic/oops
<robimarko> They remind me of Intel ME
<robimarko> Completely autonomous with acess to everything
<neggles> i'm much less scared of ME/PSP/etc
<robimarko> Well, you shouldnt be
<neggles> they're not directly attached to the internet
<robimarko> Thats the catch, ME is
<neggles> no it's not
<neggles> it's on my LAN
<robimarko> Fair point, but its not like you are always gonna use it behind a good firewall
<mrkiko> and nothing stops it from performing outgoing connections if your PC can
<neggles> no, but just being behind NAT is enough to stop bots enumerating things
<neggles> and the network-enabled features of ME are almost entirely disabled in non-vPro builds
<neggles> plus there's always the HAP bit
<robimarko> That is fine as long as you are controlling the network
<robimarko> But you never used it in an airport or so?
<robimarko> Those vPRO features are basically perfect for exploiting
<mrkiko> It's mindboggling how many opportunities those things would give you if only they where free/open-source software. But clearly reality is different...
<mrkiko> i.e.: in accessibility terms
<neggles> robimarko: assuming vPro is enabled :P most consumer boards don't have it turned on
<neggles> and vPro is only a significant risk if you have it and don't configure it
<robimarko> neggles: There is still a lot, a lot of "business" notebooks with vPRO
<neggles> mmhm, and that is why we configure it on all our clients' systems :)
<neggles> all my vpro equipped systems are attached to a meshcentral instance i run (similar setup at work, just integrated with our RMM), mTLS authentication, no inbound connections accepted, blah blah
<robimarko> Well, that still leaves plenty of those that are not configured
<neggles> indeed
<neggles> to be fair the default configuration for the past 7? ish? years is locked way the heck down
<robimarko> That is counting that there isnt a nice CVE
<robimarko> My point being that ME, modems and whatever crap is running autonomously all the time is scray
<neggles> it's not optimal, no
<neggles> mrkiko: fun fact: intel ME runs minix
<robimarko> That just makes it worse
<neggles> worse was the fact that they spent 8 years with every vPro-equipped system defaulting to "network enabled, network access enabled, username admin, password admin"
<robimarko> Cause, why not
<neggles> at least these days you have to physically touch the system to enable that stuff
<mrkiko> neggles: ehehe yeah I knew
<neggles> just... ugh. there's a reason the US DoD made intel put the HAP mode in there.
<neggles> a CSME 12 source code leak would be cool :P
<neggles> or whatever version it's up to now
<karlp> re emmc bootparts, I know they're not well used in openwrt right now, emmc is moslty just "an sdcard" btu I'm using it for our new hardware to put uboot and uboot-env on bootparts,
<neggles> speaking of cursed intel shit, have y'all seen MaxLinear's new router chips?
<karlp> so the plain user partition is jsut data, I don't need any fat partitions or anything.
<mrkiko> but my perspective on these things is that - most of modern hw has these things, so you should do your best to make it secure but you know in a sense it's built to be vulnerable to some people
<karlp> but yeah, lots of people not using it because it's not commonly used...
<robimarko> neggles: What amalgamation is MaxLinear up to now?=
<dhewg> nbd: thx for the mt76 bump, on a sucky ipq4019 usb attached mt7921u adapter that close to doubled throughput, nice one!
<\x> oooo
<\x> i need to try that sometime dhewg
<nbd> dhewg: cool!
<\x> is VHT over 2.4GHz working on mt7921u
<dhewg> PAGE_POOL eh
<\x> need mt76 patched ei
<neggles> well they bought The Artists Formerly Known As Lantiq off intel a little while back as you probably know
<stintel> I was just building a new image for my eap615 APs :)
<neggles> and they've got some shiny new router SoCs targeting wifi 7 / XGS-PON
<dhewg> also took a leap of faith, mold linked image running live on primary router atm. but non-lto for now
<neggles> which have four atom cores. as far as i can tell they're Goldmont
<neggles> wheeeeeeeeeeeeeeeeeeeee
<robimarko> Shame that they are useless to us
<neggles> verizon CR1000B has one in it, and they have a GPL dump
<neggles> it's u-boot in there
<neggles> idk what else i expected tbh
<\x> dhewg: what throughput are ye getting
<neggles> just feels really weird to have u-boot+x86_64
<robimarko> Its rare, but x86 is supported just fine
<neggles> robimarko: allegedly, one of MxL's big customers has demanded upstreaming of these
<robimarko> neggles: Oh, that would be perfect
<neggles> they've said in the past that it was "on the roadmap" but they weren't going to commit to it until a customer wanted it
<robimarko> It would be nice to have upstream driver for the WLAN
<neggles> that is definitely in the works
<mrkiko> neggles: on what chipset is the wlan on that hw based?
<neggles> the anywans don't have their own wifi in them
<neggles> the verizon cr1000b is using qcom chips i think lemme check
<robimarko> They have the MxL31712/MxL31708 with built-in wifi
<neggles> sorry, those 3 new ones specifically
<neggles> but no they're not qcom wifi, marvell 10G NICs but mxl wifi
<dhewg> \x: same as the ipq4019's ac now, 20MB/s
<neggles> WAV600 series-2
<neggles> WAV655 in the CR1000B i believe
<dhewg> the reported nl80211 connection rate goes up to 1200mbit, but the ipq4019 usb bus can't keep up I think
<dhewg> it's probably way higher on other boards, but I try to keep the number of boards and their watts low
<neggles> of course the CR1000B is running a 4.19 kernel, so upstreaming is likely to be... slow... assuming it even happens
<mrkiko> neggles: thanks
<mrkiko> thanks to all
<robimarko> neggles: Doubt its ever gonna happen
<neggles> i can dream
<\x> dhewg: ill try it maybe tomorrow, I have mine overclocked maybe itll help
<dhewg> nice, lemme know how that works
<\x> i cant test 6g though
<neggles> have intel managed to release an ax210 firmware that doesn't immediately kill 6ghz the moment it sees a non-US country code yet
<dhewg> fyi, this is a ax ap on mt7921u, and a notebook connected to it with a mt7921e without any manual irq/core tuning, just plain irqbalance
<dhewg> ax ghetto extended ipq4019
<neggles> 20MB/sec sounds like it's only getting usb2.0?
<\x> seems i have higher results from back then
<stintel> hmm, >800Mbps with my s21u connected to eap615 with latest mt76 bump - looks like the GbE is now going to become the bottleneck :P
<neggles> i have an mt7921u usb stick which does 6ghz, only 6ghz device i have right now apart from the cambium AP and the Cursed Aerohive thanks to intel's BS
<neggles> plugging it into my test NUC makes the ethernet flap...
<dhewg> oh I bet a mt7921u performs better on anything not ipq40xx
<Znevna> yay we have LEDs for mt7915, thank you, nbd :)
<neggles> does current openwrt still do octeons
<stintel> we need to track down a performance regression between 5.10 and 5.15
<neggles> yes
<dhewg> \x: looks simiar? ~24MB/s without -R, stable 20MB/s with from a client
<neggles> stintel: oh?
<stintel> neggles: actual network b/w dropped a lot
<neggles> oof :/
<stintel> ehr, s/b\/w/throughput/
<neggles> i've got a xirrus XD2-240 here which is a dual core oct iii
<stintel> seen it on snic10e and iirc Habbie saw it too on erlite
<neggles> there's a huge number of them available 2nd hand for $30-40 right now
<\x> so still so far only the mediatek addon cards/usb can do wifi 6e?
<Habbie> stintel, yes
<neggles> broadcom wifi, but it's minipcie cards, going to put two 4x4 7916AN cards into it if i can make it work
<neggles> need to harass my cambium account manager for a gpl tarball
<jow> nbd: a while ago you added bonding device support to netifd
<neggles> stintel: hmm interesting. wonder if it's just oct+/oct2 or oct3 as well
<neggles> guess i'll have to find out
<\x> neggles just buy a thinkpad x200, three mini pcie slots, two fullsize, one half
<robimarko> \x: QCA has 6E cards as well
<neggles> \x: oh no no i've already done a cursed thing
<\x> theyre like 20$ if you look hard enough
<robimarko> No idea about availability, MTK is probably best bet
<neggles> i put two MT7916DAN cards into an aerohive AP330, freescale P1020
<\x> issue is that cpu is like dual core penryn
<jow> nbd: the type name chosen for it is "bonding" which does not correspond to the kernel name ("bond") is not consistent with e.g. "bridge" either (which we don't call "bridging")
<\x> but its not an issue for 1GbE
<jow> nbd: would you mind renaming the type to just "bond" ?
<jow> maybe coupled with a config fixup to change bonding to bond internally
<neggles> \x: oh i'm quite familiar i have an x201s around somewhere
<\x> x201/s has two mini pcie slots
<neggles> ...there are a lot of thinkpads in this house
<\x> two fullsize
Larhzu has quit [Quit: leaving]
<\x> you can put an nvme in there if you want albeit slow
<neggles> you can also hook up an eGPU
<neggles> does this serve a purpose? not really
<\x> i did it on an x200
<\x> lelz
* neggles slow claps
<nbd> jow: fine with me
<neggles> tbh i was more surprised that the poor dual-core PPC in the AP330 can push 900mbps TCP
<\x> had to coreboot it for native nvme boot, else youll have to chainload it via grub or like whatever that hackintosh thing uefi is
<neggles> those 3x3:2 DBDC MT7916 AP cards run *hot* though
<neggles> robimarko: you can get the QCA 6E cards without too much trouble
<neggles> but god knows what driver support is like
<\x> what11k
<neggles> they're different chips to what's in the APs
<robimarko> What is the chipset?
<robimarko> All of the PCIe ones are supported
<neggles> i've seen at least one 1x1 SDIO, one 1x1 PCIe, one 2x2 PCIe. lemme see
<neggles> (also a 2x2 SDIO which seems silly)
<robimarko> There are fancy QCN9074 ones
<neggles> QCA2066
<\x> Q C A 6 3 9 1
<\x> ahaha
Larhzu has joined #openwrt-devel
<robimarko> Newer heard of QCA2066
<robimarko> Its not supported, there is no SDIO support currently
<neggles> that one is pcie
gromero has joined #openwrt-devel
<neggles> also known as WCN6856
<robimarko> Ahh
<robimarko> Then its supported
<neggles> tri-band DBS
<neggles> looks like HP are using them, NFA765
<robimarko> Those should be plug and play
<neggles> interesting that they're all key-E-only
<neggles> \x: QCA6391 is pcie as well it seems
<robimarko> Yes
<neggles> oh you guys might be interested in the BES2600iWA2
<robimarko> You have WCN6855/6, QCA6390/1 and QCN9024/74
<\x> neggles: heres something evil https://i.imgur.com/RMVXIaX.jpg
<neggles> the driver is a @#$#@ing nightmare at the moment, buuuuut... I have firmware sources
<\x> mini pcie to 2x mini pcie
<\x> i dont know what switch is used though
<neggles> wouldn't be shocked if there's no switch at all, looks like the bottom slot is wired for usb and the top for pcie
<neggles> also minipcie technically has two lanes
<\x> bottom is minipcie + usb, top is minipcie only
<robimarko> neggles: M.2 has 2 PCIe lanes
<robimarko> MiniPCIe only one
<neggles> hm. you're right. i guess the one two-lane impl i've seen was nonstandard.
<\x> the one where only usb is split is way cheaper https://i.imgur.com/0lo4dEY.jpg
<neggles> they ran a second lane over the usb3.0 pins
<\x> its like this one is mini pcie then one only gets usb
<\x> this one is 27 cny, the mpcie to 2x mpcie is 130 cny
<neggles> the two-pcie one is probably an ASM1182e
<neggles> 2.0 x1 up to 2x 2.0 x1 down
<stintel> neggles: I'm seeing one xd2-240 in UK, talking to a guy in Northern Ireland to get it from UK -> NI -> EU without customs :P
<neggles> what have i done
valku has joined #openwrt-devel
<neggles> I haven't even checked whether the bootloader's locked down or not yet >.>
<\x> here if you want to maybe install 4x mpcie cards on that ap330
<neggles> nah, no physical room
<neggles> the cards sink directly into cast-and-machined bosses in the chassis
<neggles> barely fit as-is, had to get some thinner thermal pads
<stintel> neggles: ~23EUR + shipping ... hard to resist :P
<neggles> why do you think i have one :P
<neggles> almost bought a 2nd one, but then i'd have to buy two more not-broadcom 4x4 cards
<neggles> and i mean. i have an XE5-8 and an XE3-4. *I do not need more access points!!!*
<stintel> :P
<neggles> the 4x4+4x4+4x4+4x4+4x4 w/2x5GbE is *enough* goddamnit
nitroshift has quit [Quit: Gone that way --->]
<neggles> still don't even have a 5GbE-capable switch...
<stintel> I do, feel free to borrow me those APs until you do :D
<stintel> heh 5-radio wtf
<stintel> but I'm gonna bet it's QCA ?
<neggles> yep
<neggles> IPQ8074A
<stintel> ok nvm ;)
<neggles> one 2.4ghz, two 5GHz which can be merged to 8x8, and two 4x4 5/6ghz switchable which will do 160mhz wide
<neggles> weird thing: the oem firmware lets you disable NSS?
<robimarko> It should via UCI
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (11.1% images and 100.0% packages reproducible in our current test framework.)
minimal has joined #openwrt-devel
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
slh64 has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
rua has quit [Quit: Leaving.]
slh64 has joined #openwrt-devel
guidosarducci_ has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
tlj has joined #openwrt-devel
tlj_ has quit [Ping timeout: 480 seconds]
xutaxkamay has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
xutaxkamay has joined #openwrt-devel
goliath has joined #openwrt-devel
rua has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
lucenera has quit [Quit: The Lounge - https://thelounge.chat]
lucenera has joined #openwrt-devel
Borromini has joined #openwrt-devel
noltari has joined #openwrt-devel
guidosarducci_ has joined #openwrt-devel
guidosarducci has quit []
<nbd> rmilecki: ping
minimal has quit [Quit: Leaving]
<rmilecki> nbd: pong
csharper2005 has joined #openwrt-devel
<csharper2005> What happened with ramips? Latest images are dated 30.01
<csharper2005> snapshots
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
digitalcircuit has joined #openwrt-devel
<Borromini> csharper2005: no errors in the buildbot logs?
fakuivan has quit [Remote host closed the connection]
csharper20051 has joined #openwrt-devel
csharper2005 has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
<csharper20051> Borromini: there is an error... I didn't understand the root cause
<Borromini> me neither but I'm seeing 'ModuleNotFoundError: No module named 'setuptools''
<Borromini> and make[5]: *** [scripts/dtc/pylibfdt/Makefile:33: rebuild] Error 1
<Borromini> for mt7621 e.g.
<Borromini> looks like some Python issue
<owrt-snap-builds> Build [#772](https://buildbot.openwrt.org/master/images/#builders/19/builds/772) of `ramips/mt7621` completed successfully.
<Borromini> lol.
<Borromini> a scentient buildbot :)
<Borromini> stintel: did you get mt7621 running reliably with 5.15?
<Borromini> IIRC you were onto some PPP issues with 5.15 and mt7621?
csharper20051 has quit [Ping timeout: 480 seconds]
<Mangix> rmilecki: ping
<stintel> Borromini: ppe
<stintel> Borromini: that's fixed
<rmilecki> Mangix: i'm going to sleep, please ping me tomorrow
<Borromini> stintel: alright, cool.
<Borromini> hopefully someone bumps ramips to 5.15 so we can watch things break. All my MT7261 stuff tested fine on 5.15 except for the odd radio not coming up (there's fixes for that)
<stintel> that pinned issue is becoming like a forum thread
<stintel> lots of random reports of broken stuff
<stintel> sigh
<Borromini> which one?
<fda> hey developers, you missed the new dropbear verison 3 months ago
<Borromini> fda: there's a PR AFAIK
<stintel> Borromini: the kernel 5.15 issue on gh
<Borromini> stintel: ok :-/
<stintel> ehr, or the ramips bump PR rather
<Borromini> :)
<Borromini> fda: feel free to add your Tested-by https://github.com/openwrt/openwrt/pull/11223
<stintel> I created a separate issue for the ppe thing and it was fixed within 2 weeks or so
<fda> i think i had this some times: "Fix long standing incorrect compression size check. Dropbear (client or server) would erroneously exit with "bad packet, oversized decompressed" when receiving a compressed packet of exactly the maximum size."
<Borromini> stintel: neat, other than that i didn't hear too many complaints about 5.15 on ramips. I haven't dared test my MT7620/MT7628 devices yet though :^)
<Borromini> don't feel like whipping out serial
<stintel> my EAP615-Wall and Unifi Switch Flex are running 5.15 also without issues
<fda> Borromini: thx! there are so much PRs
<stintel> Unifi 6 Lite not, I didn't get to flashing it while I was in Belgium
<Borromini> stintel: yeah EAP615 worked fine, EAP235 needed a fixup for one of the radios not coming up.
<stintel> and I rather not do it remote, at least not without being able to test locally first
<Borromini> i hear ya.
<stintel> Borromini: yeah that's a weird thing. the fix for 5.15 breaks things on 5.10
<Borromini> ok :-/
<stintel> so no matter what we do first, we introduce a regression that we need to fix later
<stintel> this sucks
<Borromini> so we drop 5.10 :^)
<Borromini> #yolo
<stintel> I'd be inclined to take the fix first, yes, as the plan is to drop 5.10 I'd say breaking 5.10 to fix 5.15 is favored
<fda> fritzbox 7320 has still 5.10!
<Borromini> the breakage will be limited to master no, so...
<Borromini> there's something to be said for it
<fda> the dropbear PR is really huge, i did not expect this by dropbear changelog
<stintel> Borromini: let me look into merging those 2 PRs
<Borromini> cool, thanks.
<Borromini> fda: i think the Dropbear PR does some housekeeping as well in addition to bumping (housekeeping related to the bump though from what I can tell)
<Borromini> gotta go
<stintel> hmm
<stintel> sleep() and delay() etc
<stintel> probably better that an expert looks at this
<dhewg> "some housekeeping"? have you looked at that thing?
<dhewg> that PR is like a new arch for ssh
<Borromini> dhewg: i am by no means an expert ;)
<Borromini> and feel free to weigh in of course
<Borromini> later guys
Borromini has quit [Quit: leaving]
groz has joined #openwrt-devel
<fda> i think the "Use modern crypto only [BREAKS COMPATIBILITY]" option is a good idea
robimarko has quit [Quit: Leaving]
<fda> but the scripting skills are beginner: dumb_stat() { ls -Lln "$1" | tr -s '\t ' ' ' ; } -- dumb_stat_owner() { dumb_stat "$1" | cut -d ' ' -f 3 ; } -- much easier ist the "stat" command: stat -c %U
hanetzer has quit [Quit: WeeChat 3.8]
<dhewg> I don't doubt the PR works as-is, but there're so many things it'll take days to test it
<dhewg> it should probably spit into bump with required changes and other additions
<dhewg> just imagine the hord of pitchforks if ssh access breaks ;)
rmb has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
rmb has joined #openwrt-devel
<slh> dhewg: mt7921au (in STA mode) can do around 750-800 MBit/s on 5 GHz (on 6 GHz currently only half of that with mt76), using an ivy-bridge Intel c1037u
<dhewg> nice, but I expected it to run far from it's potential on ipq40xx, that soc seems especially bad at usb thoughput
srslypascal is now known as Guest3307
srslypascal has joined #openwrt-devel
Guest3307 has quit [Ping timeout: 480 seconds]
<KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
bluew has joined #openwrt-devel
bluew has quit [Remote host closed the connection]
bluew has joined #openwrt-devel
Tapper1 has quit [Ping timeout: 480 seconds]