csharper2005 has quit [Read error: Connection reset by peer]
<hurricos>
rsalvaterra: surprised your ath10k cards crap out at all
<rsalvaterra>
hurricos: QCA9880 devices are notoriously unstable. As is pretty much all QCA 802.11ac wave 1 hardware.
<rsalvaterra>
They're usable with the ath10k-ct driver and respective firmware, but still suffer from (recoverable) firmware crashes from time to time, especially with WPA3.
<hurricos>
Iunno. I had an Unifi AP-AC-Pro with >300d and no radio resets, and it's our building's main AP
<hurricos>
I say had because a gust of wind reset it ;(
<hurricos>
Ah, WPA3 might do it
<hurricos>
I've always been unsure what to think about complaints of instability about QCA9880 / QCA9890
<hurricos>
particularly when the backdrop is mwl8k / mt76 / b43 / rt2800 ....
<rsalvaterra>
Oh, they're definitely unstable in certain configurations. I'm just no trading WPA3 for WPA2 with stability. :)
<rsalvaterra>
*not
<hurricos>
Yeah, we got more than one complaint about WPA3 making new iPhones unable to see the WiFi (and that's on ath9k).
<stintel>
ahh, think I found the reason for sigill ... have a musl patch in my m200 branch, to disable altivec, but I need to make package/toolchain/clean after switchting to said branch
<hurricos>
dirty branches strike again
<hurricos>
I'm sure I messed up the config.
<rsalvaterra>
hurricos: My network doesn't cater to fashion accessories. :P
<hurricos>
oof
<hurricos>
:D
<hurricos>
Unfortunately I cater to tenants :P
srslypascal has joined #openwrt-devel
<hurricos>
so we keep around such options as "skip_inactivity_poll '1'" :\
<rsalvaterra>
I have a guest network with WPA2, they can play in that sandbox. :)
<stintel>
meanwhile tested fit images on the M200, seems to work. now to enable that for the m300, that would require people who already run openwrt on m300 to change their u-boot env on the next sysupgrade ... is this acceptable? or better provide both fit and non-fit images for a while, with planned phaseout of the non-fit images?
<rsalvaterra>
Jokes aside, my experience with mt76 has been mostly stellar.
<stintel>
aye
<hurricos>
stintel: is u-boot-env partition (if any) r/w?
<stintel>
it is
<hurricos>
make users use fit
<hurricos>
lol
<stintel>
and u-boot envtools preconfigured
<hurricos>
you can add a COMPAT_VERSOIN
<hurricos>
you can absolutely give them the message for how to update the bootcmd
<hurricos>
if you want to be fancy and give something copy-pastable, you can see such cursed examples as target/linux/mpc85xx/image/p1020.mk / hiveap-300
<hurricos>
though that example is a little excessive
<hurricos>
I say "cursed"; they're just sort of ugly.
matteo has joined #openwrt-devel
<hurricos>
Also, while I say "they", afaik this is the only example of a copy-pastable script transferred via the image metadata
<hurricos>
rsalvaterra: any availability of mPCIe mt76 wnics?
<hurricos>
I don't even need DBDC, just a 3x3 11ac
<hurricos>
if you have recommendations on that particularly, lemme know. I'm going to bite the bullet and order one, what's the worst that can happen?
<rsalvaterra>
hurricos: Having to wait a while until all features are supported? The driver is still being developed/optimised, but it works. I think stintel has a MT7916 device, some EAP.
csharper2005 has joined #openwrt-devel
<hurricos>
Right. I don't mean to be dismissive, I've shied away from mt76 mostly because I just don't have easy access -- vendors don't tend to litter the world with them as independent cards.
<hurricos>
there's essentially no faith in them in enterprise APs at this point in time
<hurricos>
other than u6lite, but those are a disaster
<hurricos>
other than Ubiquiti stuff, but ubiquiti is a disaster*
<hurricos>
I think part of the point is that the boards "do not go EOL" -- mt76 is supposed to be so strongly software-driven that it "lasts a whole generation"
<hurricos>
but mediatek's SDK is :barf:
<stintel>
have you met QSDK? :P
<hurricos>
so I'm unsurprised not to see it more frequently in vendors' products
<hurricos>
lol
<rsalvaterra>
I've had a very smooth experience with MT7603 and MT7615 devices, on my Redmi AC2100.
<hurricos>
Yeah, I'm just saying, where I interact with OpenWrt is massively available enterprise EOL devices.
<Slimey>
:P
<hurricos>
it's just where I am, it's not that I intentionally avoid mt76, it's that I never encounter it
* rsalvaterra
sees stintel's QSDK and raises his Broadcom SDK
<hurricos>
hey brcmfmac is great
<hurricos>
if you like only having one SSID and feeling like death
<rsalvaterra>
To be honest, I haven't *seen* the SDK… only what comes from it, and it's horrible. :P
<hurricos>
also: same chip in two devices? same chip? you think so? nope, we tweaked one tiny thing. Good luck loading the same NVRAM
<hurricos>
11 variants of WNICs in M1 Macs
<hurricos>
11
<stintel>
whehe
<hurricos>
you can see why I might still enjoy a QCA9890 sometimes :^)
<rsalvaterra>
God, why the fsck did have to build a Mac around the M1? Such a lovely SoC…!
<hurricos>
LOL
<hurricos>
unrelated but
<hurricos>
I found an at91sam9g25 in a LoRaWAN gateway I'm supposed to be installing
<Namidairo>
I cringe whenever I see a mt76 issue complaining something does not work like "blah blah person's build with the vendor driver"
<Grommish>
Namidairo: Just suggest they use that build if it works for them :D It's easier than trying to explain proprietary vs opensource to people who really don't want to listen
<Grommish>
I had issues with those types of poeple when I did Android ROMs, and that was the spiel we gave to them regarding things other ROMs had that we didn't particular want when they complained
<Namidairo>
I thought you usually kept the vendor wifi on Android custom roms
Luke-Jr has joined #openwrt-devel
<Grommish>
Depends on the vendor.. A lot of the camera drivers early on were prop, for example
<Grommish>
I stopped dev'ing ROMs when Google changed the testing process to be per-device, per-build.. Wasn't worth the issues it caused, and then OEMs started seriously locking down bootloaders and I was done with it
<Namidairo>
yeah I remember seeing wrapped 4.0-era camera blobs to get them to run on 5.0+
ecloud has quit [Ping timeout: 480 seconds]
<neggles>
Grommish: ah that'd do it
<neggles>
you need terminfo :P
<neggles>
weird that it reports 0x0 though, it should default to 80x24... i guess I can make it clamp the minimum?
ecloud has joined #openwrt-devel
<Grommish>
neggles: It only reports 0x0 without stty on TeraTerm.. if I SSH into the box, it reported fine :)
<Grommish>
neggles: But, I know you had questioned it and since I figured out the why finally hehe.. It does make thing like nano so much easier to use
<neggles>
yolo: if you're using WSL2, have you set the number of vcpus for the WSL2 VM in $Env:HOME/.wslconfig ? and are you building from the VM's internal filesystem or from a path under /mnt/* (which will not work)
<neggles>
honestly for stuff like openwrt builds there's not a lot of benefit to doing WSL2 over just running linux in a hyper-V VM
<Namidairo>
defs don't do it on their paths to your ntfs filesystem
<Grommish>
neggles: Except Hyper-V VMs doesn't work on Home editions AFAIK
<Grommish>
and WSL2 does
<Grommish>
neggles: I don't care for PuTTY though :D
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
<Grommish>
neggles: PuTTY doesn't offer Kermit/Ymodem transfer via Serial, does it?
<Grommish>
I had bricked the itus to the point I needed to actually use ymodem via uboot to transfer the image
<Grommish>
and once I had TeraTerm setup, I just never looked back
slate has quit [Quit: quit]
cbeznea has joined #openwrt-devel
<hanetzer>
anyone have a Ubiquiti Nanostation Loco M (XW) on hand? I'd like to see its bootlog.
<hanetzer>
reason being, I have what seems to be a similar, if older, device, on owrt 19.x and I'm looking to port it from the ar71xx platform to ath79, along with newer openwrt
<Grommish>
Who/What is Freifunk Berlin?
<Grommish>
Interesting..
dedeckeh has joined #openwrt-devel
<slh>
Freifunk is a collection of communities maintaining free wireless access infrastructure in Germany (each town/ region has its own group, there is little to no wider organizational structure). they build heavily on OpenWrt (with their own forks of it, gluon is larger one) and add meshing capabilities and usually routing infrastructure through their hardware (to achieve ISP status and shield the
<slh>
participants donating their freifunk running APs and internet access from legal issues)
<Grommish>
slh: Thanks! Someone posted regarding wanting to contribute to rust testing, but I had never heard of it. So, this would be a good thing
<slh>
isn't that kind of the red headed stepchild? from the turnover between rt2x00 and mt76
<PaulFertser>
Probably, but there's enough boards still sold with t.
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
<rmilecki>
jow: nbd: would you expect UCI section "switch_port" with "pvid" to have no effect if put above UCI section "switch_vlan"?
<rmilecki>
it seems swconfig set "pvid" of switch ports to the "vlan" of the first UCI section "switch_vlan" that follow "switch_port"s
<rmilecki>
seems quite non-intuitive to me
<jow>
rmilecki: intuitively no, but since I know how the driver operates in the background it does not surprise me
<rmilecki>
jow: by driver do you mean netifd? swconfig?
<jow>
swconfig & its kernel backend
<rmilecki>
ok...
<hanetzer>
future reference: openwrt's source has no mechanism for disabling services at build time. this is a feature of imagebuilder alone, for now.
shoragan has joined #openwrt-devel
<jow>
rmilecki: likely writing the vlans resets the pvid information again
<jow>
rmilecki: the swconfig drivers are often very simple, they don't build an internal stae from uci and then apply it completley but translate uci into register writes piece by piece
<rmilecki>
ahh, you just reminded me of that weird swconfig CLI / API
<jow>
so if the pvid section comes first, it'll write some pvid info into vlan registers
<jow>
then it processes a vlan section, programs the vlan registers again and implicitely resets the pvid info again
<jow>
stuff like that
<rmilecki>
"swconfig dev switch0 set apply 1" or whatever it was
<rmilecki>
jow: that makes sense, i'm not sure if i really want to fix it..
<ynezz>
hanetzer: shouldn't be hard to add, take a look at prepare_rootfs in include/rootfs.mk
<hanetzer>
ynezz: true.
<ynezz>
hanetzer: that $(3) is basically DISABLED_SERVICES="" from image builder
<hanetzer>
how fudged am I if I install an image with firewall enabled?
<hanetzer>
(dumb AP)
Tapper has joined #openwrt-devel
<hanetzer>
that being said. with swconfig being retired in favor of dsa, what's the userspace tool to do 'swconfig dev switch0 set apply 1' and so on?
<neggles>
hanetzer: you can install an image with or without firewall and it's fine, and you can use the /etc/uci-defaults/xx_custom method to disable services during firstboot
<hanetzer>
ah that's neat.
<neggles>
most single-port devices default to configuring that port as LAN, on 192.168....1?.1 with dhcp server etc enabled
<neggles>
which I personally low-key hate, but I understand why
<hanetzer>
yeah, same.
<hanetzer>
imho one-port devices should be dhcp clients by default lmao
<Grommish>
neggles: You can set target/linux/xxxx/base-files/etc/board.d/01_network
<hanetzer>
yeah, we're aware.
<neggles>
why override files in the repo when I can just run my xx_custom firstboot script?
<neggles>
it sits happily in the tiny repo scripts/env creates
<jow>
rmilecki: you don't want to fix it
<hanetzer>
good news everyone. I didn't break it.
<jow>
swconfig architecture has many warts, but given that it is a technological dead-end, I wouldn't invest precious time into it
<neggles>
pretty much all my build dirs have a slightly different spin on the same script; it does whatever basic network config i'd like it to, sets the hostname to <device>-<2nd half of MAC address>, sets the timezone and NTP servers, kills the IPv6 DHCP server / prefix delegation, generates a root password and echoes it out on console
<neggles>
works quite well
<Grommish>
neggles: *nod*
<neggles>
and i don't have to remember to replace it when I change branches :P
<Grommish>
I used to use files/ but I'd forget with testing and found it was convoluting things
<hanetzer>
anywho. I just flashed an ath79 ported ubnt_nanobeam-loco-m-xw image into my live network. It picked up just fine :)
<Grommish>
hanetzer: Nice!
<Grommish>
Congrats
<hanetzer>
on the other side of it (its a point to point wireless device) I had 8 security cameras lmao
<neggles>
i'm surprised any of those nanobeams are still alive tbh
<hanetzer>
and now that I know it works, I can do it to the client side
<Grommish>
I'm trying to see if I can get the eBPF toolchain to work with surcata :)
<dangole>
jow: i saw you have tagged v0.0.20220331 in ucode repo. are you going to update to package in OpenWrt to build from that tag any time soon? I'm asking because I
<dangole>
'm just realisizng that 'uvol' is now broken due to old version of ucode in OpenWrt builds...
rua has quit [Quit: Leaving.]
bluew has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<hanetzer>
https://dev.archive.openwrt.org/ticket/19085 anyone know offhand what commit fixed this bug? I want to make sure I'm not introducing it again in the ath79 port of the device :)
minimal has joined #openwrt-devel
<hanetzer>
the simple check of doing a git log -p and searching for '#19085' returns nothing :)
<hanetzer>
hrm... unless I'm mistaken the ar9342_ubnt_nanostation-loco-m-xw.dts and (my prospective) ar9342_ubnt_nanobeam-loco-m-xw.dts can just be rolled into one device.
<hanetzer>
nbd: I believe 2135e54c0001d7c8a18c05bcff0b8944a526dcef is your work, and fixed the above referenced bug?
<jow>
dangole: yes, I plan to push it today or tomorrow
<jow>
dangole: can take care of creating an uval forward compatibility PR
<jow>
dangole: but I can't runtime test
<dangole>
jow: I'm working on it atm, having one device with bleeding-edge ucode and one with in-tree ucode. only remaining problem is the different start of ARGV, so in old version first few elements of ARGV need to be skipped. also that should be done in some minutes :)
<jow>
ah okay, great
<torv>
dangole: Thank you! It all worked/s like a charm.
<jow>
btw, you can use optional chaining operators to prevent code like if (foo.bar) use foo.bar.baz
<jow>
replace it with foo.bar?.baz
<karlp>
that's cute :) I love it
<dangole>
jow: fancy
<jow>
or for dynamic subscripts foo[bar][baz] use foo[bar]?.[baz]
<karlp>
does an eval just get null / false if it fails out early?
<pepe2k>
dangole: ping, could you point me to a place where I can find U-Boot boot commands for BPi r64? I'm interested particularly in how the dtso is selected from fit (sata vs. pcie)
<cbeznea>
hi! is there a way I can fetch the config of a particular build (that is failing) from buildbot?
<aparcar[m]>
cbeznea: not when it was never built, try CONFIG_BUILDBOT=y
<ynezz>
don't do that if you want your toolchain deleted and build it from scratch
<ynezz>
cbeznea: something like this: printf 'CONFIG_TARGET_at91=y\nCONFIG_TARGET_at91_sama7=y\nCONFIG_ALL_KMODS=y\nCONFIG_ALL_NONSHARED=y\nCONFIG_TARGET_ALL_PROFILES=y\nCONFIG_IB=n\nCONFIG_SDK=n\nCONFIG_BPF_TOOLCHAIN_NONE=y\n' >> .config
<ynezz>
cbeznea: IIUC and you're going to fix that sama7 build breakage
<ynezz>
cbeznea: I think, that `CONFIG_ALL_KMODS=y` should exhibit the error we're seeing on the buildbot
<jow>
before doing the above, ensure to ./scripts/feeds updata; ./scripts/feeds install -a
<jow>
to enable out of tree kmods
<jow>
and rm .config before
<ynezz>
feeds are not relevant for phase1, are they?
<jow>
they are
<jow>
kmods from feeds are
<ynezz>
ok, that's quite a news to me, never used feeds for build testing
<jow>
phase2 builders can't produce kmods
<jow>
I mean technically they can but since the artifacts are shared among different arches, they're thrown away
<jow>
kmods have to be produced individually for each arch in phase1
<jow>
and that includes kmods from feeds
<ynezz>
cbeznea: anyway you likely need to refresh the kernel configs with `make kernel_oldconfig CONFIG_TARGET=subtarget`
<ynezz>
cbeznea: looks like you've CONFIG_BRIDGE=m in the sama7 config which is built-in in generic config
<cbeznea>
ynezz: thank you! on my side it builds correctly on both master and 22.03 with no config changes
<ynezz>
cbeznea: it's little bit more tricky, you need to build in verbose mode, `make V=s -j512`
<cbeznea>
I'll check with your proposals
Tapper has quit [Ping timeout: 480 seconds]
<cbeznea>
ynezz: ok
<cbeznea>
I'll try that, too
<dangole>
pepe2k: There can be several dtbo in the FIT image and several configurations, then you select the configration as parameter to `bootm` in U-Boot. see commits 4e6de4f0938, 6890f6fe13b, b40f707f71d, 6890f6fe13bb, b40f707f71d4 and 41af8735d4b0
<ynezz>
cbeznea: in other words, you need to build in verbose mode to spot any kernel config issues, that's what buildbot does
<pepe2k>
dangole: thanks, will check that! I have support for multi-dtb for our build/fit command and just need to find out whether this won't break your multi-dtbo support
<cbeznea>
ynezz: thanks! I'll check that
<dangole>
pepe2k: i got the R64 on my desk anyway, let me know if I can do some testing.
<pepe2k>
dangole: will do, thanks!
Tapper has joined #openwrt-devel
srslypascal is now known as Guest1170
srslypascal has joined #openwrt-devel
Guest1170 has quit [Ping timeout: 480 seconds]
pepe2k has quit [Quit: Leaving]
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
castiel652 has joined #openwrt-devel
pepe2k has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
<neggles>
hanetzer: for that you'd probably want to make an ar9342_ubnt_airmax-loco-m-xw.dtsi and #include it in the two device specific ones, or make ar9342_ubnt_nanostation-nanobeam-loco-m-xw.dts possibly