<nitroshift>
anyone working on linux 5.10 support?
<mangix>
I am not
Borromini has joined #openwrt-devel
Borromini has quit [Ping timeout: 272 seconds]
mangix has quit [Read error: Connection reset by peer]
<stintel>
nitroshift: see ML, there were people working on 5.9, might be they shifted to 5.10 now it's in rc
<nitroshift>
stintel, o/
<stintel>
\o
<nitroshift>
thanks, i'm already running 5.9 on my rango's
<nitroshift>
5.10 is in initial phase, breaks the build at backports
<nitroshift>
stintel, if you want and have time i can send you the patchset
<stintel>
nah, I don't have time
eduardas has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
Borromini has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
victhor has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
swex has quit [Quit: swex]
Nick_Lowe has joined #openwrt-devel
<blocktrron>
blogic: np. we were offering the implementation of such a steering daemon as a lab topic @university and two days prior to the first group meeting, you've pushed usteer
<blocktrron>
Were in the process to make the necessary changes in order to run it in our community network and fix some other stuff we think might be a good idea along the way.
feriman has quit [Quit: WeeChat 3.0]
feriman has joined #openwrt-devel
mangix has joined #openwrt-devel
feriman has quit [Read error: Connection reset by peer]
<blogic>
blocktrron: awesome
feriman has joined #openwrt-devel
<blogic>
blocktrron: works really well for me
Borromini has quit [Ping timeout: 256 seconds]
<blogic>
i have a mesh, 6 nodes, 2 with uplink around house/garden
<blogic>
with 11r also enabled i can walkaround with voice/video calls running and get 0 interruptions
<blocktrron>
This is also the experience with it in my home network (although it's only 3 nodes)
<blocktrron>
However, our network is more like 100 nodes, so we need to tackle neighbor discovery there.
<blocktrron>
Also, the hearing map does not work well as soon as APs use DFS channels, as they cannot perform active probing on these.
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
feriman has quit [Ping timeout: 260 seconds]
<blogic>
ok
<blogic>
blocktrron: well, looking fwd to your patches :-D
<nitroshift>
rsalvaterra, o/
<rsalvaterra>
Hey, nitroshift! o/
danitool has joined #openwrt-devel
<rsalvaterra>
blogic: usteer…! Does this mean we'll have true band-steering in OpenWrt soon(ish)? ;)
<rsalvaterra>
But having a separate daemon for it strikes me as a bit odd… Shouldn't band-steering be one of hostapd's responsibilities? (Especially now, since all APs are managed by a single hostapd instance…)
<blogic>
rsalvaterra: it talks to hostapd via ubus
<rsalvaterra>
Yeah, I saw that, I was just wondering if makes sense to have a separate daemon (technically; politics is another story).
<blogic>
its the only sensible solution
<PaulFertser>
rsalvaterra: if you just need band steering between two APs both handled by a single hostapd instance you can try adding the relevant option to config. But I think blogic is solving a different, more complex problem which involves plenty of APs running on different nodes.
<rsalvaterra>
PaulFertser: Ah, I see. I was thinking only of a single AP.
<rsalvaterra>
So this is more like "distributed band-steering".
<ynezz>
dedeckeh: hi, I've found some strange issue with odhcp6c which leads to OOM http://sprunge.us/vv0Idx
<ynezz>
dedeckeh: it simply happens every time after about 10-12 hours for me when I boot the system in QEMU and have LAN/WAN connected there
<ynezz>
dedeckeh: that RENEW retry timeout is being decremented from 13060s down to 1s during a few hours, then it seems to trash the machine completely
<ynezz>
dedeckeh: nothing is happening on that machine, I just boot it and then let it idle
<ynezz>
dedeckeh: that `netifd: wan6 (2341): cat: write error: Broken pipe` is probably start of the out of memory situation
<ynezz>
dedeckeh: that `SQUASHFS error: xz decompression failed, data probably corrupt` is the end, the device is then going to OOPs soon