<ar7ch>
Hello, a quick question - which openwrt component does translation from uci config /etc/config/wireless to hostapd config and where should I look to add new rules/mappings? The reason why I'm asking is that it looks like ft_iface option from hostapd.conf does not exist in uci. I would like to add it
<dwfreed>
it looks like it should get set automatically whenever 802.11r is enabled?
rua has joined #openwrt-devel
rua has quit [Remote host closed the connection]
nixuser has quit [Remote host closed the connection]
rua has joined #openwrt-devel
nixuser has joined #openwrt-devel
ar7ch has quit [Remote host closed the connection]
Misanthropos has left #openwrt-devel [Leaving]
rua has quit [Quit: Leaving.]
robimarko has joined #openwrt-devel
rua has joined #openwrt-devel
<aparcar>
f00b4r0: morning, do you plan to merge the phase 2 buildbots together?
<f00b4r0>
morning. no.
<aparcar>
do you think it'd be a good thing to do or not worth it?
<f00b4r0>
i think phase2 has too many problems and should probably be started from scratch. It may require changes to our build system. The gist of the matter is that we shouldn't be rebuilding world to rebuild a single package.
<f00b4r0>
s/started/rewritten/
<f00b4r0>
the ideal scenario would be to have something closer resembling that of a more typical distro build system, but I don't know if it can be done with our current system.
<ynezz>
I assume, that we can safely start re-working that system in the staging buildbot/downloads environment
<ynezz>
I'm not opposed, but I think, that it would first make sense to discuss this a bit first, so maybe if you're willing to tackle that and find some time to write it down, it might be a good starting point
<ynezz>
unless you plan to attend the OpenWrt summit in May, so we can discuss that in person first :P
goliath has joined #openwrt-devel
<aparcar>
yea let's have a beer at summit and see how things go from there. I agree 100% with f00b4r0 to have atomic builds so it's likely wasted time to improve the phase2 as is. Thanks for reminding me of that underlying problem f00b4r0
<ynezz>
speaking about the summit, shouldn't we make it more visible? like having a link to https://www.battlemesh.org/BattleMeshV16 on the front page (it used to be there for previous BattleMesh events?)
swalker has joined #openwrt-devel
swalker_ has quit [Ping timeout: 480 seconds]
<f00b4r0>
btw a slightly more urging matter I think would be a 22.03.7 release, if only to plug CVE-2024-1086
<f00b4r0>
(I think we're affected, could be wrong tho)
<robimarko>
Do we have CONFIG_USER_NS=y and sysctl kernel.unprivileged_userns_clone = 1 ?
<robimarko>
aparacar: yes, I am monitoring but they are having some issues
<robimarko>
Eventually one push went through
<f00b4r0>
robimarko: yes to CONFIG_USER_NS (for some targets at least)
<f00b4r0>
the latter I don't know, could be user-setup dependent
<f00b4r0>
in any case it's a simple kernel bump away to fix it and that bump is already in the 22.03 tree, so I think it all boils down to issueing the tag :)
<robimarko>
Well, if I am reding the CVE correctly those 2 plus NF_TABLES=y are required
<robimarko>
But yeah, thumbs up for new point release from me
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
ar7ch has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
<Habbie>
gettext broken in packages master?
<robimarko>
Yeah, it seems that way
<robimarko>
Though the error that people report is not what I get
<Habbie>
2024-04-05T09:08:32.8850985Z /usr/bin/ld: encoding.c:(.text+0x379d): undefined reference to `libi
<\x>
works well, but yeah i dont think it should be pushed as default for 512MB devices
<robimarko>
Merged the gettext fix since more and more people reported the same
minimal has joined #openwrt-devel
<f00b4r0>
robimarko Ansuel just in case: you guys force pushed nearly simultaneously to 14971, I hope nothing got lost
<robimarko>
f00b4r0: Yeah, we were PM-ing about the same issue and pushed the same fix at the same time
<robimarko>
So luckily nothing was lost
<f00b4r0>
good. that was a bit scary :)
<robimarko>
We are getting close with that PR
<f00b4r0>
yeah. I would still very much like to see 'ZSTD_LEGACY_SUPPORT=7' removed though. Sorry for making this a sore point but I'm convinced it's a bad idea
<robimarko>
I dont have anything against
<f00b4r0>
Someone has to make the call. But if it's not removed it really ought to be documented anyway. Silent changes like this are bad form, especially in the light of current events. I think we can all agree on that at least ;)
<robimarko>
Ansuel agrees as well
rua has quit [Ping timeout: 480 seconds]
<f00b4r0>
also not clear from the conversation is that this only affects the decompression side of zstd. So essentially we're saying "we can't decompress older zstd archives", which I think is enough of a technical argument *against* it
<robimarko>
Yeah, I agree
<KanjiMonster>
0.8 (the final format) was introduced in 2015 (IIRC), and I don't think we ever enountered a zstd that failed to decrompress. Not that I want to argue against doing it, just the urgency (so maybe once switch from xz to std is done for our archives)
<f00b4r0>
KanjiMonster: the point is that this was recently introduced and really should never have been
<f00b4r0>
it's not as if it was there from the start
<robimarko>
It was added in the meson conversion which is relatively recent
<KanjiMonster>
sure, but it never did any harm, so I don't think we need to do change it back now
<f00b4r0>
xz never did any harm either. Until it did.
<f00b4r0>
my main argument in the PR is that for sensitive core tools like these, we should be *really* cautious about diverging from vanilla upstream. If there isn't a *very good* reason to do it, we should *not* do it.
<f00b4r0>
I *think* this is a strong, rational argument.
<f00b4r0>
vs the thin-air argument of "it may save a couple kilobytes but I'm not even sure", which was apparently all it took to get it there.
<KanjiMonster>
in that regard, not supporting legacy formats unless actually needed is probably the safer option; less code with (potential) buffer overflows/bugs ;)
<f00b4r0>
no. The zstd code that gets a lot of coverage testing is the default build
<KanjiMonster>
even the legacy formats?
<f00b4r0>
i haven't dug into the code to check what are the implications of changing the defaults on the binary, and I doubt anyone here did
<f00b4r0>
OK I feel I'm going in circles here. Is my above listed "strong" argument about sticking to vanilla upstream because we really can't afford to claim we're smarter than the entire team of people working on ZSTD valid or not?
<stintel>
why did we deviate from upstream default in the first place?
<KanjiMonster>
I would agree with you if we were allowing more legacy formats than upstream, but with less we are reducing the attack surface, not increasing it.
<f00b4r0>
because "it may save a couple kilobytes but I'm not even sure"
<robimarko>
stintel: no idea
<robimarko>
It was just pushed as part of the meson conversion/update
<stintel>
but then it has to be explained in the commit message
<robimarko>
Off would be equal to 8 I think
<f00b4r0>
so it was changed silently. Better even ;P
<f00b4r0>
I rest my case, I think i've made my point :)
<KanjiMonster>
the intend value for off is 0
<KanjiMonster>
though 8 would have the same effect
<robimarko>
Yes, 0 or 8 are same
<KanjiMonster>
if you were talking about the userspace zstd package, then I'd agree with default (or even 1), because who knows what old crap users have lying around. but just for extracting source tarballs we likely never need legacy support
<f00b4r0>
does it hurt? no.
<f00b4r0>
i mean again we need to have higher standards for core tools. "Do we have a very strong reason to diverge?" should be our mantra. Or else, expect us to be JiaTan'd one of these days
minimal has quit [Quit: Leaving]
<KanjiMonster>
AFAICT the whole legacy testing consists of extracting a single, simple, known good archive: https://github.com/facebook/zstd/blob/dev/tests/legacy.c - no error handling checking, no broken archive handling checking, etc.
mentalow has quit [Quit: :]]
mentalow has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
cmonroe has quit [Remote host closed the connection]
cmonroe has joined #openwrt-devel
takimata has quit [Quit: wat?]
takimata has joined #openwrt-devel
mirko has joined #openwrt-devel
mirko has left #openwrt-devel [#openwrt-devel]
mirko has joined #openwrt-devel
<mirko>
svanheule: you're the one maintaining the zyxel gs1900-* switch series, right?
<svanheule>
mrkiko: yes
<stintel>
the fan in the ECS4100-12PH is on or off, afaict :( 13k RPM :(
<svanheule>
mirko: that reply was for you -- mrkiko probably already knew ;)
<svanheule>
stintel: fun :P
<mirko>
svanheule: i just created a PR re the 24ep switch and wondered about moving common parts of the dts files into, well, common ones
<mirko>
but then noticed that was the case already and changed to every device having their own - and now wonder why
<stintel>
svanheule: yeah so it's a 3-pin fan, which should be +/- and rpm monitoring afaik, so the only way to control fan speed is voltage, gpio-fan won't be able to do that
<stintel>
iiuc
<stintel>
I found the temp and rpm sensors
<svanheule>
you could still make a thermal-zone with a gpio controlled fan
<svanheule>
it will just be on/off, I guess
<stintel>
I did, but once the fan kicks in, I cannot turn it off
<svanheule>
stintel: turn it off manually, or turn it off at all?
<mirko>
the dts is just so similar to the GS1900-24E
Mangix has quit [Ping timeout: 480 seconds]
<svanheule>
probably just the &uart1/status being different?
<stintel>
svanheule: not at all
<mirko>
svanheule: oh, that might be even a mistake - as i used the rtl8382_zyxel_gs1900-24hp-v2.dts as template
<mirko>
copy/paste - what is uart1 for?
<svanheule>
uart1 is used to talk to the PoE management controller
<svanheule>
you'll need it if you want PoE :)
<mirko>
i need it to use poe or to turn it off for specific ports?
<mirko>
ok, either way, seems like it should be included :)
<svanheule>
realtek-poe won't be able to do much without a controller to talk to...
<svanheule>
feel free to try without :P
<svanheule>
and creating a common DTSI for the 24(E) devices also doesn't sound like a bad idea
<mirko>
svanheule: didn't commit anything for a long time - shall i just merge or does it need review?
<svanheule>
might have to split it up again later, if the 24/24E turns out to be too different ethernet-wise for the DTS
<mirko>
the e/ep/hp and all v2 variants seem to be very similar
<svanheule>
please update the pull request, I would like to have another look
<mirko>
svanheule: sorry, update in which way?
<svanheule>
by force pushing to mirko:add-support-for-zyxel-gs1900-24ep
<mirko>
i mean, with what changes?
<svanheule>
if you want to add a joint DTSI file
<svanheule>
before adding a new 24EP DTS, that is
<mirko>
ah, about that - ok, figured that's still to be thought about for "later"(TM)
<svanheule>
well, if you want to do it, then it's best to do it before merging the initial 24EP DTS. Just to avoid unnecessary churn :)
<svanheule>
Anyway, gotta leave for now. Enjoy the rest of the day everyone!
minimal has joined #openwrt-devel
<mirko>
svanheule: what kinda bothers me is that the rtl8380_zyxel_gs1900.dtsi sets the poe_enable-node by default, however leaves out uart1 - so for non-poe devices you have to delete the poe_enable node and for poe-devices you have to set uart1 active
<jakllsch>
everyone loses!
<mirko>
hm, i see, the uart1 is defined even higher up, whereas gpio1/poe_enable are defined in the gs1900.dtsi file.. still feels awkward, but no better idea atm
goliath has quit [Quit: SIGSEGV]
<mirko>
also the realtek-poe package residing within the packages feed feels wrong
philipp64 has joined #openwrt-devel
goliath has joined #openwrt-devel
<mrnuke>
mrkiko: I think that was the compromise we made at the time to make it available in OpenWRT repos
ar7ch has quit [Remote host closed the connection]
<stintel>
yay the local hacker lab soldered wires to the ttl pads on the eap683lr and we have serial console
<Znevna>
local hacker lab? :P
<mirko>
stintel: where are you based?
<mrnuke>
stintel: were you able to identify the SoC on your eap683lr?
<mirko>
svanheule: oh boy.. can you confirm, that for the -24e the physical ports are indeed switched (first port is left/top instead of left/bottom as labeled on the case)?