<ynezz>
since it seems, that you're able to reproduce it, it would help a lot to know the result as it seems, that it's delaying 22.03 release and we're probably heading towards -rc7
<mangix>
hmmm I should probably build 22.03
<ynezz>
ah, so it's not present in master?
<ynezz>
there seems to be same dropbear version being used, granted I didn't read those walls of texts completely, so I've missed that
<jow>
Mangix: reopened
<jow>
ynezz: it remains unfixed and dropbear version used in master/22.03 triggers it, even on older devices
<mangix>
alright
<mangix>
fresh flash of rc6 through AUC does not exhibit the issue
<mangix>
jow: are those nft command persistent?
<jow>
Mangix: no
<mangix>
hmmm why is this working
<jow>
the people in the forum said it sometimes takes a while for the bug to trigger
<jow>
letting an ssh session running with some kind of self refreshing content (like top/htop) usually suffices to make it stall eventually
<ynezz>
jow: I'm just afraid, that if we remove that IP_TOS support from dropbear, then other half of folks are going to complain, that we've crippled their smooth experience
<jow>
ynezz: it would be just a revert to the prior state
<jow>
ynezz: as far as I understand, it simply wasn't done in a previous version
<mangix>
ummm
<mangix>
that's not a long term solution
<jow>
Mangix: of course not, it just ensures somewhat reliable ssh access in the interim
<mangix>
wouldn't VoIP and whatnot be affected?
<jow>
yes, of course
<jow>
but they would also already be affected with older versions
<ynezz>
idea is, that anyone affected could turn this off, rest doesn't care
<ynezz>
once fixed we could easily revert this workaround
<ynezz>
dunno if this should be propagated to the LuCI layer, but probably it should to improve UX
<ynezz>
and LuCI would also as well help in case the device is not reachable over SSH anymore
<ynezz>
maybe we should do it other way around, disable it by default and nerds can enable it
Shawn has joined #openwrt-devel
<jow>
ynezz: too much effort, simply revert it to the previous version
<jow>
- it wouldn't be an ux regression
<jow>
- powerusers caring about ssh performance likely run openssh anyway
<jow>
- we should avoid touching security sensitive code (granted, this seems harmless, but still)
<T-Bone>
+3 :)
T-Bone is now known as f00b4r0
<jow>
- we're introducing a knob here which we'd need to maintain in the long run and if upstream eventually introduces it's own knob we will have compatibility and migration headaches
<jow>
- also available single letter flag names are limited so it is likely that -z eventually gains another meaning
<f00b4r0>
and hopefully a fix for the actual underlying problem will be found, at which point we can smoothly revert the revert without much fuss
<f00b4r0>
instead of having to carry over the new flag forever
<jow>
this isn't meant to be a long term thing after all, just a very loose band-aid to buy some time investigating mt76
<jow>
without imparing ssh access for the common user (use-case)
danitool has joined #openwrt-devel
<dwfreed>
does this only affect the transmit side (openwrt -> client), or does it affect the receive side (client -> openwrt) too?
<jow>
dwfreed: I think nobody tested it yet
<jow>
can iperf set DSCP marks?
<jow>
then it migh be a better tool for testing
<dwfreed>
yes
<jow>
how? /DSCP finds nothing in my local desktop man page
<dwfreed>
may be only in recent versions?
<dwfreed>
it's in the debian unstable manpage
<dwfreed>
which is 3.11
<jow>
ah, probably too old here, then
<jow>
iperf version 2.1.7 (11 April 2022) pthreads
<dwfreed>
iperf3
<jow>
right
<dwfreed>
yeah, specific to iperf3, but also available in bullseye, not just unstable
<dwfreed>
you can set the IP_TOS field, but I forget how ToS and DSCP interchange
<dwfreed>
(in iperf 2)
<jow>
allegedly it understands symbolic names
<jow>
iperf3 --dscp af21 ...
<jow>
Mangix: can you redo the testing using iperf3 between router and client?
<jow>
Mangix: and try to trigger stalls/low throughput situations?
<jow>
if you manage to reproduce, can you then try to swap the client and server roles?
Shawn has quit [Quit: Leaving...]
<mangix>
jow: I'll do it later today. Need sleep.
<jow>
ta
indy_ has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
robimarko has joined #openwrt-devel
xback has quit [Ping timeout: 480 seconds]
xback has joined #openwrt-devel
<stintel>
anyone ever managed to get uxc to actually start a container?
<stintel>
documentation is very slim, and I keep hitting uxc error: No such file or directory
<stintel>
strace is not helpful
<dwfreed>
pastebin the strace?
<aparcar[m]>
we added support for apk/auc so you would have some kind of docker replacement
<ynezz>
but could be a good base for some wiki page on openwrt.org
Gaspare has quit [Quit: Gaspare]
nbd has joined #openwrt-devel
robimarko_ has quit [Quit: Leaving]
Gaspare has joined #openwrt-devel
Slimey_ has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
Slimey__ has joined #openwrt-devel
danitool has joined #openwrt-devel
Slimey has quit [Ping timeout: 480 seconds]
Slimey__ is now known as Slimey
Slimey_ has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
ekathva has joined #openwrt-devel
ekathva has quit []
<hauke>
Did someone use ubus in a pthread heavy application? Currently ubus lib is build to use some epoll loop mechanism like uloop. I would like to invoke methods from multiple pthreads and register objects with notifications on ubus. My idea was to put this all into one thread, use some epool loop there and then inform this thread about invocations and notifications to send over ubus.
<nbd>
ubus is not thread safe, so if you want to deal with it from multiple threads, you need to use locking
<nbd>
at least if there's any direct interaction between ubus and other threads
<nbd>
if you isolate it purely onto one thread, it should work as well
<hauke>
my plan was to isolate it into one thread
<nbd>
should be fine then
<hauke>
and make my appliation tell this thread what to do
<nbd>
btw. i pushed a fix for the wifi over ssh issue with the last mt76 update
<nbd>
once it's confirmed, we can backport it to 22.03
<hauke>
nbd: do you know an epoll loop implementation where I can add extra tasks from other pthreads?
<hauke>
like pthread A tells pthread with ubus to send an invoke
<hauke>
nbd: does ubus work when it is called from multiple pthreads, but with locking?
<hauke>
nbd: thanks for the mt76 update
<hauke>
nbd: I think the mt76 DSCP issue is only seen on 22.03 and not on master
<nbd>
i was able to reproduce issues with it on master
<nbd>
by forcing restart of tx aggregation
<hauke>
nice
<hauke>
is this only seen on mt7615 or also mt7915?
<nbd>
only 7615,7613,7622 (covered by the same driver)
<nbd>
from what i can tell
<nbd>
and the code bug that i fixed is specific to the mt7615 driver