<hurricos>
It works! I'll bring my BSAP3040 in next time and i can halt it and dump memory, mind throwing me a build or should I just work from your most recent commit?
matoro has joined #openwrt-devel
bluew has joined #openwrt-devel
GNUmoon2 has joined #openwrt-devel
GNUmoon has quit [Remote host closed the connection]
<stintel>
hurricos: you are my hero!
<stintel>
hurricos: I can throw you a build ... on Sunday probably :p have some lunch and dinner dates planned in home country
<stintel>
x86/64 5.15 seems to cause disconnects on strongswan, anyone else experienced that?
<stintel>
only suspecting 5.15 at this point, will flash with 5.10 to confirm/deny that
Grommish has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
<mangix>
hrm I'm getting a negative reaction moving curl to mbedtls.
<mangix>
Unfortunate
valku has quit [Quit: valku]
<digitalcircuit>
slh: Small update - in the process of trying to build the v5.15 testing kernel for ipq806x/NBG6817, it looks like the WireGuard kmod dependencies might be broken ("* pkg_hash_fetch_best_installation_candidate: Packages for kmod-crypto-lib-curve25519 found, but incompatible with the architectures configured").
<digitalcircuit>
However, I can probably skip WireGuard for temporary testing since it didn't seem to be a necessary part of creating the Déjà Dup SFTP backup to USB drive crash.
<slh>
digitalcircuit: that looks more like some build artefacts than actual breakage
<digitalcircuit>
slh: Ah, good to know.
<digitalcircuit>
I did kludge the build a bit to remove two other packages that I don't use ("coova-chilli" and "xdp-tools") that were trying to be built - I'm guessing I haven't turned off all the right build flags from copying the normal release buildinfo.
<slh>
just don't do that ;)
<slh>
the buildinfo is rather useless for personal builds
<slh>
just way too much (read everything) enabled as package, 98% you'll never need
<slh>
a good small build won't take you more than half an hour to build, compared to multiple hours for everything and the kitchen sink, as well as 8-12 times more scratch space needed
<slh>
http://paste.debian.net/1248015/ that's pretty much everything you need (plus the additional packages you really want), save as .config, and off you go --> make -j$(($(nproc) + 1)) defconfig oldconfig download world
<slh>
(defconfig is an important step for expanding a minimal config to something kconfig wants to play with)
<digitalcircuit>
slh: Noted!
<digitalcircuit>
My initial reasoning was trying to mimic the official builds to reduce the delta (in case it affects the nondeterministic crash), but starting from that config makes sense if I continue to encounter errors.
<slh>
well, you can do that - it just takes ages for stuff you won't use anyways
<digitalcircuit>
Fair point! If I end up needing to do further builds, I'll definitely explore this
<slh>
admittedly, technically packages can enable features in the kernel (which is why this kind of dependencies is frowned upon), but... low risk
<digitalcircuit>
slh: It's a bit frankensteined (forgot to compile in ath10k firmware, fetched from snapshot repos), but I have a working v5.15 build on ipq806x! Time to do the test of 10 full backups from scratch.. again :)
<digitalcircuit>
(It bothers me I haven't managed to nail down the exact CPU/IO usage pattern that causes the crash, but ah well. Redoing my desktop's backups is not too unreasonable.)
cmonroe has quit [Ping timeout: 480 seconds]
<russell-->
there used to be a build target for all kmods
Grommish has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
mrnuke has quit [Remote host closed the connection]
<f00b4r0>
hmm; I'm going to bet this because I disabled CONFIG_IPV6
<f00b4r0>
yup, that was it
<f00b4r0>
seems like there's some config dependency borkage
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Grommish has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
<ldir>
disable IPv6? Heretic
<f00b4r0>
i know right :)
<f00b4r0>
I'll see if I can track this down later, I'm not particularly inclined going down this rabbit hole ;P
mrnuke has joined #openwrt-devel
borek has quit [Remote host closed the connection]
borek has joined #openwrt-devel
ldir has quit [Quit: Out of Cheese Error]
ldir has joined #openwrt-devel
ldir has quit []
ldir has joined #openwrt-devel
<kerneltoast>
f00b4r0: the packages added for router targets require CONFIG_IPV6
<f00b4r0>
kerneltoast: not sure what you mean. If disabling CONFIG_IPV6 in menuconfig results in unbuildable image, the dependency management is broken somewhere
<kerneltoast>
DEFAULT_PACKAGES.router
<f00b4r0>
i don't know what that is.
<jow>
f00b4r0: consider CONFIG_IPV6=n to be untested/broken
<jow>
we've also been discussing it's removal
<f00b4r0>
jow: now that makes sense :)
mrnuke has quit [Remote host closed the connection]
<jow>
personally I make no efforts anymore to make packages compatible with CONFIG_IPV6=n
<f00b4r0>
then we should probably remove that config option. No point in keeping around something that no longer works
<jow>
I agree, it should happen after the release
<kerneltoast>
f00b4r0: they're packages that are always included in the build if your DEVICE_TYPE is 'router', and some of them depend on ipv6
<f00b4r0>
jow: meanwhile I'm building an image with the backports, took me a bit longer than anticipated because of PEBKAC.
<jow>
great (testing the backport)
<f00b4r0>
kerneltoast: the error message relates to a missing kernel module during kernel build. It doesn't seem related to any specific package.
<f00b4r0>
s/package/userspace package/
<kerneltoast>
i roll with CONFIG_IPV6=n for my personal builds and those default packages included in the build were giving me the same error as you
<jow>
I think nftables packaging is broken for IPV6=n
<jow>
and it is unreasonably complicated to untangle
<f00b4r0>
makes sense
<kerneltoast>
jow: it's not that hard to untangle iirc from when i looked at it before
<jow>
kerneltoast: maybe
<jow>
however upstream loves shuffling netfilter modules around
<jow>
splitting them, merging them
<f00b4r0>
darn. I wanted to test via initramfs but it seems I can't get that to boot anymore. Let's be brave and flash.
<jow>
so it's playing dependency-whack-a-mole
<jow>
introduce conditional deps, fixes it for one kernel but breaks it for older or newer versions
<jow>
so you now need version specific conditional deps
<jow>
and now duplicate that exponentiated complexity for nft and ipt
<f00b4r0>
i see. I'll have learnt something new about the build system today then :)
<kerneltoast>
jow: but that isn't _currently_ an issue for nft and ipt with just toggling off ipv6
Gaspare has joined #openwrt-devel
<jow>
evidently it is:
<jow>
ERROR: module
<jow>
'/home/varenet/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_mikrotik/linux-5.10.131/net/ipv6/netfilter/nft_reject_ipv6.ko' is missing.
<kerneltoast>
see my link above, that's not the kernel's fault
<jow>
no body said that
<jow>
it's a packaging fault in openwrt
torv has quit [Remote host closed the connection]
<jow>
kmod-nft-core currently unconditionally includes nft_reject_ipv6.ko
<jow>
so nft_reject_ipv6.ko needs to be moved into a separate package
<jow>
then everything requiring it must conditionally depend on that new separate package
<kerneltoast>
ah, then i meant to say dependency whack-a-mole isn't a problem on the kernel's side as of now
<jow>
it is just too much maintenance effort
<jow>
nobody tests these nonstandard configurations
<f00b4r0>
i do
* f00b4r0
hides :)
* kerneltoast
is running CONFIG_IPV6=n
<jow>
yeah sure, and we apply a fix now
<jow>
with another few kernel bumps it is back
<f00b4r0>
i hear you. As I said, we should remove that config option
torv has joined #openwrt-devel
<jow>
kerneltoast: also maybe we're talking different things here
<jow>
there's a kernel-level CONFIG_IPV6 and there's an openwrt build system CONFIG_IPV6
<jow>
these options do different things
<jow>
the former builds a kernel without IPV6 awareness, the latter disables IPv6 support in random packages
<jow>
(in case these package honor it and lay out their dependencies, configure scripts, ifdefs etc. out correctly)
borek has quit [Quit: borek]
borek has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<kerneltoast>
i was thinking of both, because there's no point in keeping ipv6 in the kernel if userspace doesn't need it
<jow>
I think in 2022 there's no point in building ipv6-unaware userspace
* kerneltoast
cries
<f00b4r0>
jow: when trying to import a Peer config, it says "Cannot parse configuration: PrivateKey setting is missing or invalid"
<f00b4r0>
PrivateKey is not needed for Peers
<kerneltoast>
the Year of Ipv6 seems to be off somewhere with the Year of the Linux Desktop, so i think turning off ipv6 is still fathomable today
<jow>
f00b4r0: yeah, you probably need to relax that condition
<jow>
kerneltoast: I tihnk the effort providing that choice outweights the benefits
<f00b4r0>
it seems the Peer import is in fact the same as the global import (on the first tab of the interface setup)
<schmars[m]>
Is there even CONFIG_IPV4 that could be disabled? :-)
<jow>
f00b4r0: no, they do different things
<jow>
f00b4r0: that global import basically turns the router into a client of some existing wg server (peer), usually used when you import e.g. a config for a vpn provider or something
<f00b4r0>
If I drop a full config in the first, the server and the peers are correctly configured
<jow>
f00b4r0: that other import is meant to add additional peers to an existing setup
<f00b4r0>
I just imported a full server config
<kerneltoast>
jow: if no one's done anything for the ipv6 config in openwrt in ages then, all things considered, it's in pretty good shape right now
<f00b4r0>
i.e. the router is the server, and I defined extra peers
<jow>
f00b4r0: but I agree that the private key can be made optional there
<f00b4r0>
jow: s/can/must/
<f00b4r0>
peers *never* exchange their private keys
<jow>
I know that
<jow>
oversight
<f00b4r0>
in fact it should never be in the config, so the check should be inverted :)
* jow
rolls eyes
* f00b4r0
hides
<jow>
it is a convenience thing
<f00b4r0>
ok so just to confirm one thing:
<jow>
having the private key for a peer around means you can regenerate it's qr code, recreate its config to throw it into that system
<jow>
and yes, the textbook cryptonerd approved security solution would be to never have any
<f00b4r0>
when I click on "Import peer configuration", I get the *exact same popup wording* as when I click "Load configuration"
<jow>
but that's not what most uses requested/wanted, they do want convenience
<f00b4r0>
making it look as if they're one and the same
linusw_____ has joined #openwrt-devel
<jow>
yeah, should be changed
<f00b4r0>
ha
<f00b4r0>
if I try to load a pure server config in Load Configuration, without any peers defined, I get "Cannot parse configuration: PublicKey is missing or invalid"
<f00b4r0>
PublicKey setting*
cmonroe_ has quit [synthon.oftc.net graviton.oftc.net]
seer has quit [synthon.oftc.net graviton.oftc.net]
kenny has quit [synthon.oftc.net graviton.oftc.net]
hurricos has quit [synthon.oftc.net graviton.oftc.net]
MAbeeTT2 has quit [synthon.oftc.net graviton.oftc.net]
linusw____ has quit [synthon.oftc.net graviton.oftc.net]
Luke-Jr has quit [synthon.oftc.net graviton.oftc.net]
<jow>
it is either 'peer' (leave everything and just add a new peer section with material from the config) or 'client' (overwrite everything and turn wg interface into a peer of the server described in the config)
<jow>
depending on that, different texts should be presented
<f00b4r0>
ok. So basically from my current testing, the only situation that worked for me is dumping a complete config ([Interface] + [Peer]) into the first import. Other combinations fail.
<jow>
and for mode == 'peer' the privatekey check should be made optional
aiyion_ has quit [Remote host closed the connection]
aiyion_ has joined #openwrt-devel
<f00b4r0>
well dumping a bare [Interface] config also does not work, so there's some other test that seems to kick in needlessly
<f00b4r0>
I'm sorry I can't help more there, I just can't process JS.
<jow>
and what is the error if just a bare interface config is uploaded?
Slimey has joined #openwrt-devel
<jow>
ah, probably missing public key
<f00b4r0>
yes (pasted above)
<jow>
I suppose it could be made optional in client (overwrite all) import mode
<f00b4r0>
interestingly in the "complete config" test, the missing privatekey (for the peer) error does not show
<f00b4r0>
it happily imports the peer without its private key
<jow>
well the idea of the peer import is:
Grommish has joined #openwrt-devel
<jow>
upload the wg0.conf of the peer system, take the private key out of its [interface] section and derive the pubkey from it, create a new local [peer] section with the derived pubkey
<f00b4r0>
oic
<f00b4r0>
that's completely not how I understood (and used) it :)
<jow>
the wording should be changed in this mode
<jow>
it's really just meant to throw a wg0.conf from another machine at it to turn it into a suitable [peer] section that allows said machine to connect
<f00b4r0>
ah, now that makes sense
<f00b4r0>
let me check that
<f00b4r0>
hmm, but then it wants the PublicKey *and* the PrivateKey
<jow>
and the other one (import a wg0.conf and use it as own system config, e.g. for connecting to a vpn provider) is really overly strict and should allow importing configs without peers
<jow>
yeah, that can be fixed
<jow>
it currently always derives the pubkey from the privkey
Grommish has quit [Read error: Connection reset by peer]
<jow>
we could only do that if a privkey is in there, else use the pubkey as-is
mrnuke has joined #openwrt-devel
<jow>
however wouldn't such a wg0.conf be always manually vetted?
<f00b4r0>
the test I'm running is providing in Peer import the peer's "[Interface]" section, which only defines PrivateKey and ListenPort. It fails with "Cannot parse configuration: PublicKey setting is missing or invalid"
<f00b4r0>
did I misunderstand something again? ;P
<jow>
I mean a working one should always contain a PrivateKey, or?
<jow>
no, I think that should be fixed, we basically never need a public key
<stintel>
hurricos: <3
<f00b4r0>
jow: if I provide both Private and Public keys, I still get the missing or invalid message
Gaspare has quit [Quit: Gaspare]
<f00b4r0>
I double checked that the public key matches the private one
mrnuke has quit [Remote host closed the connection]
<jow>
f00b4r0: it's complaining about the pubkey from the first peer section (which can legitimately be missing)
<jow>
alltough it would be unusualy for a working, running wg0.conf I suppose
<f00b4r0>
in a working wg0.conf, the [Interface] typically does not store the PublicKey: it's not needed.
<jow>
I mean a working wg0.conf usually has at least one [Peer] section with a PublicKey =
<jow>
otherwise it would've nowhere to connect to
<Tapper>
jow if you are removeing ipv6 =n what about making odhcp and odhcpd-ipv6only one package? Or what about using dnsmasq for dhcp?
<f00b4r0>
so following what I understood from your comment above, I tried pasting the [Interface] section of a working wg0.conf into the "Import peer" system, and it claims the PublicKey is missing. If I provide the PublicKey *and* the PrivateKey, it still complains.
<jow>
the error is not about Pubkey in [Interface] (we derive that from PrivateKey) but PublicKey of first [Peer]
<jow>
the patch I pasted should fix that
<f00b4r0>
jow: sure, but here I'm only dumping the remote party's Interface section, since I'm obviously not importing their peers
<jow>
f00b4r0: yeah, so you've outsmarted it
<f00b4r0>
lol
<jow>
I didn't consider people truncating their configs
<f00b4r0>
oh i see, if I dump the full config it ignores the Peer sections
<jow>
right
<f00b4r0>
yeah the wording could really use some clarification ;)
<f00b4r0>
let me try to apply your patch manually on the system, see if that works
valku has joined #openwrt-devel
<jow>
(don't forget to clear your browser cache, page reload likely will not suffice)
<jow>
I've to run now, will check in later
<f00b4r0>
thanks, will keep posting here :)
<f00b4r0>
that worked
Luke-Jr has joined #openwrt-devel
<f00b4r0>
another bug I'm seeing when I click "add peer", if I then click "generate new key pair" the popup content disappears and only the 'Back' and 'Save' buttons are present. No matter which is clicked the new peer keys are added.
goliath has joined #openwrt-devel
Gaspare has joined #openwrt-devel
philipp64 has joined #openwrt-devel
philipp64 has quit []
philipp64 has joined #openwrt-devel
onemarcfifty has joined #openwrt-devel
onemarcfifty has quit [Remote host closed the connection]
Ibarakasen has joined #openwrt-devel
<Ibarakasen>
Hello. I am trying to solve a gstreamer-related mystery. On OpenWRT 21.02, any gstreamer related binary complains that external plugin loader failed. However, according to strace it tries to access /usr/lib/gstreamer-1.0/gst-plugin-scanner, but somehow gives up. This file does exist and if I set env GST_PLUGIN_SCANNER to this path, the complaining disappears.
mrnuke has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<jow>
f00b4r0: yes, that bug (empty popup) is due to lacking backports. I think cherry-picking 3be479446bdeaf446468c5e7ac3b9bc49da023da, f24606b1ffd59cc82c7251243a18f4cfdc4f78d5, 0c81e25faa9ff9cb6edec477d56145d70be87cf3 and f2fa59e89af3d4bdae9b12471184425b307ad5d6 will solve it
Grommish has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
Tapper has quit [Quit: Tapper]
<Ibarakasen>
Okay, I found something. According to strace it tries opening plugin scanner in /usr/lib, but then it tries executing the scanner in /usr/libexec.
<Ibarakasen>
The makefile for gstreamer installs the plugin to /usr/lib specifically.
<Ibarakasen>
[pid 4209] execve("/usr/libexec/gstreamer-1.0/gst-plugin-scanner", ["/usr/libexec/gstreamer-1.0/gst-p"..., ...], 0x7fffc6fe9e98 /* 10 vars */) = -1 ENOENT (No such file or dir)
<f00b4r0>
jow: it's entirely possible I did something wrong too. I used git cherry-pick --strategy=recursive -Xtheirs for all patches (the luci-proto-wireguard patches would otherwise not apply cleanly on top of 22.03)
<f00b4r0>
that resulted in cleanly-applying cherry picks
<jow>
f00b4r0: I will try to repro that myself at some later time, but right now I ran out of openwrt time
<f00b4r0>
no problem :)
<jow>
maybe stuff got incorrectly merged/nested
<f00b4r0>
let me know if I can help more. Although I'm afraid I'm a dead weight for anything JS related ;P
<f00b4r0>
i'd like to help because I think it'd be a very nice feature to have in 22.03