<rsalvaterra>
So, I was looking for a way to disable the switch (swconfig) leds on my aging TL-WDR3600…
<rsalvaterra>
… and according to this ancient commit, they should be exported in sysfs, no? https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=0056ac55afa1a9fe2bd327f5f4ee2140760669f9
<rsalvaterra>
(In the /sys/class/leds/tp-link subdir.)
<rsalvaterra>
However, that subdir isn't created, I only have the GPIO-connected leds available to control.
<rsalvaterra>
Does anyone know if this is a regression, or working as intended (and I missed something)?
<darkxst>
sysfs support for gpio/led's is likely removed in recent kernels
<robimarko>
rsalvaterra: they are not exposed in UCI?
<rsalvaterra>
robimarko: I'm not exactly 1st dan in UCI-fu. How do I see that?
<robimarko>
Usually they are registed as netdev LED-s
<robimarko>
Though its been ages since I touched anything swconfig based
<robimarko>
As that is the default timeout for FDB entries
<rsalvaterra>
Interesting. I had DSA working stable before (2020's), but sometime in 2022 (the last image I had built for the WDR3600) had this issue.
<rsalvaterra>
However, as it wasn't a production device anymore, I just shelved it. Now I dusted off again because I needed a smart switch. :P
<robimarko>
Enabling assisted_learning_on_cpu_port for qca8k should help
<robimarko>
As the switch has HW learning but like on MT7350 it doesnt work in all cases
<robimarko>
Especially when it learns of a WLAN client MAC on another device and then you roam it
<rsalvaterra>
I wasn't using Wi-Fi at all, in my case, though.
<robimarko>
Thats just an example, if it learns the same MAC twice you will get this issue
<rsalvaterra>
I also read somewhere about endianness issues with qca8k (and WDR3600 is big-endian).
<robimarko>
That was only issue with the statistics reading via ethernet packets
<robimarko>
And has been fixed, MDIO never had those issues
<rsalvaterra>
There was also a regression in routing speeds, but that didn't matter so much to me.
<rsalvaterra>
I'd rather take the hit for the convenience of the DSA configuration. :)
goetz has quit [Quit: goetz]
goetz has joined #openwrt-devel
<rsalvaterra>
I wonder if ath79 should be split in DSA and non-DSA targets… Painful, yes, but…
<f00b4r0>
rsalvaterra: i have multiple WDR3600 running 21.02 and 23.05 and LEDs are controllable
<f00b4r0>
via sysfs
<rsalvaterra>
f00b4r0: The *switch* leds?
<f00b4r0>
hmm, i'd have to check to be sure
<f00b4r0>
good point
<rsalvaterra>
I have seven controllable leds, but they're the GPIO-connected ones (ath9k-phy0, green:qss, green:system, green:usb1, green:usb2, green:wlan2g and green:wlan5g).
<f00b4r0>
ah yes I think you're right
<f00b4r0>
sorry
<rsalvaterra>
f00b4r0: Just to make sure, do you have a tp-link subdir in /sys/class/leds?
<f00b4r0>
lemme check
<f00b4r0>
nope, same as you listed
<rsalvaterra>
The switch leds should theoretically be in this elusive tp-link subdirectory.
<robimarko>
Dont you have to register those LED-s via 01_leds and ucidef_set_led_switch?
<rsalvaterra>
I didn't dig any deeper yet, I just expected this to be working out of the box. Principle of least surprise, and all that… :)
<Ansuel>
are you sure you have the flag enabled?
<Ansuel>
on swconfig they were configurable
<rsalvaterra>
Hm. Which flag?
<Ansuel>
swconfig-leds ?
<rsalvaterra>
I don't know if I have that flag. Where can I see that?
<stintel>
anyone else seen similar crashes? there's been a bunch of changes to uclient-fetch recently
<nbd>
stintel: i'd suggest putting ulimit -c unlimited in the script calling uclient-fetch
<nbd>
and grabbing a coredump
<nbd>
i'll help you look into the crash cause if you get me a proper backtrace
<stintel>
could be something ppc related, on one of my devices netifd appeared to have crashed also, unfortunately I was not at home and other logs overwrote any useful log info
<stintel>
hmmm looks like ddns-scripts don't use procd
<rsalvaterra>
stintel: What's your ddns provider?
<stintel>
myself
<stintel>
(a php script)
<nbd>
stintel: you can edit the script from ddns-scripts and put the ulimit line just above the uclient-fetch call
<nbd>
no need to put it in the init script
<rsalvaterra>
stintel: I use freedns, but I wrote a trivial ad-hoc script in /etc/udhcpc.user.d. That way I only make a request when my address effectively changes.
<stintel>
hah
<stintel>
apparently it already writes core files
<stintel>
of course I have no symbols
<stintel>
how would I go about running that core file through gdbserver?
<jow>
hostapd runs as non-root, so you likely won't be able to interact with uci files
<jow>
at least when assuming the default 0600 permissions
<Ansuel>
ugh i hoped it was acl problem and not permission... any idea how to handle that?
<Ansuel>
hostapd should call an ubus service that runs as root i guess???
<Ansuel>
but what would be the correct way to do it
<jow>
maybe you had this discussion already, but writing state data into /etc/config/ is a no-go imho
<jow>
the natural place to store that would be something like /var/run/
<Ansuel>
this data needs to be restored on reboot
<Ansuel>
or wpad restart
<jow>
why can't a user just add it to /etc/config/wireless then?
<Ansuel>
hostapd generates a per-device psk when WPS push button succeeds. this pks needs to be saved in uci file
<jow>
well programmatically writing uci is destructive
<jow>
it will nuke user comments, it will reformat the file, it might commit intentionally uncommitted changes or apply an incomplete set of changes in the middle of a user session
<jow>
it feels wrong. Such kind of state info should go to /var/run/ or -if it needs to persist- somewhere else in /etc
<jow>
but it should be outside of /etc/config/wireless
<Ansuel>
/etc/hostapd maybe?
<jow>
yeah, something like that. Or named after the function, /etc/wps/...
<Ansuel>
my idea was to also expose these per device psk in luci... would it be ideal to have the config in uci format
<Ansuel>
?
<jow>
probably more hassle than what its worth
<Ansuel>
or i think i will just provide an helper in ubus to dump them
<jow>
just write hostapd's native format
<jow>
then you can simply cat it into the generated config, along with the other entries generated from config wifi-station uci sections
<Ansuel>
mhhh ok
<Ansuel>
thanks for the hint
<jow>
upside is also that you can simply do an rm -f /etc/wps.conf && wifi up
<jow>
to clear out any kind of automatic wps associations
<jow>
wrt. luci, you can maybe use luci-app-upnp as role model
<jow>
it also works with the miniupnpd lease file directly
<Ansuel>
ok i think with this last thing, the feature is ready nice
<Ansuel>
at the end i decided for /etc/hostapd/hostapd-phy2-ap0.wps_psk (etc/hostapd network permission) and hostapd creates the file as soon as an entry is created
<Ansuel>
seems easier to handle than having to parse the file everytime for each phy