<djfe>
wait now they are back. a couple hours ago they were gone
<djfe>
nvm then
<jow>
hauke: this commit here was a bit unlucky: https://git.openwrt.org/?p=project/rpcd.git;a=commitdiff;h=c07ab2f91061ad64209e9aaa1fb1b77061a1af25;hp=31c390727b83c9efd768c7aa258813e6084b46a3
<jow>
hauke: I would've preferred to add new fields with a 64 suffix
<hauke>
jow: Ok, I will use new fields next time
dangole has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
<jow>
hauke: I would've preferred to add new fields with a 64 suffix
<jow>
bah sorry, arrow up fail
<jow>
hauke: maybe this particular change wasn
<jow>
't a problem after all, just noticed various reports about missing station info in luci, allegedly caused by upgrading rpcd-mod-iwinfo
<jow>
so I guess some abi broke, again
<hauke>
jow: that is maybe related to this change
<hauke>
for me it works in a fresh build
<jow>
the actual problem likely was the libiwinfo changes
<hauke>
so I assume it should be fixed in rc3
<jow>
luci is dlopen'ing libiwinfo and expects certain struct layouts
<jow>
hauke: here's the luci side: https://git.openwrt.org/?p=project/luci.git;a=blob;f=libs/rpcd-mod-luci/src/luci.c;h=e21105d3c6e301049fa5b84dc7f3fbc0572825ca;hb=09d5de617c2cb21b8b67dc8f54a181ebd8023fd3#l950
<jow>
hauke: however client info is handled via rpcd-mod-iwinfo
<jow>
since libiwinfo has no proper abi tracking (or at least the abi version was not bumped after the 64bit counter change), it was possible to install a new rpcd-mod-iwinfo expecting 64bit counters abi while having an old libiwinfo with 32bit counters abi
<jow>
in any case, doing such data type changes, in the middle of a struct, durcing the rc phase, involving core libraries and touching the ui is likely to blow up
<jow>
but I can understand why it was applied, looks innocent enough and one can't spend hours for every trivial change or fix request
<jow>
ideally we shouldn't touch iwinfo(-abi) once we branched
<jow>
the luci-rpcd plugin will glob for the library and use the first one it found, this could still lead to abi issues
<jow>
it should probably try to load exactly the abi suffixed version it was compiled against
<jow>
as it stands right now, a rpcd-mod-luci built against new libiwinfo will still dlopen the old one on systems having multiple versions installed (e.g. after opkg upgrade)
<jow>
this could lead to various broken things (and would explain the reports about missing channel selection in luci)
<hauke>
yes you are right
<jow>
lot's of grunt work though, iwinfo.git would need to expose its build time ABI_VERSION value into a public header somewhere so that we can use it elsewhere to determine the version
<jow>
probably not worth to fix since in the long run we'll get rid of it anyway since everything we support is native cfg80211 anyway, so no need for an extra abstraction
schwicht has joined #openwrt-devel
DLange has quit [Quit: CU. Soon.]
DLange has joined #openwrt-devel
<hauke>
jow: do you want to expose cfg80211 directly to luci?
<hauke>
at least it is a stable ABI which only gets extended in a backwards compatible way
<jow>
luci access wifi info through ubus luci.getWirelessDevices and iwinfo.*
<jow>
the former is a proxied call to ubus network.wireless/status that simply adds iwinfo data to each interface before returning the reply
<jow>
the latter is querying some iwinfo data directly, but both can be replaced with some trivial ucode + nl80211 calls that provide the same output format
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]