<Grommish>
I don't have perf issues.. My issue is that I have my WSL2 OS moved out of %APPDATA%, which is fine, but I want to wipe all the drives and reinstall Winders fresh so I can properly setup the drives (I ad-hoc'd them originally), but it means having to tarball the wsl2 distro, wipe everything, re-import and it just takes forever :(
<Grommish>
Maybe I can just point it back to the rootfs directory afterwards, but I don't want to chance losing the install if it goes bad
<Grommish>
This old-arsed laptop has a 64Gb M.2 2230 SSD as the boot device and that just isn't enough.. and since I dropped the drives in afterwards, in order to move installation defaults, it wants to wipe the drives prior
<Grommish>
PITA all around but I picked up a nasty wiggler somewhere so it's time
<Grommish>
The good news is, when you export the WSL2 and then re-import it elsewhere, it no longer is bound to the WSL NAT :D
<Grommish>
It has access to the host nic directly
Vaughn has quit [Server closed connection]
Vaughn has joined #openwrt-devel
chder has quit [Server closed connection]
chder has joined #openwrt-devel
guidosarducci has quit [Ping timeout: 480 seconds]
guidosarducci has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
Spr0cket has quit [Server closed connection]
Spr0cket has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
Grommish has quit [Ping timeout: 480 seconds]
<neggles>
hurricos: i don't know if you've looked at the meraki MX6..7? 8? device you picked up particularly closely yet, but I have worked out what the smartfusion is for (assuming it's the same as it is on some of their older smartfusion2-equipped devices)
<neggles>
it's an entire FPGA... functioning as an emulated SPI flash for secure boot.
jbowen has quit [Server closed connection]
jbowen has joined #openwrt-devel
cyani has joined #openwrt-devel
swalker has quit [Server closed connection]
swalker has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
Grommish has joined #openwrt-devel
<Grommish>
*twiddle* This thing is still exporting.. *sigh*
arnd has quit [Server closed connection]
arnd has joined #openwrt-devel
Luke-Jr has quit [Ping timeout: 480 seconds]
noltari_ has joined #openwrt-devel
noltari has quit [Ping timeout: 480 seconds]
noltari_ has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
noltari has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
Luke-Jr has quit [Read error: Connection reset by peer]
minimal has quit [Quit: Leaving]
valku has quit [Remote host closed the connection]
Luke-Jr has joined #openwrt-devel
ekathva has joined #openwrt-devel
dansan has quit []
Luke-Jr has quit [Ping timeout: 480 seconds]
linusw__ has quit [Server closed connection]
linusw__ has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
Luke-Jr has joined #openwrt-devel
dansan has joined #openwrt-devel
MAbeeTT has quit [Server closed connection]
MAbeeTT has joined #openwrt-devel
awgh has quit [Server closed connection]
awgh has joined #openwrt-devel
cyrozap has quit [Server closed connection]
cyrozap has joined #openwrt-devel
Luke-Jr has quit [Read error: Connection reset by peer]
<slh>
it kind of is, an unexperienced user pushing buttons on the github gui
kopijahe has joined #openwrt-devel
<slh>
probably not intentionally harmful, but close-and-forget stuff
<slh>
happens every few weeks (the create pull request button is rather prominent in the github webinterface, so clueless users are likely to click it for their own forks)
kopijaheaseli has quit [Ping timeout: 480 seconds]
<rsalvaterra>
It's understandable. GitHub is weird.
Luke-Jr has quit [Ping timeout: 480 seconds]
gleb has quit [Server closed connection]
gleb has joined #openwrt-devel
<jow>
rsalvaterra: I used to call those "merge bombs"
<jow>
simply close them without notice
lmore377 has quit [Server closed connection]
lmore377 has joined #openwrt-devel
cmonroe has quit [Server closed connection]
cmonroe has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
robimarko has joined #openwrt-devel
<rsalvaterra>
jow: How's your nftables-fu? I'm adding support for dnsmasq nftsets as an UCI configuration, but I'm not really sure about the syntax…
<rsalvaterra>
As I understand, nftsets require both a set name and a table name… I'm thinking of adding the table name as a config option too.
Luke-Jr has quit [Ping timeout: 480 seconds]
rua has quit [Quit: Leaving.]
kopijahe has quit [Read error: Connection reset by peer]
<jow>
make it part of the name
<jow>
something like tablename/setname
Luke-Jr has joined #openwrt-devel
<rsalvaterra>
jow: Yep, that was my idea too.
<jow>
the dnsamsq config is about referencing preexisting sets, right?
<jow>
they have to be created externally
<rsalvaterra>
jow: Actually, dnsmasq should both create and populate the sets.
<rsalvaterra>
That's how it works for ipsets, anyway.
<jow>
what happens with resolved IPv6 addresses? are they silently discarded?
<jow>
because a set in "ip" should not be able to store IPv6 addresses
<rsalvaterra>
Hm… I thought it could store *both* types of addresses.
<rsalvaterra>
I don't know if it makes sense, though.
<rsalvaterra>
First I'm going to see if what I wrote even works, then we can take care of compatibility. :P
<jow>
nopem nft sets are explicitly typed
<jow>
they can store either ipv4 or ipv6
<rsalvaterra>
Hm. Cute.
<rsalvaterra>
I've read the source code, but it's somewhat confusing, it traditional dnsmasq style.
<jow>
I think it was a mistake back then to expose the --ipset syntax as-is to uci
<jow>
it should not be repeated for nftsets
<jow>
as you already mentioned, it might make sense to introduce a new "config set" type
<jow>
make it generate ipset or nftset depending on -x /usr/sbin/nft
<jow>
(potnetially an option type to explicitely override)
<jow>
give it an option family to select ipv4, ipv6 or both (default)
<jow>
then automatically generate ip and/or ip6 --ipset or --nftset options as needed
<rsalvaterra>
Well, that would be the perfect time to do so, yes… but we would still have to keep compatibility migrating from fw3 to fw4, no?
<ynezz>
speaking of dnsmasq/fw4, is there some support for "dynamic" rules? For example some of the current services are behind load balancers which usually change their IPs when reconfigured etc. so basically one would need to specify only domain name in some config option like registry.gitlab.com and when something behind the router is trying to reach that allowed host/domain fw rules would be updated on
<ynezz>
the fly
<jow>
if nft is present and table is absent, assume fw4
<jow>
ignore table for ipset
<jow>
rsalvaterra: yeah, unfortunately we need to continue recognizing `list ipset`
<jow>
in it's dnsmasq specific format
<jow>
rsalvaterra: btw, ipsets can only store one af as well, so either ipv4 or ipv6
<jow>
the ipset example is confusing too in the config
<jow>
it states:
<jow>
# Add the IPs of all queries to yahoo.com, google.com, and their
<jow>
# subdomains to the vpn and search ipsets:
<jow>
#ipset=/yahoo.com/google.com/vpn,search
<jow>
that reads as if resolved IP addresses are added to both vpn and search
<jow>
but IPv4 ones will be written to "vpn" and "ipv6" ones to search
<rsalvaterra>
I definitely thought it would populate *both* sets with the *same* addresses.
<jow>
so the syntax for ipset is /domain[/anotherdomain[/...]/ipv4setname[,ipv6setname]
<jow>
no idea if /domain/,foo would be valid (only store IPv6)
<rsalvaterra>
And here I was thinking this would be easy… :P
<jow>
when [ -x /sbin/fw4 ] then /domain[/anotherdomain[/...]/ipv4setname[,ipv6setname] should be transformed into nftset=/domain[/anotherdomain[/...]/4#ip#fw4#ipv4setname [nftset=/domain[/anotherdomain[/...]/6#ip6#fw4#ipv6setname]
<jow>
a more explicit `config set` section type could then be added later
Guest123 has quit [Ping timeout: 480 seconds]
<jow>
(and I still don't unterstand the syntax, nftset=.../4#ip#... is redundant, ip implies 4
<jow>
but I guess it was just copy-pasted from ipset and then beaten onto until it looked like nft
<aparcar[m]>
anyone ideas regarding caching the built tools/? If I move them around make will rebuild them all, I'm guessing stamps no longer fit the time of build. nbd maybe?
<jow>
rsalvaterra: hm, actually it is even more complicated
<jow>
that would be my backwards compatible proposal (and do the old --ipset stuff in the else branch of the fw4 test)
<jow>
it tries to deduce the family of existing sets and simply falls back to unspec family for not existing sets, for those dnsmasq will emit warnings if a domain resolves to both ipv4 and ipv6
<jow>
and a revised variant that puts all sets into one option (not sure if this is preferable): https://pastebin.com/4MANzRcK
<rsalvaterra>
jow: Wow, that was fast. Your shell experience obviously shows. :)
srslypascal is now known as Guest129
srslypascal has joined #openwrt-devel
srslypascal is now known as Guest130
srslypascal has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
<jow>
maybe add another logger warning stating smth. like "Found fw4, treating ipsets as nftables sets"
Luke-Jr has joined #openwrt-devel
mattytap_ has joined #openwrt-devel
mattytap has quit [Ping timeout: 480 seconds]
<aparcar[m]>
jow: is it Long Term possible to drop dnsmasq and use odhcpd more? You were the one reacting on GitHub that it’s not planed which I read as unfeasible
<jow>
dnsmasq has a lot of usecases
<russell-->
aparcar[m]: provides dns too
<jow>
configurable dhcp options, dns routing, specific handling of dhcp client groups (tagging), ipsets, nftsets, conntrack integration, basic dnssec etc.
<jow>
it is ugly, the code smells
<jow>
but it also is a kitchen sink and many of its bells and whistles *are* used by people
<jow>
suddnely replacing dnsmasq with a rather anemic odhcpd would be a major regression from a featur pov
<jow>
at the very least, odhcpd would need to gain support for freely configurable dhcp options
<jow>
and probably a bunch of other things I am overlooking right now
<aparcar[m]>
russell--: :D
<aparcar[m]>
jow: thanks, seems like no way around it
<jow>
yes, that's the dilemma
<jow>
I do think it can be done, but it will not happen overnight
<jow>
odhcpd need to get brushed up to support the most important features (dhcp options)
<jow>
and a replacement for dns resolving must be found
eduardo010174 has quit [Quit: Page closed]
ekathva has quit [Remote host closed the connection]
<aparcar[m]>
isn't the DNS thing something John or Felix code over the weekend?
<stintel>
I'm curious to hear Habbie's opinion on that :D
ekathva has joined #openwrt-devel
<ynezz>
yeah, one can introduce several RCEs over the weekend
<nbd>
at some point, i really want to write some simple ubus dns and dhcp protocol adapters that are easy to lock down hard with seccomp/ujail
<aparcar[m]>
nbd: should we start a crowdfund?
<nbd>
funding isn't really the problem at the moment, lack of time is
<nbd>
for the dhcp server part it might even be a good idea to write most of the logic in ucode
<nbd>
and maybe some of the dns parts as well
<aparcar[m]>
jow: mind creating a tag (v0.1.0) for ucode so I can create a debian package?
<aparcar[m]>
or even v0.0.1, if you feel humble
srslypascal is now known as Guest138
srslypascal has joined #openwrt-devel
Guest138 has quit [Ping timeout: 480 seconds]
<rsalvaterra>
aparcar[m]: Funny, I was also looking at the nf_conntrack_max pull. :)
<jow>
aparcar[m]: yeah, I'll add a tag for the current head commit. I think v0.1 is fair
<aparcar[m]>
please 0.1.0 as "semver"
<jow>
I don't want to deal with semantic versioning
<aparcar[m]>
rsalvaterra: can you please give it a test? we just ran into the issue on a APU
<rsalvaterra>
Ouch. An issue caused by the patch?
<aparcar[m]>
jow: okay make it 0.1 then, shouldn't matter
valku has joined #openwrt-devel
<aparcar[m]>
jow: please ping me once it's tagged
srslypascal is now known as Guest141
srslypascal has joined #openwrt-devel
<jow>
aparcar[m]: I mean I can do v0.1.0 too, but the git describe of it ends up looking kinda ugly -> v0.1.0-0-g7d27ad5
Guest141 has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
srslypascal is now known as Guest143
srslypascal has joined #openwrt-devel
<ynezz>
jow: then just start with v1.0.0 ? :P
Guest143 has quit [Ping timeout: 480 seconds]
<aiyion>
ynezz: I encountered that gem about a year ago :) https://0ver.org/
<ynezz>
:D
<ynezz>
naming and versioning are hard
<aparcar[m]>
jow: let's go with 0.1.0 if you don't have a hard argument against it, the debian package will be "0.1.0-1"
<jow>
what about 0.0.20220322 ?
<ynezz>
aparcar[m]: do you plan to do APK as well? I've it on my TODO list for some time
<aparcar[m]>
sounds lovely, I think that's what wireguard is doing
<jow>
okay, I'll do that, then
<aparcar[m]>
port APK to debian?
<ynezz>
aparcar[m]: it makes more sense to use alpine container with ucode for templating purposes
<ynezz>
they're much smaller, thus faster CI jobs etc
<aparcar[m]>
oh hah, yea I'm happy to port it to alpine as well
<aparcar[m]>
once we got the tag
<jow>
tag pushed
<ynezz>
cool, thanks!
<aparcar[m]>
thanks
<aparcar[m]>
jow: while at it can you switch your username to jow instead of jow- 😉
<aparcar[m]>
speaking of ugly jow--ucode-753dea9
<jow>
I'd love to, but someone has taken that name already
<aparcar[m]>
write a support ticket, that user account isn't used
<jow>
("jow-" is also unable to host github pages)
<aparcar[m]>
yea I know
MAbeeTT2 has joined #openwrt-devel
<aparcar[m]>
you're probably the only user with an invalid username
<aparcar[m]>
ynezz: probably some mislead souls not finding the real jow
<aparcar[m]>
jow: btw for now I'll disable all the bells and whistles around ucode and just compile the basic version. I'm not keen to port the entire openwrt ecosystem to debian
<aparcar[m]>
stintel: you're working on that right?
<jow>
aparcar[m]: makes sense, allthough nl80211 and rtnl are not really openwrt specific
<jow>
they just happen to use libnl-tiny by default
<stintel>
aparcar[m]: no, I'm not going to port anything to debian as I don't use debian
<jow>
I guess with ome cmake if-else-ery they could be compiled using a libnl-3 or so
<stintel>
nor ubuntu
<aparcar[m]>
jow: up to you
<aparcar[m]>
I'll create the basic version with CI and then you can tinker with it
MAbeeTT has quit [Ping timeout: 480 seconds]
<jow>
yeah, math, struct, fs are the important ones
<rsalvaterra>
Looking at fw4 print output for the first time…
<rsalvaterra>
… damn, the nftables syntax is compact…!
<jow>
scripting nft is nice, yeah
<jow>
typing coplex rules on the cli is ugly as hell
<aiyion>
I'm looking for the reason, why my /etc/board.json contains an of by one label-mac.
<aparcar[m]>
jow: something doesn't look right
Lechu has quit [Ping timeout: 480 seconds]
<jow>
yay, old libjson-c
<aparcar[m]>
sorry for that
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<aiyion>
When is /etc/board.json updated/written?
<aiyion>
I cannot see the issue in the dts yet.
<dangole>
aiyion: config_generate does that, and it's called in /etc/init.d/boot
<dangole>
aiyion: i don't think that's nice, because for default wifi settings (which are triggered by hotplug event) this may not have happened yet. i guess we need to let config_generate work in a way that it can be called multiple times and only the first call would trigger actually generating the config and all follow-up calls will just wait for that to have happened (ie. use some locking and pidfile for config_generate maybe?)
<aiyion>
I just don't get what's not happening, yet. I have the ar71xx device, flash the latest openwrt, tell it not to keep the config.
<aiyion>
ip a shows, eth0 does match the correct mac, so something must work correctly.
<f00b4r0>
dangole: it's board_detect that generates board.json if I'm not mistaken. config_generate prepopulates /etc/config based on board.json
<aparcar[m]>
jow: bummer there is no caching for apt...
<aiyion>
dangole, f00b4r0: still figuring out whats happening, but the hint around board_detect was nice.
<aiyion>
as board_detect goes through whatever is in /etc/board.d/ I looked into that.
<aiyion>
Theres a line in 02_network, which instructs the label mac to be the result of cat /sys/class/ieee80211/phy0/macaddress
<aiyion>
So theres an explicit entry for my device take the label_mac from phy0, which is not assigned the label mac in the dts.
<aparcar[m]>
dangole: did you put more thoughts on this locking issue?
<dangole>
aparcar[m]: yes, it should be simple to add using 'flock' in board_detect. and then board_detect can be called from anyone extecting /etc/board.json to be present and only the first call will actually generate the file while all others will just sit there and wait until the first call has finished or return right away in case /etc/board.json already exists
<aparcar[m]>
excellent
Grommish has joined #openwrt-devel
Grommish has quit []
robimarko has quit [Quit: Leaving]
GNUmoon has quit [Remote host closed the connection]
Grommish has joined #openwrt-devel
mattytap has joined #openwrt-devel
mattytap_ has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
mattytap has quit [Read error: Connection reset by peer]
mattytap has joined #openwrt-devel
srslypascal is now known as Guest176
srslypascal has joined #openwrt-devel
Guest176 has quit [Ping timeout: 480 seconds]
eduardo010174 has joined #openwrt-devel
eduardo010174 has quit [Remote host closed the connection]