Sawzallz has quit [Remote host closed the connection]
Sawzallz has joined #openwrt-devel
Daanct12 has quit [Quit: WeeChat 4.4.2]
Daanct12 has joined #openwrt-devel
tersono has joined #openwrt-devel
felix has quit []
felix has joined #openwrt-devel
<tersono>
Is there a recommended way to create some default firewall configuration from a package? Specifically I want to add a firewall zone associated with the tun device managed by the package. I could add it on daemon startup if it doesn't exist, but then the firewall config would also still need to be reloaded.
<dwfreed>
you should make a netifd protocol module for the service, so that it can be managed as an OpenWrt interface; once it's an OpenWrt interface, firewall handling is automatic and fully user configurable
kali_ has quit [Remote host closed the connection]
<tersono>
Hm ok. The interface still wouldn't be configured by default though? With the current approach where it's managed as a service the default service instance is created automatically
rua has quit [Quit: Leaving.]
<tersono>
The other complication is that this is more like a like a radio, and the configuration of the network is a separate thing from the radio configuration
<dwfreed>
tersono: the user would create an interface in openwrt with protocol 'foo' where foo is whatever service this is; once the interface is started, netifd would call your protocol handler script, and you could do whatever setup is necessary, including configuring "radio" and "network" (see wireguard as an example of how to have extra configuration options); once your protocol script is done, netifd
<dwfreed>
takes care of telling the firewall the interface is now up, and the firewall automatically loads its necessary configuration, including zone mapping, forwarding, and filtering rules
<robimarko>
Default is always git.openwrt.org for everything
<robimarko>
BTW, what do you think we should do about the freeswitch package which requires pcre which we dropped
<Ansuel>
IMHO the solution would be to find tester for pcre2
<Ansuel>
if we can't find a single tester for it there is no excuse to drop it...
<robimarko>
Which as you can see is not happening, as even the person that is using freeswitch simply re-adds libpcre back
<Ansuel>
but it's strange we didn't find one...
<robimarko>
Dude even pushed an update to freeswitch last month
<Ansuel>
yep i was checking just that...
<russell-->
zyxel,gs1900-10hp working now
<Ansuel>
is it possible to disable the regex module ??? O.i
<robimarko>
Should we really even bother, its been like a year since you posted the PR
<Ansuel>
it's just that i really hate putting all those effort in migrating entire project and then having the package dropped... and it's not even something they can ignore since PCRE is EOL...
<robimarko>
They have been doing quite a good job at ignoring it
<robimarko>
I mean, I dont care if its broken in the telephony repo, but the damn error every time is quite annoying
<Ansuel>
for sure it's something that must be handled by 24.xx
<robimarko>
Meaning ASAP if there is ever going to be 24.xx release
<Ansuel>
the annoying part is not accepting the downstream patch... keeping them in pr like that only cause problems as it gets lost... Having that downstream permits to have track of it and even help them to actually implement the feature
<Ansuel>
robimarko main blocker for 24.xx is the luci app for APK (kernel bump got handled from what i can see)
<robimarko>
There are still 2 or 3 targets that need to be bumped
<robimarko>
qoriq and at91 being the hard ones as nobody seems to want to actually test the bump
<robimarko>
I am pushing for realtek to default to 6.6 so it also gets actually tested
<robimarko>
So we can finally drop 5.15 ASAP
<robimarko>
Is APK ready outside of LuCI?
<Ansuel>
we have staging buildbot that produce testing image
<Ansuel>
but yes outside luci it's ready
<robimarko>
Great, so it would make sense to default to APK soon-ish
<Ansuel>
yep there will be some stupid build bug to fix (mostly some package that still needs to adapt to the new version and some target trying to install non existent packages (don't ask)) but those will be easy and buildbot failing will help on that
<russell-->
robimarko: i've been running an m300 (i.e. qoriq) on 6.6.47 since late august
<robimarko>
russell--: Great to hear that, can you please comment on the PR about it
<robimarko>
Cause any runtime testing comments really help
<Habbie>
is there a document about apk on openwrt? i have questions like "did the package format change" which it would likely answer
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #openwrt-devel
minimal has joined #openwrt-devel
rua has joined #openwrt-devel
<Ansuel>
\x i wonder if there is a way to detect the misconfiguration and fix that internally...
<Ansuel>
hostapd is full of workaround for mistake done by the clients...
<Ansuel>
if the problem is that present i wonder if it might be a good idea to report this to hostapd directly and discuss there for a solution?
tersono has quit [Ping timeout: 480 seconds]
tersono has joined #openwrt-devel
<slh>
Ansuel: I didn't really look at luci-app-opkg at all, but would it be feasible to write a small /bin/opkg shell script doing transparent parameter translation to apk? I haven't noticed any libopkg, so that might be feasible (and I don't expect luci-app-opkg to have that many requirements on the opkg call API)
<slh>
certainly not perfect, but maybe just good enough to get started
<Ansuel>
it's all parsing hell... no apk is different than opkg so better not handle things that way... better make the user use guide for apk directly than try with wrapper and complicate things
<slh>
well, dropping luci-opkg from the luci metapackages might be the next best alternative
<Ansuel>
or rename to luci-pkg and support both...
tersono has quit [Ping timeout: 480 seconds]
<stintel>
PSA: don't upgrade to macOS 15.0
<jakllsch>
always good advice :-)
<Habbie>
stintel, why?
<stintel>
firewall dropping legit traffic
<Habbie>
ah
tersono has joined #openwrt-devel
<Ansuel>
stintel it's for your own safety :D
rua has quit [Quit: Leaving.]
<stintel>
ah yes, since you can't unplug the ethernet cable ¯\_(ツ)_/¯
rua has joined #openwrt-devel
<\x>
Ansuel: i have no idea on this thing really, but yeah all i see is that this is a mismatch of what the client think is the "highest" security
<\x>
its the mismatch causing this bs, ap says 9|8|6|4|2 and clients be like 9|8|4|6|2
<\x>
so theres that bad blood on 4 and 6, you either remove 4 or remove 6
<stintel>
sounds like this is about Apple again
<\x>
either works, but yeah removing 6 is less preferrable on security standpoint
<\x>
blame wi-fi.org guidelines
<stintel>
funny story: macOS devices can connect to wpa2+3+ft, and so can iOS devices. iPadOS devices cannot
<\x>
i guess some arent updated or some weird thing, maybe older apple with some older broadcom
<stintel>
it's just another case of companies having grown so big, the departments have no clue about what the other departments are doing
<Ansuel>
nha just wifi things... and things getting so complex with all the standard that firmware are all offloaded and assumption are buried deep in a single line in the closed source blob
<f00b4r0>
stintel: i'm more inclined to blame different wifi chips and shitty firmwares though ;)
<f00b4r0>
also, i'm running macOS 12 and will until it stops receiving security updates. I have been less than impressed with the recent evolutions of macOS
<stintel>
no argument there :P
<stintel>
but we had users complaining "I got a 60s notice for a reboot to install 15.0"
<stintel>
there was no cancel button
<f00b4r0>
the cancel button is the power plug ;P
<stintel>
just clicking the pop-up window resulted in cancel though
<stintel>
but we've like 10% on 15.0
<stintel>
and it's a shithosw
<stintel>
not even able to ping default gw
<f00b4r0>
how typical of recent .0 macos releases. Jobs must be turning in his grave ;P
<stintel>
I'm going to explicitly request microsoft to introduce the possibility to completely block .0 versions from being installed on corp managed devices
<stintel>
why that doesn't exist yet is beyond me
<stintel>
this has been a problem since last time I ran macOS on a daily
<f00b4r0>
yeah it sounds like these devices aren't in managed mode
<stintel>
which is ~10 years ago
GNUmoon has quit [Ping timeout: 480 seconds]
<Ansuel>
stintel are you asking enterprise feature on a macos?
<stintel>
Ansuel: I know the 2 don't work well together, but unfortunately Windows has such a bad rep that macOS in a corp context is extremely common
tersono has quit [Ping timeout: 480 seconds]
<Ansuel>
well guess who works well in enterprise IF correctly setup :D
<stintel>
Linux? :P
<Ansuel>
that IF tho is as big as the entire planet
<Ansuel>
stintel linux is ok only for server... try to do enterprise stuff on worker pc with limiting stuff :D
<stintel>
it's all just a giant shitshow
<stintel>
meanwhile my Gentoo workstation install is 15 years old and running fine
<stintel>
and theoretically even OK for cyber insurance companies because I run AV (clamav, and the insurance doesn't list which AV solutions are accepted and which not)
<Ansuel>
but not secure with the pixhell attack :D
<Ansuel>
you are welcome
<stintel>
ah, is anything then
<f00b4r0>
side channel attacks are always amazing, tbh
<f00b4r0>
pixhell reminds me of a similar one from a few years back where iirc they managed to extract data from the PSU noises
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #openwrt-devel
tersono has joined #openwrt-devel
tersono has quit [Ping timeout: 480 seconds]
<stintel>
ah wonderful, trying 6.6 on my m300 and entire network offline
<stintel>
ffs
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #openwrt-devel
tersono has joined #openwrt-devel
Mangix has quit [Ping timeout: 480 seconds]
tersono has quit [Ping timeout: 480 seconds]
Mangix has joined #openwrt-devel
tersono has joined #openwrt-devel
<robimarko>
stintel: That is weird since russell-- stated that it works