<will[m]>
anyone have any idea why netlink (nlbwmon) would stop reporting bytecounts in event messages? it works with stock openwrt but in my custom build it reports family/proto/dst_port/src_mac/src_addr... but not out_bytes/in_bytes. as if a driver or kmod was missing. any ideas where i should start looking? the major difference in my build is that i removed a bunch of ubox and init stuff because i need to run my own services without the default
<will[m]>
stuff, but i don't see why that affects kernel networking byte metrics
<slh>
if you enabled flow offloading, that would be one explanation.
minimal has quit [Quit: Leaving]
<hurricos>
Hey -- can someone look over my device tree? I'm trying to load ath10k caldata with nvmem-cells
<neggles>
hanetzer: yeah but you want to make it explicit which image to use; either by having multiple images that mostly differ in name and the compatible= string in the DTS, or by renaming the DTS/image to something more generic
<neggles>
hurricos: hi
<hanetzer>
neggles: I mean, on the ar71xx target a few hw's shared a mach
<neggles>
I'm turning into a sort of devicetree perfectionist lately...
<hanetzer>
well, its better than mach :)
<neggles>
hanetzer: yes'm, but "the initialization for these is identical" =/= "this hardware is identical", and telling people to flash an image marked "nanostation" to their nanobeam will confuse them
<hanetzer>
I wish someone had the magic for vlan-trunk-over-wifi :)
<neggles>
that can be made to work fairly easily
dangole_ has quit [Ping timeout: 480 seconds]
<hanetzer>
because man fudge this stock firmware.
<hurricos>
I'm going to try one more thing
<hurricos>
it looks like I got the pci address wrong
<hanetzer>
I was under the impression their proprietary bs allowed for that, but that's not the case.
<hurricos>
but failing that I'll post it here :^)
<neggles>
hanetzer: so you'd probably want to name the image/target "ar9342_ubnt_airmax-loco-m-xw.dts" / "Ubiquiti AirMax Loco M devices" and list the different models
<neggles>
hurricos: okeydokey ping me if/when you do :P
<hurricos>
It'll compile in 10, I'll let you know then heh
<hanetzer>
neggles: do tell, if you know how. I've been fucking around with it like half a day
<neggles>
hanetzer: AirMax *does* allow for VLAN trunking but AirMax is also *bad*
<hurricos>
wait, err
<hurricos>
so for a PCI device
<hanetzer>
yeah but I can't fookin get it to work and their webui keeps shitting itself on getting an ip
<neggles>
first question is, how many VLANs
<hurricos>
pcia000:02/a000:02:00.0/a000:03:00.0 -- what reg is that?
<hanetzer>
5 total, but only like, 3 that *need* to make it across.
<hanetzer>
security, mgmt, 'general lan'
<hurricos>
I'm basically reading the apm821xx tree's device trees and trying to figure out what reg property I give wifi1 here:
<hanetzer>
security is for a dvr/nvr (cctv), mgmt is the mgmt interfaces for the various devices, 'general lan' is well, generl lan.
<neggles>
hanetzer: so if you put it into airmax p2p bridge mode, it will transparently pass all VLANs and you can set the mgmt interface VLAN
<neggles>
i would need a screenshot of your config page
<neggles>
hurricos: 2 tics lemme just check something
<hurricos>
:D
<schmars[m]>
neggles: we do precisely this all the time with various ubiquiti device in freifunk berlin. i don't have a config screenshot handy though :)
<hanetzer>
neggles: there's no tic for p2p bridge on this device (nbe-m5-16, aka loco m xw in owrt parlance)
<hanetzer>
so if you know how to do it in openwrt I'm all ears :)
<neggles>
hanetzer: problem is i've forgotten what the settings page looks like
<neggles>
but it's basically the default airmax mode
<neggles>
on openwrt, i would set up VXLAN or EoIP bridging
<neggles>
there's also umm ath79/dts/ar7161-aruba_ap-105.dts line 104
<neggles>
yay this one has an oem bootlog
<hurricos>
I wonder, should I map out the topology in the device tree?
<hurricos>
It's rather shallow, just the PCI bridge: Freescale Semiconductor Inc P1010 (rev 10) above the card.
<hurricos>
I assumed the pci0 and pci1 were already doing that. Freescale has that magic pre-/post-dtsi stuff
<neggles>
hurricos: based on the bootlog from the ap105, and its dts, you were right and you want wifi@0,2
<neggles>
but you'll need the compatible= "pcivenid,devid";
<neggles>
hanetzer: uhhhh ok hang on
<hanetzer>
neggles: I'm very dumb so please label lmao.
<hanetzer>
dumb like my APs
<Namidairo>
I wonder how much removing those rf shields and that extra cap near the power affects the design
<Namidairo>
you know, apart from the BoM savings...
rua has joined #openwrt-devel
<hanetzer>
neggles: on the locoxw porting front. I suppose a sed -e 's:Nanostation:Nanobeam:g' -e 's:nanostation:nanobeam:g' nanostation-loco-m-xw.dts > nanobeam-loco-m-xw.dts and adding the makefile bs should be enough?
<hanetzer>
since I know the nanostation firmware can correctly init the hw
<Namidairo>
if they're similar enough you could just device_alt it
<hanetzer>
because under ar71xx, it didn't even distinguish the nanobeam part. just Ubiquiti Loco M (XW)
<neggles>
yeah, i would just make the one DTS file without the name in it, and refer to them as what they are
<neggles>
AirMax Loco M
<hanetzer>
so git mv & edit?
<neggles>
don't really need to git mv since you'll be squashing all of this into one commit anyway for merging
<hanetzer>
no I mean, git mv the nanostation-loco-m-xw.dts to airmax-loco-m-xw.dts is what I mean.
<hanetzer>
or should it still be a distinct dts file?
<hurricos>
hahahaha nothing works :(
<neggles>
hanetzer: yes, do that
<hanetzer>
neggles: which? distinct file or shared file?
<neggles>
ah sorry, shared
<hanetzer>
k. sounds good.
<hanetzer>
y'know, for 'hot sauce in a plastic package', the taco bell diablo(? black package) is pretty spicy and not half bad.
<neggles>
git mv it and just change the compatible= to say "AirMax Loco M Devices" then probably edit the makefile to use DEVICE_ALTx_MODEL
<neggles>
hanetzer: okay i believe i have got this sorted
<neggles>
here's the AP side. we are lowkey cheating here by using multicast for the vxlan peer address so you don't have to do any other config, but you may wish to use direct unicast.
<hanetzer>
ok, so question. what is 239.1.1.1?
<neggles>
that would be multicast group
<neggles>
so you can either change that to <IP address on other side of link> or leave it
<neggles>
in this example I am passing vlans 10, 20, 30, 40 across the link, and vlan 10 is being used as mgmt
<hanetzer>
ah, dhcp
<neggles>
yeah you can change that to static
<neggles>
you can drop "force_link" from the vxlan0 if you like as well
<hanetzer>
and, the 'same' config on the other device?
<neggles>
yes, except you make it a wifi client and you change peeraddr
<hanetzer>
and the peeraddr is just 'made up'?
<neggles>
so 239.0.0.0/8? 4? is multicast groups. multicast is voodoo magicks.
<neggles>
in this case it's how you'd allow for multiple far-side clients.
<hanetzer>
ah. so other side, 239.0.0.2 would be sufficient?
<neggles>
you either use 239.1.1.1 both ends
<neggles>
or if you have the 'wlan' IP of AP on 172.17.1.1, and client on 172.17.1.2, you would set peeraddr to the *other* device's IP
<neggles>
AP would have wlan IP 1.1, peeraddr 1.2, client has wlan IP 1.2, peeraddr 1.1
<hanetzer>
gotcha.
<neggles>
i should note i've not actually tested this entirely.
<hanetzer>
that being said. the port of the switch that plugs into eth0 of either. is that an access port or a trunk?
<neggles>
trunk in my case
<hanetzer>
if this bacons my saves I'll be forever grateful :)
<neggles>
if you want mgmt to be on the untagged vlan, change "option device 'br-lan.10'" to "option device 'br-lan'"
<neggles>
i would highly recommend not applying this blindly/without serial console
<hanetzer>
heh. well, I've become a bit skilled at just doing the tftp recovery :)
<neggles>
you should be able to factory with the button
<neggles>
or failsafe mode
<neggles>
but if you have them deployed already, first thing I would do is create a new SSID on the AP, put it in the new/not-yet-existing 'wlan' network, assign IP to that network
<hanetzer>
well, the devices are positioned 'just right' and I don't feel like taking them down lmao
<neggles>
so drop the 'config interface wlan' block into /etc/config/network on the AP to create the new interface, `service network reload`, then add a new SSID and attach it to that 'wlan' network rather than 'lan'
<hanetzer>
so that I can get in wirelessly even if it fuggs up eh?
<neggles>
kinda
<neggles>
yea
<neggles>
the idea is to not lose remote-side access or near-side access
<neggles>
so 1) `opkg install luci-proto-vxlan`; 2) drop the config interface 'wlan' and config interface 'vxlan0' blocks into /etc/config/network on both devices and restart, configure AP SSID, configure client's wifi client interface to connect to that SSID
<neggles>
then make sure you can ping from one to the other over the new interface
<neggles>
since this is a new/custom image, probably go bake luci-proto-vxlan into your image :P
<neggles>
actually lets not flood this channel with config help :)
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
ekathva has joined #openwrt-devel
valku has quit [Quit: valku]
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
goliath has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
amaumene has joined #openwrt-devel
pepe2k has joined #openwrt-devel
danitool has joined #openwrt-devel
danitool_ has joined #openwrt-devel
robimarko has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
pepe2k has quit [Ping timeout: 480 seconds]
guidosarducci_ has quit [Remote host closed the connection]
guidosarducci has joined #openwrt-devel
pepe2k has joined #openwrt-devel
<rsalvaterra>
aparcar[m]: Updated your dnsmasq branch (new upstream patches) and rebased on current master.
Tapper has joined #openwrt-devel
pepe2k has quit [Remote host closed the connection]
pepe2k has joined #openwrt-devel
pepe2k has quit [Read error: Connection reset by peer]
<xback>
each part is split out identically as handled in the kernel config
<robimarko_>
LGTM, I can drop my package
<robimarko_>
Looks like its time to make a PR to add ath11k
<xback>
i'll just edit mhi-bus to make the debug stuff optional on selection
<robimarko_>
Personally, I think that debug should be left on
<robimarko_>
Without it, there are no messages as far as I remember nor debugfs
<xback>
aah ok
Misanthropos has joined #openwrt-devel
<hanetzer>
compatible=qcom,ipq807x-hk07
<robimarko_>
hanetzer: Was it accidental copy/paste?
<hanetzer>
nope. just grabbed the dtb out of the firmware update I thought didn't have a kernel :)
<hanetzer>
binwalk is busted :/
<robimarko_>
If it was QSDK then the FW update will always have kernel as well
<hanetzer>
hadda search for 0xd00dfeed and dd it out :)
<robimarko_>
Binwalk is probably confused because if its NAND based its inside of UBI
hexa- has joined #openwrt-devel
<hanetzer>
pretty easy. find the offset of 0xd00dfeed, the next 32 bits is the size. dd if=in.bin bs=1 skip=$((0xd00dfeed-offset-in-hex)) count=$((size-in-hex)) of=out.fit (or out.dtb)
<hanetzer>
fit images will have two d00dfeed's. one for the whole fit image itself, one for the dtb in the fit.
<robimarko_>
Or you can just use ubireader to extract the images from volumes and then use the python based extract-dtb tool
<hanetzer>
true.
ecloud has quit [Ping timeout: 480 seconds]
<hanetzer>
but yeah, binwalk is foobaring on ubi, I guess. ubireader works.
<stintel>
/go tap_
ecloud has joined #openwrt-devel
<hanetzer>
finally figured out dumpimage's usage properly
<hanetzer>
(from u-boot)
<neggles>
hanetzer: yeah binwalk eats itself and dies on ubi
<neggles>
especially ubifs with endianness mismatch
rua has quit [Quit: Leaving.]
Grommish has joined #openwrt-devel
<Slimey>
my putty.log is 12GB
<hanetzer>
Slimey: heh.
<hanetzer>
putty is telnet/ssh/serial for windows right?
<Slimey>
yeah
<hanetzer>
nice.
<rsalvaterra>
Whoa. Managed to shave off another 20 kB from dropbear.
<karlp>
"it only allows logins from clients built against tomorrow's unreleased ssh key style, but that's ok" :)
<rsalvaterra>
Actually, I think it was just by disabling SHA-1 HMAC (keeping only SHA-256).
<rsalvaterra>
Nobody should be using SHA-1 in 2022 anyway…
<Grommish>
There are people using Chaos Calmer in 2022 ;p
<jow>
sure
<jow>
s/people/vendors/
<rsalvaterra>
Grommish: Loads of undiagnosed insanity out there. :)
<Grommish>
jow: *nod*
<Habbie>
i -doubled- the linux kernel version by installing openwrt on a box the other day ;)
<Habbie>
.. and i installed 18.06
<Grommish>
rsalvaterra: haha Indeed
* jow
fondly remembers brcm-2.4
<rsalvaterra>
Habbie: That's admirable, in a sad kind of way… :P
<rsalvaterra>
Fondly?!
<Habbie>
rsalvaterra, 88 kbyte free after install - but i was happily surprised to find luci in that 4MB image :D
<Grommish>
rsalvaterra: I got many of those side-long looks of "Are you OK?" with rust
<jow>
ancient kernel, buggy uclibc, proprietary wl.o, nvram
<jow>
fun stuff
<rsalvaterra>
Grommish: I didn't exactly write you off as insane, I was more "skeptical that you could, yet intrigued that you may". :P
<Grommish>
jow: I have a question.. I'm getting closer to this rust-lang toolchain. Assuming the buildboxes aren't going to be able to build and store for download, is there a way to have the local build reuse the distro archives I generate instead of rebuilding the whole thing each time?
<Grommish>
rsalvaterra: Oh, dear sir, it's been working for a while, at least on mips64 :D its the rest I am unsure about
<jow>
Grommish: I guess so
<jow>
iirc we're doing similar stuff with the bpf toolchains
<Grommish>
jow: I will check there then!
<jow>
but I really dislike the trend of introducing more and more precompiled toolchains
<jow>
we can as well ditch buildroot entirely then, building own cmake and tar and the one hand and reusing precompiled llvm toolchains on the other
<rsalvaterra>
Hm… Long as it takes, I rather compile the BPF toolchain too… and it does take forever.
<jow>
either completely from source, or completely precompiled
<rsalvaterra>
More than doubled my build times.
<Grommish>
rust-lang takes about 2-3 hours to build from source because of the concern about pre-compiled
<rsalvaterra>
(From scratch, that is.)
<jow>
but compiling the "simple" stuff jsut for the sake of it is a waste of resources imho
<Grommish>
per target
<Grommish>
or arch I should say
<jow>
Grommish: totally makes sense. maybe we should introduce phase0 builders to do weekly toolchain builds or so
<Grommish>
I went into it not needing to rely on the buildbots or being stored, but someone mentioned it and I wanted to explore it.. or at least reusing what archives I do create during the initial process
<jow>
actually toolchain and the rest of openwrt should get decoupled anyway imho
<jow>
one process to do the whole gnu tar, cmake, gcc, ebpf-llvm, lzma, firmware-utils etc.
<Grommish>
I figure the amount of poeple who might use rust-lang is so small right now, I don't see why the resources shoudl be spent
<jow>
another to build kernel and packages
<jow>
Grommish: I'm just worried a bit about reproducibility
<rsalvaterra>
Guys, how do you generate those pretty commit messages (with the hashes and subjects) for the "bump to latest git HEAD" type of changes?
<Grommish>
But, re-using the built resources would be preferable to rebuilding
<jow>
I've no problem with making use of precompiled toolchains per-se, but ideally they should be built semi regularily by the project
<jow>
monthly, or whenever there's actual updates
<Grommish>
Ok.. I'm not there yet anyway, but I wanted to see what options I might have towards the endgoal. right now, changing my branch in feeds/packages to update the PR triggers a rebuild :D which is a pain, but not insurmountable
rua has joined #openwrt-devel
<olmari>
I use buildroot every once in awhile fir making my builds, I love the idea of compiling stuff needed, only then van be exctly sure and also if needed optimized... Wouldn't middle ground be compiling most everything where needed and use thoe until new stuff introduced on particular tool after which, compile :)
<Grommish>
But I use the distro archives I package to do the actual install after the build (their x.py install doesn't work right) so I have the archives broken down by host and target archs alreaady separately
<Grommish>
In theory, it's pick and mix as you need for what you're building at that point
danitool_ has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<rsalvaterra>
olmari: All my mounts have been noatime for the last 10+ years, and I've never had any issues whatsoever. ;)
<rsalvaterra>
The atime concept itself is just silly, especially nowadays, with flash storage.
<olmari>
mm.. I mostly use relatime per default, some very high speed stuff I consider noatime because IDK... maybe time to ocnsider noatime per default =)
<rsalvaterra>
Like the man himself wrote: "For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!".
<rsalvaterra>
Nowadays there's also lazytime, for people who *really* want access times.
<rsalvaterra>
(And haven't been forbidden to use a computer yet. :P)
<Slimey>
heh
<robimarko_>
xback: Thanks
pepe2k has quit [Remote host closed the connection]
<aparcar[m]>
nbd: does the option also influence the vmlinux creation?
<rsalvaterra>
Is anyone working on bringing up Linux 5.15 on ath79 yet?
<Slimey>
i have
<xback>
rsalvaterra: ath79 was done by ynezz. I have converted and test ath79 mikrotik and pushed it. currently updating and testing generic_nand with 5.15
<xback>
to be accurate: ath79_generic was done by ynezz
<rsalvaterra>
LOL! Yeah, I just checked the log and totally missed it. :)
<xback>
ath79 generic_nand is currently building for test, and if all works i'll push that one on thursday probably
<rsalvaterra>
I wonder how the DSA conversion will work on top of it… might as well try it.
<rsalvaterra>
Heh… it's just device tree and kconfig changes. Should be fine. :)
<rsalvaterra>
Time to kill the WDR3600, I guess…
<hanetzer>
huh. the firmware is riddled with .gitignore files :)
cmonroe has quit [Ping timeout: 480 seconds]
<nbd>
aparcar[m]: yes
<hanetzer>
nand devices scare me a bit. no easy 'put a clip on it and use flashrom' lmao
<neggles>
olmari: the list of things which care about atime is very, very short
<neggles>
basically a few misc DBs, mongo i think maybe?
<neggles>
and a few catastrophically ancient utils
B1773rm4n has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
goliath has joined #openwrt-devel
danitool has joined #openwrt-devel
<olmari>
Thanks.. I think I'll reimport my zfs root all by noatime and enable on datasets only if certainly needed.. (welcome to 2000s I guess ;D /
Borromini has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
rua has joined #openwrt-devel
Borromini has quit []
Borromini has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Tapper has joined #openwrt-devel
<mangix>
Wonder if btrfs has flash friendly mount options
slingamn has quit [Quit: leaving]
hanetzer has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest1274
srslypascal has joined #openwrt-devel
lmore377 has quit [Quit: No Ping reply in 180 seconds.]