<nitroshift>
not enough coffee and it's too early to think
dorf has quit [Remote host closed the connection]
<mangix>
nitroshift: yeah that's normal
dorf has joined #openwrt-devel
<nitroshift>
i know, i got mixed up thinking they should be split between cpu0 and cpu1
<nitroshift>
ignore me
Luke-Jr has quit [Ping timeout: 480 seconds]
dedeckeh has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
<mrkiko>
karlp: does the reboot crash affects sysupgrades?
<mrkiko>
karlp: regarding ethernetp orts, I think the problem might be related to the driver or something. I remember having the same issue when I submitted patch to port TL-MR6400 V1 to ath79
<rsalvaterra>
'morning! :)
<rsalvaterra>
stintel: Hmm… maybe the size of your home network? ;)
pmelange has joined #openwrt-devel
<rsalvaterra>
aparcar[m]: In addition to those targets you mentioned in the commit message, I also tested binutils 2.37 with ath79/generic and mvebu/cortexa9, so I'm pretty confident it's fine.
<mangix>
rsalvaterra: it's already merged
<rsalvaterra>
I know, I just saw it. :)
<rsalvaterra>
There's a dark side to the musl bump for the early adopters… after it, doing a build without a complete wipe will likely cause runtime issues.
<mangix>
switch LED control over GPIO == OK,. switch LED control over registers == NO.
<rsalvaterra>
Yeah, I know, but what can we do when the LEDs aren't connected to GPIO?
<mangix>
i wonder if there's a way to fake it. probably not.
<mangix>
rsalvaterra: those LEDs are connected to the switch. They're not separate GPIOs
<rsalvaterra>
I was thinking about that, but I don't really know. I think that's what Andrew Lunn meant with his email, that we had to somehow abstract the way LEDs are physically connected.
<aparcar[m]>
rsalvaterra: let me know if the tool works for you
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
<rsalvaterra>
FFS, am I the only one to hate those useless GitHub merge commits?!
<rsalvaterra>
Trying to see the history of a specific directory, only this sh*t comes up.
<rsalvaterra>
Jeez…
<mangix>
I think even Linus had a similar complaint recently.
<mangix>
Honestly merge commits should be disabled.
<rsalvaterra>
*Why where they even enabled in the first place? o_O*
<rsalvaterra>
Let me guess… defaults.
<mangix>
yep
<mangix>
squash and rebase was disabled but merge commits were not.
<stintel>
rsalvaterra: haha
<rsalvaterra>
Guys, can we please make the future a bit less insane, since we can't change the past? :P
<mangix>
in come the turris people complaining about GPG signatures.
<aparcar[m]>
mangix: yea don't do it. Stop using this merging pleease
<aparcar[m]>
mangix: you rebase locally, resign it all good
<mangix>
that's not the issue
<mangix>
that would just replace the original committer's signature with mine
<rsalvaterra>
aparcar[m]: I just mentioned auc to a friend who manages several dozens of OpenWrt routers and APs in production. O:)
nitroshift has quit [Quit: Gone that way --->]
<aparcar[m]>
tell the friend to sponsor me a faster server :P
<mangix>
how fast is your current one?
<aparcar[m]>
4 cores, HDD (very slow), ram is not an issue
<mangix>
painful
<aparcar[m]>
correct
<rsalvaterra>
aparcar[m]: Hmm… server load likely won't be an issue (in his case). It's a public institution, they do MITM (with full disclosure to the staff) with a wildcard certificate, so they're probably able to cache the images locally.
<aparcar[m]>
oh the server caches all images as well
<aparcar[m]>
still a x86 images takes up to 10 minutes because all the file system creation is so slow...
<rsalvaterra>
Ouch… so slow? :/
goliath has joined #openwrt-devel
pmelange1 has joined #openwrt-devel
<mangix>
rsalvaterra: sounds like the 3600 I use is actually amazing.
pmelange has quit [Read error: Connection reset by peer]
pmelange has joined #openwrt-devel
<rsalvaterra>
mangix: Oh… why is that?
<rsalvaterra>
(I love it, but I'm obviously biased. :))
<mangix>
12 cores > 4
<rsalvaterra>
AMD <3
<PaulFertser>
The Intel server at work builds OpenWrt ramips/mediatek image in less than 8 minutes from scratch ;)
nitroshift has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
<aparcar[m]>
well my server just uses the imagebuilder so it's not that fancy, mostly IO I think
<PaulFertser>
52 cores (2 SMT threads each)
pmelange1 has quit [Ping timeout: 480 seconds]
<PaulFertser>
But I agree, Intel be damned, no joy to work with them at all.
dedeckeh has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<karlp>
mrkiko: no, the sysupgrade completes, then it reboots into the new kernel (I can see the compile time changed) then it crashes, but not on all rebuilds. it's definitely a bug somewhere, but absolutely not something I'm interested in chasing. once it's reset once from uboot, it reboots happily "forever" without crashing.
<karlp>
the port link detection is likely something simple, there's a ton of ar9331 devices, and a ton of similar devices with the same switch, but I don't know the right dts invocations, and I was going nohwere trying to cargo cult plausible snippets around.
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
<mangix>
huh
<mangix>
./scripts/dl_cleanup looks interesting
pSych0bUNny has quit [Remote host closed the connection]
<Habbie>
so, 5 hours for a -full clean rebuild- of the entire packages tree? that's pretty neat
<Habbie>
i assume this means that anybody on an image snapshot from before the musl bump suddenly cannot use the snapshot packages feed
<karlp>
snapshots are like that, yes.
<karlp>
they're a snapshot, not a magically rolling release you can stably use
<karlp>
but you can sysupgrade to a new one...
<Habbie>
i figured/assumed, thank you for confirming
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Habbie>
so, if a package has a patch that is no longer necessary with musl 1.2.2, i can drop it from the package? or should i take users on -releases- building packages from -master- into account?
<karlp>
nope, they can learn their lessons :)
<Habbie>
hah, ok
<Habbie>
this works for me :D
victhor has joined #openwrt-devel
<stintel>
yeah, if we'd have to support that, we'd be making it really hard for ourselves
<Habbie>
well, yes, i get that
<karlp>
I do that in my own packages feed, so that I don't have to have branches there, but it's not at all scalable in general :)
<Habbie>
but i could also choose to just keep this patch for a bit longer
<Habbie>
but if i'm alone in even trying, i won't bother
<karlp>
yeah, don't bother.
<rsalvaterra>
mangix: Having your tree as another remote is a pain. I use autocomplete to checkout my 5.10-bump branch and you have a branch named 5. I keep checking yours out instead of mine. xD
kenny has joined #openwrt-devel
Tapper has joined #openwrt-devel
<rsalvaterra>
stintel: Well, I'm fscked. I'm getting a bump from 200/20 Mb/s to 500/100 Mb/s. I'm not sure if my Omnia is having it (with cake, of course). :P
<SwedeMike>
rsalvaterra: 500/100 should work with cake, it did on my wrt1200ac (unless there's been a performance regression of course, I tested it back 3-4 years ago). You can't go much higher though.
<mrkiko>
karlp: don't know if you replied to me and I might have lost your replies
<SwedeMike>
rsalvaterra: and if CAKE doesn't work, just use fq_codel (I do that with 900/900 on my wrt1200ac)
<rsalvaterra>
SwedeMike: Could be worse, I guess. :) I'd avoid fq_codel, if possible, since cake is better at flow identification/isolation.
<SwedeMike>
mmm, and 900 down ingress flow handling is marginal with the wrt1200ac, I should change back to my APU2 sometime
<stintel>
rsalvaterra: told you to get an m300 ;)
nitroshift has quit [Quit: Gone that way --->]
<rsalvaterra>
stintel: Glad you're here! You're an expert in device trees, right? :)
<rsalvaterra>
… and if I understood correctly, if I remove the pause property from from a fixed-link, pause frames will be disabled by default. Right?
<stintel>
rsalvaterra: I don't know anything about device-tree :P
<stintel>
rsalvaterra: but that is my conclusion yes
<rsalvaterra>
You're bringing up the M300, I assure you you know more than me. :P
<stintel>
the description for full-duplex gives a hint
<rsalvaterra>
Yep! I just wanted to make sure, but it feels like the correct interpretation.
<stintel>
when absent, opposite is assumed
<stintel>
I am struggling to understand uci, once again
<rsalvaterra>
What's with UCI?
<stintel>
well I inherited some code that uses uci in lua for state tracking but without using commit, I think that will cause the state file to ever grow and eventually cause oom or enospc, trying to fix that but it's driving me up the wall
<stintel>
documentation is limited as always
<stintel>
I've tried adding commit, but now I'm not even seeing the state nor config file
<stintel>
also probably not the best idea to do it like that, but I'd first like to get the current code in a kind of working state, and then I'll think about how to do it differently
aleksander has quit [Quit: Leaving]
jbowen has joined #openwrt-devel
pmelange has quit [Quit: Leaving.]
Slimey has quit [Read error: Connection reset by peer]
Slimey has joined #openwrt-devel
Slimey_ has joined #openwrt-devel
Slimey_ has quit [Read error: Connection reset by peer]
Slimey_ has joined #openwrt-devel
<stintel>
sigh. test VM behaves differently than the AP
Lynx- has joined #openwrt-devel
Slimey_ has quit [Read error: Connection reset by peer]
Slimey_ has joined #openwrt-devel
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
<Lynx->
hey gents - I have managed to router->LAN ingress away from my lan interface (veth0) to 'br-lan', but how do shift LAN->router ingress from veth0 to 'br-lan'?
<Lynx->
(where veth1 is a member of 'br-lan')
Slimey has quit [Read error: Connection reset by peer]
Slimey has joined #openwrt-devel
<dwfreed>
I don't understand why you're putting yourself through all this pain
Slimey has quit [Read error: Connection reset by peer]
pmelange has joined #openwrt-devel
Slimey has joined #openwrt-devel
<Lynx->
dwfreed how do you mean?
Slimey has quit [Read error: Connection reset by peer]
<Lynx->
just trying to get CAKE/SQM to work with VPN PBR
Slimey has joined #openwrt-devel
<Lynx->
even though this isn't that weird - it is challenging to get to work properly
Slimey has quit [Read error: Connection reset by peer]
Slimey has joined #openwrt-devel
Slimey has quit [Read error: Connection reset by peer]
Slimey has joined #openwrt-devel
<dwfreed>
Why not just apply SQM to the LAN interface rather than the WAN? (with the numbers reversed)
<Lynx->
dwfreed I can, but router->LAN and LAN->router traffic is then shaped
<dwfreed>
and how significant is that in reality? :P
Slimey has quit [Read error: Connection reset by peer]
<Lynx->
well I have samba share
<Lynx->
and I like to test router -> lan performance
Slimey has joined #openwrt-devel
<dwfreed>
It is possible to exempt things with fwmarks, but you then have to make your own SQM script to add the exemptions
<dwfreed>
might still be less pain than what you're trying to do :P
<Lynx->
dwfreed I found I if I make 'veth1' member of 'br-lan', and set 'veth0' to my main LAN IP, then I can have router -> LAN traffic sent from 'br-lan' - that works. But I can't figure out how to get LAN -> router traffic not ingress on veth0. Is that actually technically impossible?
<dwfreed>
You probably have to do something with network namespaces to get what you want to work correctly, which is probably very unsupported by OpenWrt
<ynezz>
list of all libtool packages would be quite longer I assume
<ynezz>
to me it looks like breakage of libmnl
<ynezz>
granted I've just checked few packages, but the error is same, missing libmnl
<ynezz>
configure: error: Package requirements (libmnl >= 1) were not met:
<ynezz>
and libmnl fails due to target-arm_arm926ej-s_musl_eabi/libmnl-1.0.4/build-aux/missing: line 81: automake-1.14: command not found
<ynezz>
so probably some esoteric libtool usage in the libmnl which needs to be ironed out?
<mangix>
Nope. It's more than libmnl
<mangix>
libtool 2.4.2 vs 2.4.6 breaks API. It's probably not compatible since OpenWrt uses an old automake
<mangix>
Or maybe something is wrong with the patches. Who knows.
dorf has quit [Remote host closed the connection]
<mangix>
One way to work around these failures is to remove autoreconf.
<jow>
or to stop needlessly updating that autotools
<jow>
the bump commit cites no reason why libtool was updated
<jow>
other than that the one we use is from 2015
<jow>
and wouldn't disabling autoreconf effectively revert packages to wahtever ancient upstream libtool they ship with? rendering the libtool update mostly moot in the first place?
<will[m]>
a mythic jow appears just as i have a useful question lol
<will[m]>
jow: any hint on getting in6_addr to display an ipv4 in host byte order, and getting uint16_t port #s into host byte order? i've got a bunch of 100.10.168.192:20480 that would really love to be 192.168.10.100:80
Tapper has joined #openwrt-devel
<will[m]>
banging on htons() seems only partly useful
<jow>
uhm... context?
<jow>
htonl() for in_addr.s_addr, htons() for the port
<jow>
but without knowing what you actually do and want to achieve it is just guessing :)
<will[m]>
> 'struct in6_addr' has no member named 's_addr
<jow>
and you want to print them?
<will[m]>
yeah i'm writing a program that interfaces with netfilter / netlink / conntrack and your nlbwmon seems like the best example out there to cut my teeth on it all
<will[m]>
not a lot of people seem to use in6_addr for their programs... i like it, but the google results are sparse
<will[m]>
it's outputting, just in backwards order. 🎶 so close i can almost taste it 🎵
<jow>
well I just put both IPv4 and IPv6 addresses into a struct in6_addr
<will[m]>
yeah i'm a big fan
<jow>
and I also convert IPv4 to big endian so that the database has the same format on all architectures
<jow>
for your custom program you likely just want to remove the htobe32() conversions
<will[m]>
ahhhhh
<jow>
to not convert the IPv4's to big endian in the first place
<will[m]>
no wonder google thinks i'm crazy ok
<jow>
and once that conversion is gone, you can simply use inet_ntop(AF_INET/AF_INET6, in6_addr_ptr, buf, sizeof(buf))
<will[m]>
amazeballs! it works as it should now
<jow>
where buf should be at least INET6_ADDRSTRLEN bytes long
<will[m]>
i didn't consider that your parsing functions would be doing anything unique. thanks a lot!
<will[m]>
btw speaking as a user instead of coder, is it an unreasonably large hurdle to have nlbwmon store and report conversation bytecounts like (my laptop) <=> (netflix) : 400gb this month ?
kenny has quit [Quit: WeeChat 3.2.1]
<will[m]>
i'd imagine the database would be 100x bigger for sure
<jow>
code wise? no
<jow>
I think you just would need to extend struct record to contain a destination ip as well
<jow>
and extend the netlink conntrack parsing code to store the dest ip as well instead of discarding it
<will[m]>
ok cool. maybe when i ascend to valhalla and have unlimited free time i could contribute something like that
<jow>
problem is defining "netflix"
<will[m]>
thanks for your help lately, i will sing your praises
<jow>
you'll most likely end up with hundreds or thousands of reconrds connecting to different IPs
<will[m]>
oh yeah i guess i meant the respective IPs, rather than some kind of intelligent grouping
<will[m]>
the GUI would have to do some aggressive drilldowns to make it more than a pile of mush for sure
<jow>
problem is database size, that's why nlbwmon does not really try to preserve details
<will[m]>
exactly
<will[m]>
i wrote something similar internally with syslog -> logstash -> sql and the sky really is the limit on db size when you do such things
<mangix>
jow: wolfSSL update mandates libtool 2.4.2 which is compatible with the 2.4.0 previously in the tree. I have no idea why he decided to bump it to 2.4.6
<jow>
I am quite sure this is nothing that can't be solved with a sed one-liner
<jow>
used to do the same for gettext in the past
<jow>
personally I would never touch autoconf, automake or libtool without a very good reason
<jow>
a single package with a stupid version constraint in configure.ac is not a good reason
<jow>
anyhow, need to run again - bbl
Borromini has left #openwrt-devel [#openwrt-devel]
Luke-Jr has quit [Ping timeout: 480 seconds]
kenny has joined #openwrt-devel
pmelange has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
Luke-Jr has joined #openwrt-devel
danitool has joined #openwrt-devel
<hauke>
mangix: I haven't chekced that libtool is really the problem, but it is very likly
<hauke>
the problem has to be there since multiple days
Tapper has quit [Ping timeout: 480 seconds]
pmelange has quit [Quit: Leaving.]
Tapper has joined #openwrt-devel
<mangix>
hauke: it's either that or my autoconf-macros update. Maybe it's both. But I think most of the problems are from the libtool update.
mangix has quit [Remote host closed the connection]
mangix has joined #openwrt-devel
<rsalvaterra>
mangix: ping
<rsalvaterra>
I just noticed an interesting behaviour with the DSA status quo on my WDR3600… :)
<mangix>
rsalvaterra: saw
<mangix>
i think someone broke dnsmasq
<mangix>
oh nvm. it's not dnsmasq that's broken
<mangix>
it's wifi
<dansan>
hanetzer: hello!
<dansan>
Can anybody tell me where this hash value in build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/packages/ipkg-mipsel_24kc/kernel/CONTROL is generated? "Version: 5.4.143-1-344a8e677903a8f375f8c2c8dae8d7ca" I see where it's written in include/package-ikpg.mk, but trying to trace down it's origin.
<hanetzer>
dansan: is that not a git hash?
<dansan>
hrm
<dansan>
I actually never considered that, lol!
Tapper has quit [Ping timeout: 480 seconds]
<dansan>
nope, not a git hash :)
<hanetzer>
hehe. how did that whole u-boot/openwrt thing I helped you out with turn out?
<dansan>
Oh my! I have to try to remember. ehem. "Hello brain. Do you remember anything about a u-boot issue?"
<dansan>
lol!
<dansan>
I'm pretty sure it got solved, but there's been a few thousand other things since then.
<hanetzer>
dansan: had to do with irridium sats :)
<dansan>
Yeah!
<dansan>
Yeah, that's what my company works with, Iridium sats.
<dansan>
I sent vogon poetry to space yesterday :D
<dansan>
xmitted that is
<hanetzer>
those poor aliens.
<dansan>
lmao!
<dansan>
Oh, I'm sure they've seen worse at this point!
<hanetzer>
my recent interest is a ryzen x570 board which includes a realtek rtl8117 management/bmc-like chip that runs openwrt
<dansan>
Really?
<hanetzer>
yep. asus x570 pro ws ace, if you're interested.
<dansan>
So a sort-of extra little computer/router on the same board?
<hanetzer>
yep. like how 'serious' servers have an ast2500 bmc on them.
<hanetzer>
its mips-like; lexra (doesn't have those patented unaligned load/store instructions)
<hanetzer>
probably not as full featured as that, but it does have remote management caps (power on, power off, kvm-over-ip [you can watch the bios screen even], can flash the ryzen bios) so its really interesting from the perspective of a coreboot/etc developer. oh, and it has a documented/supported superio chip and a *real* com port header.
<dansan>
So it's apparently in the VERSION set prior to calling BuildTarget/ipkg (include/package-ipkg.mk) which I appears to be called by BuildPackage (include/package.mk), which appears to be set to the value of BuildKernel (include/target.mk)...
<hanetzer>
is this vendorware?
<dansan>
Oh wow, that's cool!
<dansan>
So much to learn!
<dansan>
lol, what's "vendorware"?
<hanetzer>
dansan: ever download a sdk/bsp for a given soc, and it was full of badly mangled kernel/u-boot/packages?
<dansan>
oh, yikes!
<hanetzer>
that's vendorware.
<mangix>
I see what's happening
<mangix>
someone broke hostapd
<aparcar[m]>
mangix: me?
<aparcar[m]>
mangix: master seems fine again
<dansan>
Well, this is for a new product -- we still have a long way to go before we will release. Going to try to get as many of my changes mainlined as I can and then release the rest for GPLing.
<hanetzer>
well if you ever need help/rubber ducking feel free to hit me up.
<dansan>
hanetzer: I've got a lot of neat patches. I have an option where you can specify the external kernel tree, but tell it that you actually want to populate it by cloning upstream, and then applying all of the quilt patches as git commits. This makes kernel dev and debugging SO SO much easier!
<dansan>
I've got a series of kernel debugging support patches as well.
<hanetzer>
yeah. my last adventure in kernel debugging was bisecting amdgpu.ko. took a while, encrypted rootfs.
<dansan>
Then when you're ready for a release-type build, you run "git format-patch" on your external kernel repo add the kernel patches to the appropriate target/linux/ patch directory
<mangix>
aparcar[m]: about to test. I think https://git.openwrt.org/?p=project/netifd.git;a=commit;h=06d11bbf1f2b61dcdb1b7088eec539fcd00b28a0 is the problem
<dansan>
yikes!
<dansan>
Sorry I can't chit chat much right now. I'm on the clock and have to fix this problem. :(
<dansan>
hanetzer: definitely need to get caught up though! :)
mangix has quit [Read error: Connection reset by peer]