Folks,
Tl;Dr Does someone spotted an issue with wifi calling when HW offload is enabled?
Long:
On my Xiaomi 11t pro, when I connect to the dumb ap ( Xiaomi ax3200), wifi calling is enabled in few seconds. When I go to the BPI-R4 it takes over 5 min. I was trying firewall rules, enabling QoS, SQM, removing SFP (they require to enable flow control) - nothing helped. Someone suggest to disable offload - I tried and it established in 1min, so I turn on sw offload - same 1 min and all was good.
So I go back to hw offload - takes 5 min and it is flapping.
I can only confirm that wifi calling using dumb aps and the R4 acting as uplink with hw offload works like it should on my Samsung S23+ (and always did for which I am glad, the 4G and 5G signal is crap in my apartment). I do not have a wifi card in the R4 so can't test that part.
I occasionally lose connection to the corporate VPN on my work laptop but that has happened with every router I have used so I blame it on the other endpoint.
Does anybody have stability issues with MT7915E and RC2 (or maybe the issues started with one of the snapshots before that - haven't updated the installation for quite a couple of months)?
I've installed 1 MT7916AN (rockstable throughout all snapshots) and MT7915E (stable for most of the snapshots), and after a couple of hours the 2,4GHz SSIDs I created on the MT7915E somehow... refuses new connections?! Connected devices stay connected, but new devices cannot connect anymore.
tcpdump -vv -i br-wan dst port 500 or dst port 4500 or dst port 5060 or dst port 5061
So I check how the traffic looks like for the phone:
tcpdump -vv -i br-lan dst host 192.168.88.114
All looks normal, just when the HW offload makes the VoWiFi establish connection more harder than when just SW is enabled. I got a puzzle.
Or maybe it is a time to buy new phone?
In fairness, it would seem to me that a UDP protocol that fails with a few out of sequence datagrams is pretty much broken seeing that this can always happen with UDP.
That's also why I never bothered to investigate it myself. And, FWIW, I get up to 2gbit over a single wireguard channel from my laptop to protonvpn so it can't be that bad.
They're still valid. I'm using both patches. Note that the 'target.mk' patch is a little quick hack that brings Cortex A73 optimisation to the kernel. For application packages to benefit from it, you'll have to include the application packages in the '.config'. Unless you have critical applications, pulling them from snapshot repository still works and is hassle free.
This won't work as-is. A DISASTER happened to my BPI-R4 in the past week. So I had the chance to boot into my eMMC disk for the 2nd time and see..
Turns out the numbers of partitions of the SD card image and eMMC image are different. So the steps as-is in the quoted post won't work. However, I believe the principle holds. A set of modified procedures should work. Interested folks may invest your time and explore.
A disaster happened to my BPI-R4 in the past week that totally destroyed my R4 setup. It's just a live backup router and hadn't materially impacted me. Except that I forgot to copy its config off-device for backup. So, much of months' configuration effort is lost.
Post-mortem analysis and bisecting recent changes show the suspect may be this commit that caused consistent kernel crashes in NFT:
commit 47c75a25cdeed6fda9608d61926799dbd1b1fef3
firewall4: update to Git HEAD (2024-12-18)
I didn't see anyone else having the issue. So I believe it partially has to do with my modifications to the firewall rules. Though my changes used standard facilities & followed best practice documented in OpenWrt wiki.
Too many lessons to talk about from this disaster but I'll keep it relevant to this thread:
I suggest OpenWrt for BPI-R4 makes it clear that it's running in recovery mode. E.g. by display that info in MOTD when a user login or TTY drops to system prompt.
I suggest OpenWrt for BPI-R4 should be created to run it like OpenWrt for x86. R4 is a big system and deserves it. Perhaps too late for R4 but not the future, say, BPI-R5.
Always do you configuration backup off device i.e. store it like your family photos and source codes. Especially true if you've done non-trivial config changes.
F2FS in 2024 is better in reliability but can't compared to ext4 & co. So extra care & awareness needed when use F2FS for a writable partition.
Repeating my same work of several months is boring. This disaster gives me a chance to reconsider how to better run my BPI-R4. It's perhaps the only silver lining out of it.
Off topic, but as I suffered from this various times: write down your mods in absolute detail and save the source data/images/patches + config backups to some veracrypt (windows)/luks (Linux) containers. Thus a crash will be nasty, but you do not need to reinvent the wheel...
Same bug for me on rc3 as on rc2 - cannot connect to MT7915E-2,4GHz-SSIDs with several mobile/IoT devices.
No issues connecting to MT7916-5GHz-SSIDs though.
Does anybody have the same issues? It DID work on snapshots before, but I didn't update frequently so I can only tell that it worked at least until June 2024 snapshots.
edit: Found the issue: It has something to do with fast roaming options. Thus I deactivated 802.11r/v + DAWN for the moment.
I currently have a R4S as main router, but im busy upgrading my infrastructure to 10G. The Bpi-R4 is one of the candidates to replace the router. Few questions:
Is the SPF fully functional on the 24.10 RCs? (going to connect it to a XGS1250-12)
How is the NAT speed, close to the 10G?
How is the speed with QoS?
Wireguard I saw was >1G (Which is sufficient for my needs).
