<ea8500>
Hello everyone. I wanted to share what I found when using the Linksys ea8500 router. In June 2021 I purchased a Linksys ea8500 router, from the first moment I noticed poor performance on the 2.4 GHz wifi, I found that it improved if I placed option ieee80211w '0' in the wifi-iface in the /etc/config/wireless file. But still the performance was poor and unstable. After a lot of searching I found this post https://github.com/greearb/ath10k-ct/issues
<ea8500>
which mentions a similar problem and the difference between using the stock firmware and the Candela Technologies modified firmware. In the tests they obtained better results with the stock firmware, so I decided to try it, and it was a success! the ath10k-firmware-qca99x0 firmware works optimally on my Linksys ea8500 router, while the default one (ath10k-firmware-qca99x0-ct), does not.
jlsalvador has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
<mangix>
ea8500: note that it is possible to mix and match drivers and firmware
danitool has quit [Ping timeout: 480 seconds]
<mangix>
will[m]: use ccache
<will[m]>
<champtar> "did you by any chance had..." <- I'm using the open wrt SDK docker image and just keeping it open in between runs. Every time I try having the SDK or build route on my laptop directly it gets corrupted and I need to repull it, so I'm trying to snapshot something repeatable that I can reset when necessary.
<will[m]>
<mangix> "will: use ccache" <- Will check that out, thank you
kenny1 has quit [Ping timeout: 480 seconds]
<mangix>
aparcar[m]: so layerscape failed. restool succeeded but tfa-layerscape failed. I can't reproduce locally.
<mangix>
the only difference is I use binutils 2.37 locally. Maybe that's enough to fix.
<rsalvaterra>
Seems like we're clear for the GCC 11 bump… :) https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f9050f1c435bfc8593eeb689ebde5fd04ff41e66
<mangix>
mhmm
<mangix>
hauke should be merging the musl 1.2 stuff soon
Tapper has joined #openwrt-devel
<rsalvaterra>
Finally! ;)
<jow>
will[m]: do you use the SDK? If so, try disabling menuconfig [*] Advanced configuration options (for developers) ---> [ ] Automatic removal of build directories
<aparcar[m]>
I'll go ahead and merge gcc11 once I gave it a final runtime test
<Tusker>
I am trying to get the DSA switch configured within the DTS for the WatchGuard xtm33 I am porting. the switch detects on the mdio on 0x11 and 0x10, and there seems to be a phy on 0x1f (with a status of down) on the same mdio bus, and it returns a reasonable status like 1000mbit. there are two ethernet devices which look like they should connect to those two 0x10 and 0x11 (which is looks like in the factory boot logs), but I can't figure out wha
<Tusker>
any ideas anyone? :)
<aparcar[m]>
mangix: merged, thanks again for you help
<mangix>
cool. may the unexpecterd failures in the packages feed begin :)
danitool has joined #openwrt-devel
<mangix>
should just be 1 or 2 packages
<mangix>
ah yes, libuwsc will break
rua has quit [Quit: Leaving.]
Kali_ has joined #openwrt-devel
<Kali_>
I got a question: How do i pass custom variables into ubus object callbacks?
<Kali_>
(without using global variables)
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
pmelange has joined #openwrt-devel
pmelange has quit [Quit: Leaving.]
<rsalvaterra>
Yikes. I think I'm going to have a 500 Mb/s internet connection soon. I don't have a router capable of (cake) shaping at that speed. :|
<rsalvaterra>
#firstworldproblems
<mangix>
Don’t use cake. Problem solved
<rsalvaterra>
Maybe the Omnia… but it will be begging for mercy, for sure.
<stintel>
rsalvaterra: get an m300 ;)
<Tusker>
OK, so the mdio tool can see the marvell ports, but it can't see it when specifying in dts - https://pastebin.com/X004b5JV
<rsalvaterra>
Fun fact: the plan is for bpftables to use the exact same iptables syntax.
<karlp>
mrkiko: not even looking at it, only concern with trying to get both ethernet ports link detection working.
<mangix>
eBPF is only compiled with clang I believe. Wonder if it’s possible to use a clang toolchain in OpenWrt. My guess is no.
<lemmi>
rsalvaterra: last time i checked, ingress shaping was done through
<mangix>
Clang gets built weird. It uses a monorepo structure.
<Kali_>
well
<lemmi>
rsalvaterra: last time i checked, ingress shaping was done through ifb device. that causes the packet to pass through the router multiple times
<lemmi>
rsalvaterra: i suggest disabling ingress shaping. what i do is mark packets from wan and the have 2 DRR qdiscs on my lan interface. one for lan traffic, one for traffic coming from the internet.
<lemmi>
that way i don't rely on ifb devices, performance is much better this way
<Kali_>
mangix: i think you can pre-compile it with a clang cross-compiler into .(s)o files and use buildroot to link them.. i think, i might be speaking out of my ass here
<rsalvaterra>
lemmi: There's no other way to do ingress shaping. To decide what to do with a packet, you need to receive it first, hence the ifb. :)
<rsalvaterra>
XDP could potentially accelerate that process, I think.
<mangix>
Kali_: I mean more like adding toolchain/clang or llvm.
<Kali_>
yeah that would require a lot more work
<mangix>
One benefit if that is faster compilation. LLVM uses CMake
<lemmi>
rsalvaterra: i just explained how it works
<lemmi>
rsalvaterra: firewall mark on ingress, extra qdisc for downstream links that do shaping on egress
<mangix>
So regarding bufferbloat. Why not just set all user configurable buffering to low levels?
<SwedeMike>
hard to control the ISP upstream router egress buffer size
<mangix>
You mean modem?
zatwai has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
<SwedeMike>
mangix: because it depends on the application if big buffers are good or not, thus non consensus on what the buffer depth should be
<lemmi>
mangix: yeah.. it's about the buffers you don't control
<SwedeMike>
mangix: no, I mean the egress buffer of the BNG or whatever they might call their router.
zatwai has joined #openwrt-devel
<SwedeMike>
CMTS etc
<mangix>
Hrm unfortunate
<SwedeMike>
that's what ingress shaping tries to solve, to minimize the hits to the ISP FIFO
<mangix>
Anyway, I’ll be using HWNAT. Don’t need cake :)
<SwedeMike>
s/don't need/can't use/
<mangix>
lol. FWIW DOCSIS 3.1 modems use pie.
<lemmi>
mangix: in essence you want to be the chokepoint. if everything else is faster, their buffers wont fill
<SwedeMike>
actually both my previous DOCSIS access and my current FTTH aren't bloated, they have 10ms FIFO so it's not strictly needed to do ingress shaping
<SwedeMike>
but I do it anyway, because I'm a nerd who likes AQM
<mangix>
This pali guy is comedy gold.
<mangix>
Hmmm should I bite?
rua has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<stintel>
testing 5.10 on octeon since today
<stintel>
I'll probably make that the default in a couple of weeks if I don't hit issues
<stintel>
and after that I'm retiring my octeon hw
<stintel>
now strace doesn't build all of a sudden
<stintel>
anyone using a Zyxel NBG6817 with master? got a report that sysupgrade to snapshot from master doesn't boot
<dwfreed>
still on 19.07, not brave enough to even go to 21.02
jbowen has quit [Quit: leaving]
<hauke>
aparcar[m]: mangix: stintel: I pushed the musl 1.2 update
<hauke>
thank you mangix for your work on it
<stintel>
hauke: thanks for pushing it
Borromini has quit [Quit: Lost terminal]
goliath has quit [Quit: SIGSEGV]
<rsalvaterra>
OMFG, musl 1.2 was merged, I can finally delete my branch! :D
<Habbie>
wow
<Habbie>
in what openwrt release can we expect it? :)
<rsalvaterra>
22.x.
<Habbie>
ok
<stintel>
I'll give you a more smartass answer: the next one
<Habbie>
oh, 21.02 is out
<Habbie>
i missed that
<stintel>
welcome in September 2021, Habbie ;)
<Habbie>
i'm pretty sure september is not month 2!
<Habbie>
so that brings me to another question
<stintel>
¯\_(ツ)_/¯
<Habbie>
if a user installs 21.02 today, they'll get the packages tree as it was 'at some point', right
<Habbie>
if i update a package on master
<Habbie>
should i also PR to the 21.02 tree?
<stintel>
they'll get the openwr-21.02 branch of the packages tree
<stintel>
if that's a non-breaking version bump yes
<Habbie>
right
<Habbie>
or in case of a CVE, maybe just add a patch then
<stintel>
yeah
<Habbie>
so like Debian
<stintel>
I don't think we do hard version freezes, especially in the feeds
<stintel>
it probably depends on the maintainer
<Habbie>
i'm the maintainer in this case
<stintel>
I rarely merge anything to the release branches because I simply don't run them
<stintel>
and I prefer to not merge what I don't run
<Habbie>
yes, fair
<rsalvaterra>
stintel: And here's a cynical comment: your answer is the correct one since, given the current tendency, we don't know if the next release will be a 22.x. :P
* rsalvaterra
braces for impact
<stintel>
rsalvaterra: :)
<stintel>
let's hope we can have a 22.<6
<stintel>
anyway, I should bisect that fscking fw3/ipset issue
<stintel>
I kind of have the feeling that nobody uses anything, how else can this issue have gone unnoticed :/
<rsalvaterra>
stintel: Hm… maybe something changed in the meantime, in terms of configuration?
<stintel>
no, absolutely not
<slh>
stintel: I'm running master/ r17525-a46fa5c3a7 with DSA PR#4036 musl and mac80211 updates pulled in, no recent issues with sysupgrade
<slh>
on my nbg6816
<slh>
err, nbg6817
<stintel>
slh: thanks
<slh>
I usually update once a week or once every two weeks at most
<slh>
depending on what happens in master
<stintel>
I'll suggest my colleague tomorrow to try resetting with the button (if it has one?)
<stintel>
maybe some config got hosed and reset would fix the thing being unreachalbe
<slh>
the easiest way is to switch to the other (old) partition and upgrade from there
arifre has joined #openwrt-devel
<slh>
but yes, the nbg6817 has a very reliable push-button tftp recovery (fetching from a tftp server on your client)
<stintel>
I've 0 experience with this device so I'm kind of blind here\
<stintel>
but thanks for confirming that it works for you
<stintel>
wait, no, but doesn't matter, this worked for years
<stintel>
at least 3
<stintel>
If specified, match traffic against the given ipset. The match can be inverted by prefixing the value with an exclamation mark. You can specify the direction as 'setname src' or 'setname dest'. The default if neither src nor dest are added is to assume src
<rsalvaterra>
Right.
<stintel>
but doesn't even matter
<stintel>
fw3 claims the set is missing
<stintel>
(I added src for shits and giggles no change)
<rsalvaterra>
What happens when you manually delete the ipset an restart fw3?
<rsalvaterra>
*and
<stintel>
exactly the same, same fw3 error, yet ipset exists afterward
<stintel>
I'm gonna revert to 5.4
philipp64 has quit [Quit: philipp64]
<rsalvaterra>
I wonder how I'm not seeing that issue on my machines… :/
<dwfreed>
"Note that during git rebase and git pull --rebase, ours and theirs may appear swapped; --ours gives the version from the branch the changes are rebased onto, while --theirs gives the version from the branch that holds your work that is being rebased."
<stintel>
Imma leave that tab open for tomorrow
<dwfreed>
which is why git checkout --theirs is the correct answer
<dwfreed>
as counter-intuitive as it sounds
<rsalvaterra>
dwfreed: There's probably a good reason for that, but I just took it as gospel. :)
* stintel
head explodes
<dwfreed>
it's explained in the next paragraph in the git-checkout manpage
<dwfreed>
basically, during a rebase, you become the steward of the canonical history, and you're merging some contributor's changes
<dwfreed>
so canonical history is ours, and the contributor's changes is theirs
<rsalvaterra>
Whoa… So I took my version of the 543-ath9k_entropy_from_adc.patch, refreshed the patches again… and came out completely unchanged. Surprising.
<stintel>
pffft, of course random package build breakage during bisect
<rsalvaterra>
stintel: Yeah, we had this chat about bisectibility in the packages feed a while ago… :)
<stintel>
I'm really close to doing a make clean after every build
<stintel>
because shit is constantly breaking
<stintel>
which is extremely frustrating
<mangix>
rsalvaterra: Ansuel recently broke wake/suspend for qca8k :)
<rsalvaterra>
mangix: Oh…? Was that the reason for your lan{2,4} failures?
<mangix>
nope
<mangix>
that's the multicpu dsa patch
<mangix>
which I'm done with at this point
<stintel>
bah
<stintel>
the breakage is due to things in packages feed being switched to meson
<mangix>
stintel: elaborate
<stintel>
read up
<mangix>
I just see breakage
<rsalvaterra>
mangix: stintel noticed a possible breakage in fw3 ipset handling.
<mangix>
how is that related to meson?
<stintel>
bisect was mentioned 6 times in the last 2h
<stintel>
but that's horribly broken because going back 4 months in master half of packages breaks
<mangix>
yes, I switched 44 packages to use tools/meson
* mangix
wonders why core openwrt libraries don't use pkgconfig and are not versioned
<PaulFertser>
I wonder how to find an owner of DGS-1210-10P Rev F1 to test if we can have a common dtsi with R1. But nobody's answering so far. Can't be so few people really have it?
<mangix>
rsalvaterra: what's worse is all autotools packages on the buildbots don't build currrently
<mangix>
why did cotequeiroz think it was a good idea to update libtool when it clearly breaks API
<mangix>
aparcar[m]: does your CI have host libtool?
<stintel>
great. bisecting went from major pita to impossible
<aparcar[m]>
mangix: CI should have everything
fda- has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
pmelange has quit [Quit: Leaving.]
shibboleth has joined #openwrt-devel
<stintel>
sigh
<stintel>
previous image of my VPN router was using 5.4.117 kernel. managed to build the commit that introduced that kernel version in master, yet the ipset problem persists
<stintel>
what I also noticed, is that if I add entries to the ipset in firewall.user, the first attempt fails
<stintel>
and that VPN router booted several times with that image without issues (due to hypervisor issues)