<Namidairo>
you still kind of need a daemon assessing the reports and kicking in order for proper "steering"
<Namidairo>
clients are sometimes a little reluctant to roam unless the signal is overwhelming high/low or you start setting preferred band settings etc.
c0sm1cSlug has quit [Read error: Connection reset by peer]
c0sm1cSlug has quit [Read error: Connection reset by peer]
c0sm1cSlug has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
minimal has quit []
srslypascal is now known as Guest301
srslypascal has joined #openwrt-devel
Guest301 has quit [Ping timeout: 480 seconds]
<atomiclycursed>
Hey all, is any one experienced in the code surrounding tplink-safeloader.c, looking to get official support for a tp link device and am a bit stuck currently looking for a bit of clarification!
bluew has quit [Remote host closed the connection]
bluew has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
amaumene has quit [Quit: amaumene]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
GNUmoon has quit [Ping timeout: 480 seconds]
<mangix>
hauke: ksmbd update is missing
cmonroe_ has joined #openwrt-devel
Tapper has joined #openwrt-devel
gch981213 has joined #openwrt-devel
rua has quit [Quit: Leaving.]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
GNUmoon has joined #openwrt-devel
<PaulFertser>
atomiclycursed: just ask a specific question
<neggles>
Slimey: attempting to band steer almost exclusively causes more problems than it fixes
gch981213 has quit [Quit: leaving]
<neggles>
an AP cannot know what the signal conditions etc. are like at the client end, and any vaguely decent client device will automatically shift bands as signal conditions allow - quite reliably on any 802.11ac device and most 802.11n dual-band devices
<neggles>
the only thing an AP can do to try and influence that is repeatedly deauthenticate the client & pray it connects to the "right" radio
<neggles>
this almost always just results in a bunch of packet loss because your AP has decided that you should be using 5GHz, but it doesn't know about [list of reasons the client has for not using 5GHz right now], so it sits there deauthenticating you forever
valku has quit [Remote host closed the connection]
<PaulFertser>
But why would it happen that the client can probe the AP on 5 GHz but not actually use it?
<neggles>
APs are generally capable of quite significantly higher TX power than most clients, have better antennas
<neggles>
it's not at all uncommon for a client to be able to hear an AP on 5GHz but not vice-versus
<PaulFertser>
I'm talking about hearing a probe from the client, so TX power doesn't play a role in this specifically.
<neggles>
AIUI the AP beacons and the client decides what to attempt to associate with based on those beacons (ignoring 802.11k/r/v for the time being)
<PaulFertser>
hostapd's integrated band steering takes into account reception of active probe frames from a client.
<neggles>
OK - there may be local interference on the client end that makes it unusable which the AP can't hear, for one
<neggles>
what client device *won't* choose to use 5GHz when it has the option?
<PaulFertser>
I agree it's the client that should be deciding if the client is sane.
<neggles>
and if your client is *not* sane, chances are it's not going to need enough bandwidth for 2.4GHz vs 5GHz to matter...
<PaulFertser>
I do not have personal experience but apparently many people report that band steering helps them.
<neggles>
the plural of anecdote is not data, but in my experience, across dozens of networks big and small, time and time again i've had it cause nothing but trouble
<neggles>
with one notable exception which was a very-high-density deployment where 2.4GHz was essentially unusable (small sports arena type thing)
<neggles>
even on that deployment we ultimately just disabled 2.4GHz entirely
<PaulFertser>
I see people added support for kicking clients here so it must be working for them: https://git.openwrt.org/?p=project/usteer.git;a=tree
<neggles>
I would love to hear from someone who has fixed something with band steering and actually has data to back that up.
<neggles>
(that's not meant to sound dickish, i really would)
<neggles>
but not for lack of trying, all i've been able to find is people saying that it "fixed their problem" or had some incredibly broken client device that would've been better served by an extra 5GHz-only SSID
<neggles>
(and the aforementioned very-high-density deployments)
<neggles>
it seems a bit placebo-effect-y, or like they just see "connected to 5GHz" and assume everything is better
<neggles>
just a couple weeks ago I had a friend complaining about his unifi setup having bad roaming performance, dropouts in airplay audio streams whenever more than a few meters away from an AP, inability to roam between APs while on a VoIP call without it dropping out - band steering. disabled it, all of those issues disappeared.
<neggles>
sure, that's partly Because Ubiquiti, but
<PaulFertser>
I'd like to hear blocktrron about that, yes.
<atomiclycursed>
for flash_partition_entry how important is it that names match what's in the original firmware
<atomiclycursed>
also where does tplink-safeloader.c sit in master these days or it's equivalent?
goliath has joined #openwrt-devel
<neggles>
atomiclycursed: generally you want to keep the original firmware partition table and names, if at all possible
<atomiclycursed>
neggles: thanks, the build is hitting tplink-safeloader: src/tplink-safeloader.c:2772: put_partitions: Assertion `flash_parts[j].name' failed. and I was assuming it's due to me just doing a blanket copy/paste from the original firmware given all others appear to have moved to a simplified list
<neggles>
atomiclycursed: sounds like a formatting issue with your DTS? but I've not done any tp-link things in a long while so not exactly familiar with what safeloader does
<PaulFertser>
atomiclycursed: looks like a name wasn't assigned at all.
<PaulFertser>
So NULL instead of NUL-terminated string.
<atomiclycursed>
thanks, I'll do a better compare from a working one, I didn't want to change too much as it was working on the 19.07 branch, I did clean it up but maybe I removed something I shouldn't have!
<atomiclycursed>
having 15 partitions should be fine then as long as safeloader and dts match?
<jow>
hauke: 19.07 branch is fine, for 21.02 I'd like to backport a bunch of fixes yet
<jow>
(in LuCI)
goliath has quit [Quit: SIGSEGV]
<blocktrron>
PaulFertser: network assisted roaming can help to apply policys you've configured to the clients selection behaviors
<blocktrron>
steering clients on connect is hit or miss and i would generally not do it
<blocktrron>
in the end, roaming behavior is implemented on the client. 802.11v offers BSS transition management which allows a ESS to send prioritized requests to the STA which the STA can accept or not
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
felix has quit []
felix has joined #openwrt-devel
<PaulFertser>
blocktrron: thank you. Not sure I understand how to apply this knowledge to real life scenarios neggles was talking about.
<rmilecki>
nf_flow_offload_ip_hook() crashes kernel on my GT-AC5300
<rmilecki>
this happens as soon as i start iperf traffic
<rmilecki>
ping doesn't trigger it
<neggles>
blocktrron: that makes sense & is pretty much what I thought - an AP can’t reliably determine which band a client “should” be on, it just doesn’t have a way to know
<blocktrron>
neggles: this is not true
goliath has joined #openwrt-devel
<neggles>
i should’ve finished the second half of that thought before hitting send
<blocktrron>
the ESS can request measurements from the client with thich he gets the RCPI and can evaluate the clients surroundings
<neggles>
AP can’t tell *without 802.11k/r/v*
<neggles>
blocktrron: assuming the client supports that :P
<neggles>
if a client implements all the functionality necessary for AP-assisted steering to work properly, it seems likely that it would also be sane enough to make the right decision without assistance, in the majority of networks
<neggles>
of course there’s always going to be exceptions - large/high-density deployments, challenging RF environments, etc - and 802.11k/r/v can do some very cool and good and clever things when appropriately configured, but most of the time when people talk “band steering” they’re talking about the stupid “deauthenticate device repeatedly until it changes band” stuff and that’s just
<neggles>
never a good move
<neggles>
and most networks don’t have k/r/v :(
<neggles>
maybe I should flash a few spare NanoHDs with OpenWrt and try getting that all set up and working again
<f00b4r0>
question for the network experts: on an OpenWRT router if I want fairness between hosts behind the router and cannot shape uplink (because speed is unknown/variable), I should use fq_codel instead of cake, correct?
<lemmi>
i think you want to prefer cake
danitool has joined #openwrt-devel
KGB-0 has quit [Ping timeout: 480 seconds]
dangole has joined #openwrt-devel
amaumene has joined #openwrt-devel
hexagonwin has joined #openwrt-devel
hexagonwin has quit []
eduardo010174 has joined #openwrt-devel
<rmilecki>
that nf_flow_offload_ip_hook() crash is caused by firewall.@defaults[0].flow_offloading_hw='1'
<rmilecki>
it's weird as my hw doesn't even support hw offloading
<rmilecki>
nbd: jow: ^^
<f00b4r0>
lemmi: I was under the impression cake /requires/ shaping to work. I'll go investigate again :)
rsalvaterra has quit [Quit: rsalvaterra]
rsalvaterra has joined #openwrt-devel
amaumene has quit [Read error: Connection reset by peer]
amaumene has joined #openwrt-devel
rua has joined #openwrt-devel
atomiclycursed has quit [Remote host closed the connection]
<blocktrron>
neggles: client support is not much of an issue these days. Only large platform with lacking support is macOS and Huawei mobiles (nobody wonders about this)
<blocktrron>
The desire to use band-steering comes from poor network planning w/o coverage overlaps on higher frequencies
<stintel>
arduino's and esp mcu's are also terrible at roaming
<stintel>
but I have yet to test if usteer has any positive impact on that
eduardo010174 has quit [Quit: Leaving]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<f00b4r0>
blocktrron: ISTR claims that Apple says their device can better select the correct operation band (vs being steered). In my (very limited) experience it works rather well
pmelange has joined #openwrt-devel
<blocktrron>
f00b4r0: i can second that
<blocktrron>
Where BTMs make a lot of sense is in high-density or multi
<blocktrron>
-radio scenarios for load-balancing clients
<f00b4r0>
ah i see
<blocktrron>
Roaming for a moving target has to happen for the client side mostly (and is supported by narrowing down bands to scan using neighbor reports)
<Namidairo>
wtf do they really not support 11k/r/v except on their new arm macs
<Namidairo>
thanks broadcom?
<f00b4r0>
Namidairo: they support it on iphones. I guess they assume laptops aren't "moving" as much
<f00b4r0>
i didn't know M1 macs supported it, that's good news I guess
KGB-0 has joined #openwrt-devel
pmelange has quit [Ping timeout: 480 seconds]
<rmilecki>
nbd: is that BR_OFFLOAD upstreamable?
<nbd>
rmilecki: it's a temporary solution
<nbd>
i plan on building a replacement using xdp and a userspace daemon
<nbd>
upstream will not accept an offloading solution that hooks into the bridge layer
<rmilecki>
ack, thanks
<nbd>
the performance improvement of that code is significant enough that i decided to push it to openwrt until my replacement is ready
<nbd>
on 7622+7915 it's a 6-10% cpu usage reduction for lan->wlan bridging
<nbd>
on weaker platforms probably even more
<Namidairo>
is the comment about the net_bridge_port correct though
<Namidairo>
oh wait I see what they're talking about
<Namidairo>
it's unreachable because you already checked for it
<rmilecki>
nbd: i hope it's a correct fix and it doesn't just avoid race by accident
<rmilecki>
looks good in testing though!
<nbd>
i don't think it's an accident. when reviewing the code, i could clearly see the race
<rmilecki>
great :)
<rmilecki>
thanks for fixing that nbd!
<nbd>
thanks for reporting & testing
<nbd>
i will push the fix
<nbd>
done
Misanthropos has joined #openwrt-devel
<rmilecki>
nbd: if I have "flow_offloading" set to 1 AND "flow_offloading_hw" set to 1 AND hardware without offloading - does kernel use software offloading
<yolo>
worked with openwrt for one board a time so far, now I need work with multiple boards and multiple versions(master and 21.02) in parallel, is it recommended I just checkout openwrt to different directories for each project, or openwrt can cope with multiple-branch/multiple-board build "safely", something like yocto's loca.conf changes that I can build multiple revisions/boards under one topdir.
<zorun>
for multi-arch, I think there is a feature to easily save/restore config files
<zorun>
for multi-version, better use separate directories, you'll run into issues if you often change branches