<ldir>
jow: https://pastebin.com/SJNE7gWT - There's probably a better way of doing that - fixes the problem that 'connections.js' was showing the 'reply' direction data, not the 'original' direction.
<jow>
ynezz: need to look into it in more details, but firefox here is very eager to hop onto https://
<jow>
likely when it used the same host/url with https in the past
<ynezz>
it's probably related only to aarch64, unable to reproduce it here in qemu x86/64, curl doesn't exhibit that issue as well
<jow>
ldir: great, thanks for confirming. I'll fold it into the patch series
<hauke>
maybe google is trying something out on the chrome instance of this user
<f00b4r0>
jow: isn't firefox one of those "https-first" browsers nowadays?
<jow>
f00b4r0: possible, yes.
<ldir>
jow: I think the s/dport code should be e[kv[1]] ??= kv[2]; instead of e[kv[1]] ??= +kv[2]; The addition is superfluous.
<jow>
ldir: that is to coerce the ports into numbers
<ldir>
Ahh, ok
<jow>
probably does not matter though since the frontend will handle both
<jow>
more of an ocd thing
<ldir>
I like ocd
<ldir>
at least people are checking it works :-)
<jow>
how's the performance for you? does it feel noticeably slower?
<ldir>
I've not noticed any difference in performance.
<Ansuel>
(jow btw i'm planning to disable read/write access by default on github actions for the openwrt repo. Any problem with that? We will have to set specific permission on the various workflow)
<ldir>
jow: I've gone through quite a change in setup over past 2 days, going from iptables to nftables... dropping a few things in the process, falling over some others. 'ipset' needs a re-think in dnsmasq.
<jow>
Ansuel: I can't think of potential issues
<Ansuel>
jow yep we just have to update the workflow, think we should do the same of the other repo too IMHO
<jow>
ldir: unfortunately I didn't manage to finish/test in time for 22.03
xes has quit [Remote host closed the connection]
xes has joined #openwrt-devel
cbeznea1 has quit [Quit: Leaving.]
xes has quit [Remote host closed the connection]
cbeznea has joined #openwrt-devel
valku has joined #openwrt-devel
<jow>
nbd: I was thinking some more about the ucode / EINT / signal issues. We can fix waitpid() to retry, that should be simple but the problem goes deeper - for example the fs library would also need to be completely rewritten to not use stdio as this is not EINTR-safe
<jow>
nbd: the actual root cause seems to be uloop_init(), it sets up custom signal handlers to handle INT, TERM, CHILD and PIPE
<nbd>
stdio isn't safe?
<jow>
nbd: these custom signal handlers are installed without SA_RESTART
<jow>
so from then one, any stdio operation in the client program becomes unsafe
<jow>
*then on
<jow>
plus a bunch of other interruptable syscalls
<jow>
I see multiple solutions (for ucode)
<jow>
1) rewrite any stdio using code to use low level read(2)/write(2)/open(2) etc. - this will likely negatively affect performance for readline-esque operations unless we reimplement stdio buffered io ourselves
<jow>
2) extend mod-ubus uloop.init() to patch the signal handlers after uloop_init()
<jow>
this is crappy workaround though and might not work for cases where ucode is embedded in host programs that setup uloop elsewhere
<nbd>
i think we should probably just set SA_RESTART as well
<nbd>
brb/bbl
<jow>
I am leaning towards this as well, yes
xes has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
xes has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
mrkiko has joined #openwrt-devel
<karlp>
anyone know what might have gone wrong to get "include/kernel-version.mk:11: *** Missing kernel version/hash file for . Please create ... include/kernel-." ?
<karlp>
I've done a make dirclean and rm -rf tmp already?
xes has joined #openwrt-devel
hanetzer1 has quit [Ping timeout: 480 seconds]
<Ansuel>
karlp as the error said
<Ansuel>
you are using a kernel version that is not defined with an include/kernel-* file
<karlp>
yeah, I have never tried to explicitly define or not define one, ... so I don't know what would have happened to not have one?
<karlp>
it kinda looks like it's empty somewhere?
<Ansuel>
wait what? kernel version is mandatory for a target
xes has quit [Read error: Connection reset by peer]
<karlp>
I just updated my tree from and old master, like 18months ago, to the 2203 branch,
<karlp>
I did press ctrl-c to kill a build, I wanted to re-review a cahnge I'd rebased, but that's just in shell stuff in user space.
<karlp>
but now I can't do menuconfig/build anything...
<karlp>
well, I've manually nuked all the chunks of build/staging/tmp and regenerated my .config from scratch and it's... ok again? bit of a time suck but so be it.
<karlp>
I suspect I interrupted scripts/config generation in a bad place.
xes has joined #openwrt-devel
xes has quit [Ping timeout: 480 seconds]
<ynezz>
karlp: you've probably missed something during rebase? you should have include/kernel-5.10 since 0765466a42f (1/2022), it's not generated
<karlp>
it worked after nuking by hand large chunks of build/staging/tmp and redid my config.
<karlp>
unreproducible, so *shrugs
<karlp>
was hoping maybe someone just knew what file I could delete to rebuild it, rather than the whole tree.
<karlp>
beingreminded harshly again that my laptop isn't the fastest build machine in the world :)
goliath has joined #openwrt-devel
minimal has joined #openwrt-devel
<Ansuel>
karlp the error comes from having a kernel version and no related file in include/ so with some effort there should be a way to repo but the big question is why
<rmilecki>
Habbie: what Broadcom device did you buy? :)
<f00b4r0>
holy shit. I just trashed my openwrt after running a "save" in luci on an overlayfs that was apparently full. And it seems I can't even opkg remove the most recently installed package
<f00b4r0>
*ugh*
ekathva has joined #openwrt-devel
ekathva has quit []
<Ansuel>
yep when overlayfs is full you are fked
<PaulFertser>
There's a script on the wiki to unfuck.
<jow>
I wonder if the "persistent" flag achieves just that
<Ansuel>
it's not well defined and everyone does it the way they understand it... reality is that at the very end it's probably games implementing nat in a bad way/user behind nat pretentindg to host games
<jow>
and if not, people should consider simply adding another flag to add the desired behaviour
<jow>
instead of introducing copy-pasted target kmods into the kernel
<Ansuel>
yep i think persistent is common fullcone but they want a kmod with fullcone-nat in the name
<Ansuel>
should we create a kmod that does only one command :D (actually now i'm curious to check what tecnicolor do about fullcone nat...
<Ansuel>
time to check brcm broken gpl
<nbd>
my understanding is this:
<nbd>
netfilter already maps requests from the same internal ip+port to the same external port (as long as the entry is kept alive)
<nbd>
the difference in full cone nat is that it allows any external host to contact the internal port/ip combination on the mapped port
<nbd>
whereas netfilter by default only allows this from hosts that the internal ip/port has made contact with
<nbd>
this was the most difficult part of NAT that i had to deal with in unetd
Misanthropos has quit [Ping timeout: 480 seconds]
<nbd>
it was the main reason why the use of STUN servers is required when doing unetd over double-NAT with DHT discovery
<nbd>
on DHT discovery, i get a direct link between two nodes on one port, but i can't use that to open up the wireguard data port, because the other side won't accept packets from it
<nbd>
with full cone nat it would be easier, because i could just send a packet from the data port on one side to the discovery port on the other side
<nbd>
and that would give the other side the necessary info to establish a direct data port connection
<nbd>
i took a quick look at the 'persistent' flag, and it doesn't provide the relaxed port access behavior needed for "full cone NAT" mode
<nbd>
so regardless of the "persistent" flag, we're always doing "port restricted cone nat"
sorinello has quit [Read error: Connection reset by peer]
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<Ansuel>
Patch was created by Broadcom.
<Ansuel>
Adds fullcone nat support to the MASQUERADE target.
<Ansuel>
jow wonder if you are interested in the patch
<stintel>
bah, I'm now stuck with full clown NAT in my head 😂
sorinello has joined #openwrt-devel
<Mangix>
my fedora instance is broken. ffs
<Mangix>
gotta love broken autotools projects
<Mangix>
wonder if the /home subvolume can be reused
Misanthropos has joined #openwrt-devel
xes has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
Ansuel_ has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
isak has quit [Read error: Connection reset by peer]
isak has joined #openwrt-devel
MaxSoniX has quit [Quit: Konversation terminated!]
<jow>
nbd: thanks for that concise summary
<jow>
nbd: so it seems to be that a new flag "relaxed" or similar could be added which lifts that extra security requirement
<jow>
probably also have a higher chance for upstream inclusion compared to custom hacked kernel modules
<Ansuel_>
jow from what i notice ANY implementation of full cone nat require additional function so it's not a simple flag from what i notice from brcm source and that xt_fullconenat kernel module
<Ansuel_>
jow additional check on the type of packet and some extra flag needed to bheave differently but we are right about all of this... the feature NEEDS to be handled by netdev first then we can consider backport...
<Mangix>
Ansuel_: in the packages feed, it is mandated that all patches are ran through the refresh target
<Ansuel_>
yep but main problem is that we still don't have a workflow to compile check core package AFAIK?
<Ansuel_>
we should be able to implement that for kernel workflow tho
<Mangix>
checking for dirty patches does not require compilation AFAIK
<Mangix>
it's fairly irritating as the packages feed has all clean patch. base is a wild west
robimarko has quit [Quit: Leaving]
<Ansuel_>
ahahaha so true
<Ansuel_>
we should also put some effort for linting our scripts
<Mangix>
you mean shellcheck?
<Ansuel_>
yes
<Mangix>
I had some commits like that before I broke my fedora install
<Mangix>
I'll probably spend the rest of the day fixing that up...
<Ansuel_>
and how we should handle new script... example i have to merge a new script for xiaomi and i don't know if we should keep the shellcheck comments to disable ash warning or not
<Ansuel_>
mangix and it's still broken ?
<Mangix>
Ansuel_: yeah. I have to reinstall. I ran sudo make install on libtirpc with the assumption that it would install to /usr/local. Nope.
<Mangix>
proceeded to break libpam, sudo, and basically the whole OS
<Mangix>
the way fedora is configured, there's no real root user
<Mangix>
you have to use sudo su -
<Mangix>
so I can't login as root and do dnf reinstall libtirpc
<dwfreed>
you wouldn't have been able to if pam is broken anyway
<dwfreed>
and you probably just need to set a root password and you can log in directly as root (but if pam is broken it doesn't matter)
philipp64 has quit [Ping timeout: 480 seconds]
<Mangix>
probably
<Mangix>
turns out in order to keep /home, I have to use the Fedora 37 ISO.
Shyn has quit [Quit: Page closed]
<Mangix>
cause...btrfs subvolumes are hard
torv has quit [Remote host closed the connection]
<barhom>
Is it possible to configure wpa2/psk with multiple allowed passphrases? Basically a list of passphrases that is valid
<slh>
lvm2+ext4 might be easier (for the future)
<Mangix>
slh: nah that's just an Anaconda quirk that they fixed in 37
torv has joined #openwrt-devel
<barhom>
Or, if I use wpa2/enterprise - is there some option to have a super basic allow list (username/password in a file) without going through having freeradius installed locally on the router? I feel like its overkill for me to have freeradius, but having a few different username/passwords in a file (a la htpasswd) is fine
<Mangix>
Alright. Reinstalling. Hope this goes well.