<Tusker>
hurricos: I was thinking, to get over the gunzip issue with the kernel, would using the okli loader as an intermediate step solve the problem ? Does the okli loader get it's own new memory space ?
<Tusker>
FYI - the AP370 runs into the same OOM for gzip too
<philipp64>
dhewg: can't use "procd_add_reload_interface_trigger" because I don't know a priori what interfaces named is going to listen to, so I assume "all of them".
<Slimey>
yo
jlsalvador2 has joined #openwrt-devel
jlsalvador2 has quit []
jlsalvador2 has joined #openwrt-devel
jlsalvador2 has quit []
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Ping timeout: 480 seconds]
jlsalvador2 is now known as jlsalvador
jlsalvador2 has joined #openwrt-devel
jlsalvador has quit [Ping timeout: 480 seconds]
jlsalvador2 is now known as jlsalvador
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<Tusker>
hurricos: so, for the ap370, need to patch both uboot binaries, in two locations (due to A/B). I am going to build a non-compressed kernel image version of 5.10.x sysupgrade, with a big "kernel" partition (will try and get it to work with an appended dtb)
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
Luke-Jr has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
victhor has quit [Ping timeout: 480 seconds]
lmore377 has joined #openwrt-devel
Andi_ has quit [Ping timeout: 480 seconds]
Andi_ has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<Tusker>
hurricos: OK, have 5.10.x booting on ap370 now, will push my commit
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<dhewg>
philipp64: dunno about bind, but usually you have a uci config entry to specify what interface a daemon is listening on, and you just use that then
<philipp64>
Yeah, in the case where UCI handled all the config... but bind is too lengthy and complicated for that.
<dhewg>
I guessed ;) That solution looks like a bit like a sledgehammer though
<dhewg>
is "reload" not sufficient?
<philipp64>
No... as Noah said a few hours ago, once named detects interfaces and opens sockets, it lowers privilege... once in that lowered state, it can't open another socket on a reserved (<1024) port...
<philipp64>
there might be a fix using libcap where that capability can be reserved, but... I'd be surprised if that could be done and the Bind folks didn't already think of it.
dangole has joined #openwrt-devel
<philipp64>
See capabilities(7) in particular, CAP_NET_BIND_SERVICE
<Tusker>
philipp64: why not use the rndc control ?
<philipp64>
What would using rndc change?
<Tusker>
maybe I misunderstood the problem, though I thought rndc could control bind post startup and priv drop, and if you need to have it listen on new interfaces, then restart it ?
goliath has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
hgl has quit [Remote host closed the connection]
hgl has joined #openwrt-devel
marinelli has quit [Quit: marinelli]
freesky-edward has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Tusker has quit [Ping timeout: 480 seconds]
Tusker has joined #openwrt-devel
freesky-edward has quit [Remote host closed the connection]
<ldir>
rsalvaterra: no 10.76 bump yet? What's going on? :-D
<rsalvaterra>
ldir: Manual refreshing is going on. XHCI, mainly. A bit paiful, this time.
* rsalvaterra
will need to double-check the bcm27xx target…
<stintel>
haha, as usal
<stintel>
usual*
<rsalvaterra>
*painful
<rsalvaterra>
mangix: Yep! Seems like a complete 802.11ax implementation, this time.
rua has quit [Quit: Leaving.]
Andi_ has quit [Remote host closed the connection]
Andi_ has joined #openwrt-devel
goliath has quit [Ping timeout: 480 seconds]
<ldir>
rsalvaterra: phoo yuck is all I can say then. Good luck.
<stintel>
alright, my Unifi 6 Lite is again completely dead. enabled all the panic_on_ stuff, and reboot on panic is after 3s (openwrt default), still the thing just goes unreachable and that's it
<stintel>
why did I break my rule of not buying shit without RJ45 console again :/
<rsalvaterra>
Different quirk patches sharing the same bits. Fsck my life.
gladiac has quit [Read error: No route to host]
gladiac has joined #openwrt-devel
<rsalvaterra>
And then upstream starts to use the *same* bit(s).
<rsalvaterra>
Anyway, I edited our patches to avoid conficting bit definitions. Hopefully they'll be upstreamed before upstream starts to use the respective bits. Again. :P
<stintel>
dangole: hitting https://bugs.openwrt.org/index.php?do=details&task_id=3943 again on my apu2 at my parents' place. commenting out the lines containing jail in the init script works around the problem again. can you suggest anything to look at?
<stintel>
the Unifi 6 Lite load average doesn't seem to drop below 1
<rsalvaterra>
stintel: Uh? What's keeping one core so busy?
<stintel>
not that uncommon, seen that many times before, never figured out how to find the cause however
<stintel>
but pretty sure it's a bug in some kernel component
minimal has joined #openwrt-devel
<Habbie>
aparcar[m], 'flask janitor update' in asu just sits there, strace shows select(0, NULL, NULL, NULL, {tv_sec=594, tv_usec=328835}, any clues?
<Habbie>
aparcar[m], webinterface offers me no branches, Latest versions: []
Tapper has quit [Ping timeout: 480 seconds]
<Habbie>
aparcar[m], ah, a 600 second sleep is default in the janitor, i didn't expect this to be a long running process
<Habbie>
aparcar[m], ok, so -i 0 makes it exit quite quickly indeed
<Habbie>
aparcar[m], ah! I needed a config.py with some BRANCHES in there
<Habbie>
aparcar[m], i'll PR doc improvements later
Tapper has joined #openwrt-devel
ashkan has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
shibboleth has quit [Quit: shibboleth]
<dangole>
stintel: the output of `ps aux | grep dnsmasq` in FS#3943 shows that dnsmasq itself is not even running, but only the ujail wrapper. does the ujail process stay even if you stop dnsmasq?
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<rsalvaterra>
Context: iptables rules, match port vs multiport. What's faster? Multiple port rules, or one multiport rule? I'd say the latter, but it's likely someone around here knows better. :)
<jow>
the latter is faster
<rsalvaterra>
jow: Thanks for the hint. :)
rua1 has joined #openwrt-devel
<rsalvaterra>
I guess is high time I UCIfied my firewall.user… getting ready for firewall4.
<rsalvaterra>
*it's
Tusker has quit [Quit: Time wasted on IRC: 15 hours 17 minutes 2 seconds]
rua has quit [Ping timeout: 480 seconds]
Dgrey has quit [Read error: Connection reset by peer]
rsalvaterra_ has joined #openwrt-devel
rsalvaterra is now known as Guest4186
rsalvaterra_ is now known as rsalvaterra
<rsalvaterra>
Gah. I have rules which are basically impossible to express in UCI. *facepalm*
<rsalvaterra>
This way, I make sure the firewall has to be working for these services to be accessible. A bit safer, in my humble opinion.
<jow>
(change lan to tor)
<jow>
becomes iptables -t nat -A zone_lan_prerouting -p tcp ! -d 192.168.17.1/255.255.255.255 -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m comment --comment "!fw3: Tor transparent bridge" -j DNAT --to-destination 127.0.0.1:2080
<jow>
(w/ lan instead of tor)
<rsalvaterra>
Hm… will fw4 play nice with these more complex rules?
<genuser1>
Question, if I write a bash script that runs in the background of owrt, what is the best/proper way to output to the system log?
<jow>
rsalvaterra: fw4 will ignore "option extra" since it cannot be interpolated into nft commands
<jow>
genuser1: (produce lots of lines) | logger -t my_ident
<jow>
genuser1: or logger -t my_ident "My message"
<jow>
rsalvaterra: we coould think about support tcp flag matching natively though since it is rather common
<genuser1>
thanks jow. Just what I needed :)
dangole_ has joined #openwrt-devel
<jow>
if I see it correctly, that particulr tor rule should degrade somewhat nicely, it'll overmatch but should still produce the correct result
<jow>
I mean if the nft equivalent of --syn is not applied
<rsalvaterra>
Sure, it will work, albeit not as efficiently as possible.
<rsalvaterra>
However, efficiency is important for the systems we target too…
<stintel>
dangole: good catch, there is only the ujail process, not dnsmasq itself
<stintel>
dangole: the ujail process stays after first /etc/init.d/dnsmasq stop, if I do that again, the ujail process stops too
<stintel>
unfortunately even then, starting the service again only spawns the ujail process, no dnsmasq
dangole has quit [Ping timeout: 480 seconds]
<genuser1>
Anyone have any ideas on why my wan link would drop, come back up, complain about a command failed: permission denied and then just continue normally? This becomes an obvious problem when I am in the middle of an online game session but not with streaming or general web browsing.
<genuser1>
I am not at home right now so no access (vpn is down) to home router
<dangole_>
stintel: I guess something results in dnsmasq exiting right after being started -- it's just weird that ujail would keep running. maybe /tmp is full?
genuser1 has quit [Remote host closed the connection]
<stintel>
I've updated the ticket to mention that only the ujail process is running
<stintel>
trying some random stuff but I don't know much about ujail
<stintel>
replacing -k with -d
<stintel>
let's see if that gives me more info
<stintel>
nothing after this: Wed Oct 27 16:05:49 2021 user.notice dnsmasq: Allowing RFC1918 responses for domain ...
snh_ has joined #openwrt-devel
<jow>
rsalvaterra: true. It's not that nft can't handle matching TCP SYN packets only, it just does not understand `extra`. We'd either need to support TCP flag matching natively in both fw3 and fw4, e.g. through 'list tcp_flags' (preferred) or introduce something like `option nft_extra` and let users manually convert their extra matches
<jow>
or rather, not nft is not understanding`option extra` but fw4 which translates to nft
<rsalvaterra>
jow: Found another issue… can't have multiple src_dip entries, can I? :)
<jow>
yep, but that limitation can be lifted
<dangole_>
stintel: for dnsmasq we are not using many ujail features, it was the first service to use ujail back then, only using filesystem isolation afaik (ie. no seccomp, no dropping capabilities, ...)...
<dangole_>
stintel: so whatever causes dnsmasq to quit right away after that line without telling us why is most likely somehow related to filesystem access, as everything else shouldn't make a difference if with or without ujail
<rsalvaterra>
jow: It would be nice, we need it for rules like this: iptables -t nat -A prerouting_lan_rule -p udp -m udp -m multiport --dports 53,123 ! -d 192.168.16.1/32 -m comment --comment "lan DNS and NTP hijack" -j REDIRECT
<jow>
ah, you mean src_dport
snh has quit [Ping timeout: 480 seconds]
<jow>
because I was wondering how you do multiple src ip matches with plain ipt (apart from cidr or -m iprange)
<rsalvaterra>
Gah! Of course, src_dport, sorry.
snh has joined #openwrt-devel
snh_ has quit [Ping timeout: 480 seconds]
<jow>
we can allow multiple ports and map to -m multiport internally
<jow>
just need to ensure that multiport is vaialble by default
<rsalvaterra>
Yeah, I have lots of nt rules with multiport matching. I think it's implemented, but only for filter rules, right?
<rsalvaterra>
*nat
<jow>
afair yes, but can be extended
goliath has quit [Quit: SIGSEGV]
rsalvaterra has quit [Read error: Connection reset by peer]
rsalvaterra has joined #openwrt-devel
snh has quit [Ping timeout: 480 seconds]
snh has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
rua1 has quit [Quit: Leaving.]
rua has joined #openwrt-devel
<stintel>
sigh, whatever I try, nothing results in more output from dnsmasq. tried running it in strace with output to /tmp somewhere, nothing
jbowen has joined #openwrt-devel
<jow>
welcome to the world of security features
<jow>
that kind of mirrors my experience with selinux :D
jbowen has quit []
<jow>
stuff not working ,dabble around for a while, disable
<jow>
stuff works
<stintel>
life is too short for selinux ;P
<stintel>
unless you run redhat maybe
<stintel>
they've spent an awful lot of time to make things work
<stintel>
but then it's still most of the time :P
<stintel>
anyway
<stintel>
something is off with ujail on my router in Belgium
<stintel>
this just hangs: /sbin/ujail -n blah -r /tmp -- /bin/echo test
<jow>
I stil ldislike the idea of having ujail by default
<jow>
it's badly integrated the way it is atm
<stintel>
while on a freshly booted vm it works fine
<jow>
for example it should automatically setup jail mounts for stuff mentioned in /etc/config/dhcp
<stintel>
it's doing that afaik
<stintel>
because I have /var/lib/dhcp.leases (as my /var is persistent) and that is automagically added to the jail
<stintel>
dangole: does that help narrow things down, that even simple echo via ujail just hangs on the affected system ?
<jow>
yeah, just checked, it does it to some exten
<stintel>
on a non-broken system it continues there with jail: adding mount /etc/resolv.conf /etc/resolv.conf bind(1) ro(1) err(0)
<stintel>
but on both systems that's a symlink to /tmp/resolv.conf
<dangole>
stintel: i guess it hangs still a bit earlier in the library dependency tracing code written by blogic a decade ago... can you use gdb and interrupt once it hangs and paste the backtrace?
<dangole>
mangix: i don't know that package, but looks more like jailing is incomplete...? mount-binding single files often gets you into trouble if the file is replaced (as inode number changes then and mount-bind blows up), so in case the program does that, that would explain the problem.
<stintel>
sigh, don't have the binary anymore on my workstation
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
KGB-0 has quit []
_lore_- has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
_lore_ has quit [Ping timeout: 480 seconds]
<stintel>
and we're back at yak shaving, now libgd is complaining about missing dependencies
<rsalvaterra>
stintel: Now that you mention it, just before rebooting, moments ago, I saw a *ton* of kworker threads on my system. I don't remember there being that many…
<dangole>
stintel: that looks pretty evil :( like musl ld.so doing something weird upon starting the jailed executable. as this is happening after long uptime I still believe we must have exhausted some resources. if it's not memory or space in /tmp, maybe it's open filehandles?
<stintel>
dangole: 136MB used of 4GB :P, tmp is at 0% usage ... filehandles ... which process should I be looking at, or the global limit ?
<dangole>
stintel: must be a global resource as the process is a newborn at this point
Luke-Jr has joined #openwrt-devel
<dangole>
stintel: now that i'm reading the code, i believe i know at least roughly where things are going wrong: int elf_load_deps(const char *path, const char *map) in jail/elf.c is my guess
<dangole>
stintel: because that also had some really weird stack corruption on MIPS64 for which i built an even more weird work-around a while ago, after days of not finding the root cause. and it's exactly where you are now experiencing the strange hang.
<stintel>
dangole: I updated procd-ujail now as I didn't have the binary anymore on workstation so had to rebuild, now it doesn't want to run in gdbserver anymore :/
<stintel>
it just spits out "ujail <options> -- <binary> <params ...>"
<stintel>
the usage test
<stintel>
text*
<dangole>
stintel: are you calling 'run' with the arguments intended for ujail in gdb?
<stintel>
dangole: ah, no. didn't have to previously
<stintel>
ok so "run -n blah -r /tmp -- /bin/echo test" hangs again
<stintel>
so the previous bt was probably due to mismatch in ujail binary, sorry about that
<stintel>
need to read kernel docs for the file-nr etc, it's not the same as last time I used it
KGB-0 has joined #openwrt-devel
<stintel>
maybe it's just whatever epoll needs that hit a limit
<dangole>
stintel: i by now suspect calling those elf*_find_section() functions... wild casts and pointer juggling involved there... could be memory re-use triggers the problem, ie. once malloc() returns previously used non-zerod pages...
<dangole>
stintel: because afaik we shouldn't even epoll for anything when coming from #9 0x00007ffff7fe30a0 in do_init_fini (queue=<optimized out>) at ldso/dynlink.c:1545 ...
<stintel>
dangole: on a system where ujail is working it doesn't show epoll there so that confirms what you just said
<dangole>
stintel: stack corruption would explain both, what you are seeing and the quite odd behavior on MIPS64 (see work-around in elf.c)
<jow>
I wonder if you could easily test with another gcc toolchain version
<dangole>
stintel: now we just need to find where in good old jail/elf.c this is happening (this code wasn't touched in half a decade i guess)
<stintel>
CONFIG_PKG_CC_STACKPROTECTOR_STRONG=y CONFIG_KERNEL_STACKPROTECTOR_STRONG=y any impact ?
<stintel>
jow: this has been happening for a year, toolchain is not the culprit
<jow>
I am seeing weird stack corruptions in firewall3 as well
<jow>
ok
<stintel>
> I’ve seen this problem before, mentioned it a few times on IRC, the first time was in October 2020, so before 21.02 was branched, so it’s very likely this problem exists there as well.
<stintel>
ok, I did not debug it completely as now, but it's always after several weeks of uptime that it pops up, would surprise me if that now has a different cause
<stintel>
never say never though, but ..
goliath has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<mirko>
hm, can't get cryptsetup/luks running with default cipher (aes-xts-plain) while kmod-xts is loaded - cryptFormat failing me with "device-mapper: table: 253:3: crypt: Error allocating crypto tfm"
<mirko>
"Check that kernel supports aes-xts-plain64 cipher" - what else than xts could I be missing? *wonder*
<Slimey>
oh my ix0: <Intel(R) X540-AT2> mem 0xcd000000-0xcd1fffff,0xcd5f8000-0xcd5fbfff irq 34at device 0.0 on pci1
<stintel>
mirko: sha modules ?
Borromini has joined #openwrt-devel
ashkan has joined #openwrt-devel
<stintel>
interesting, managed to open the Unifi 6 Lite case without breaking it
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
alex_const has joined #openwrt-devel
<alex_const>
Hi! I'm trying to build an OpenWrt image with custom kernel based on 3.3.8. My OpenWrt branch is master. What's the easiest way to go about this? Both building from local kernel directory and dropping a patch for subarch is fine. I'm just not sure what files I should edit. I tried editing kernel versions in include/kernel-version.mk to build pure 3.3.8 first, but the build system still tried to download 5.4.
<stintel>
alex_const: don't bother with 3.3.8
<alex_const>
stintel: I need this to test OEM patches for a SoC not yet supported by the kernel. Their kernel is based on 3.3.8 and I'd rather not port everything they added.
<stintel>
27|17:42:40 < dangole> stintel: i guess it hangs still a bit earlier in the library dependency tracing code written by blogic a decade ago... can you use
<stintel>
gdb and interrupt once it hangs and paste the backtrace?
<stintel>
27|18:44:32 < dangole> stintel: i by now suspect calling those elf*_find_section() functions... wild casts and pointer juggling involved there... could be
<stintel>
memory re-use triggers the problem, ie. once malloc() returns previously used non-zerod pages...
<stintel>
27|18:45:13 < dangole> stintel: because afaik we shouldn't even epoll for anything when coming from #9 0x00007ffff7fe30a0 in do_init_fini
<stintel>
(queue=<optimized out>) at ldso/dynlink.c:1545 ...
<stintel>
soldering a header on my Unifi 6 Lite meanwhile :P
<blogic>
hmmmz
<stintel>
can you make something out of it ?
<blogic>
made a note, will look close tomorrow
<stintel>
alright, ping me if you need more info / testing
<stintel>
thanks
<blogic>
a reproducible test-case would help
<stintel>
blogic: yeah that's going to be next to impossible, it happens after some uptime (several weeks)
<dangole>
blogic: i think this could be related to the stack corruption on MIPS64 i blamed on gcc some months ago and made a weird work-around back then. most likely elf*_scan_dynamic or elf*_find_section are the culprits, but I can't quite see where things are going wrong. maybe use of uninitialized variable in all the pointer-juggling in these functions... @champtar should maybe also have a look...
<stintel>
can we add prints to confirm your suspicion ?
<dangole>
stintel: yes, that can help and was the way I originally discovered the problem (but not the cause) and made the work-around for MIPS64...
<mirko>
stintel: sha1, sha256, sha512 loaded
<blogic>
dangole: we should ask ynezz to add his armageddon CI for procd/ujail
<blogic>
maybe/probably that will open a can of worms
<blogic>
ynezz: ^^^
<stintel>
mirko: no other ideas for now
<blogic>
dangole: what wuergaround ?
clayface_ has joined #openwrt-devel
clayface has quit [Ping timeout: 480 seconds]
<dangole>
blogic: commit 33b799b94c ("ujail: elf: work around GCC bug on MIPS64")
<blogic>
kk
<blogic>
will check tomorrow
<blogic>
kk, of to read unicorn and fairy stories ... best part of the day
dangole has quit [Remote host closed the connection]
guidosarducci has quit [Remote host closed the connection]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
guidosarducci has joined #openwrt-devel
dangole has joined #openwrt-devel
Tapper has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<aparcar[m]>
Habbie: thank you that’d be great
<Habbie>
aparcar[m], is -i 0 indeed what a user should do? or should the janitor be another permanently running job?
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<aparcar[m]>
Habbie: it should run permanently to keep things updated. At some point I’ll implement some kind of web hooks
<Habbie>
i saw a ticket, yes
Staz has joined #openwrt-devel
<alex_const>
umm... so could someone point me to the right direction regarding building another kernel version with custom patches?
<mirko>
urgs, make doesn't fail if at least ath71 images get too big
<mirko>
images just don't get created, make succeeds though. only hint is in verbose output ("[mktplinkfw] *** error: images are too big by 190430 bytes")
<mirko>
on latest 21.02
<slh>
that's the expected behaviour, otherwise it wouldn't be possible to successfully build OpenWrt at all (as there will always be some devices that got too small)
<mirko>
then i'd at least expect a "TARGET/DEVICE SKIPPED!"-warning
<philipp64>
noahm: why are we building with --disable-linux-caps ???
<aparcar[m]>
anyone knows of a IP script that automatically returns the subnets of a IPv6 address?
<aparcar[m]>
like cutting a /64 down into multiple /80 addresses
<zorun>
but it's meant to be used interactively, there is no parseable format
<zorun>
it's also really easy to do with a few lines of python (starting with "import ipaddress")
<dwfreed>
aparcar[m]: note that your example would produce 65,536 subnets
<aparcar[m]>
dwfreed: just enough!
<aparcar[m]>
mirko: It might, I'll check it thank you!
minimal has quit []
<aparcar[m]>
ipcalc.sh seems to be pre installed, can that script also do it?
<jow>
nope
<aparcar[m]>
oh it's ipv4 only?
<jow>
yes
<jow>
what do you want to do exactly? enumerate all contained subnets of a specific size?
<aparcar[m]>
I'm thinking about a wireguard script that automatically offers open subnets to clients
<jow>
there's also owipcalc
<aparcar[m]>
thanks I'll check that out
Tapper has quit [Ping timeout: 480 seconds]
<aparcar[m]>
oh wow that's exactly what I need
<aparcar[m]>
how can you summon all these nice tools
<noahm>
philipp64: it may not be necessary anymore, I don't know. we've been doing that since before 2014 when I imported bind9 from oldpackages.
nmrh has joined #openwrt-devel
nmrh has quit [Quit: nmrh]
_lore_- is now known as _lore_
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
Tapper has joined #openwrt-devel
<dangole>
nf_flow_offload_ip_hook tries to occasionally dereference 0xdead000000000110 (on mt7622). looks familiar to anyone? it (obviously) causes kernel oops "address between user and kernel address ranges"...
<hurricos>
@tusker: Could you share a build for the AP370?
Tusker has joined #openwrt-devel
<aparcar[m]>
zorun: you did some work with wireguard and link local stuff?
<aparcar[m]>
nick: you too?
<nick[m]1234>
aparcar: a bit
<aparcar[m]>
nick: thoughts on dhcpv6 over wireguard?
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<philipp64>
noahm: building now without it... will test this evening...