Hello Valentin,
no, it is not jet released. But releasing the Hardware does not mean, that it will work! This is not how this works ā¦
where can I buy it (for the future):
ā look on aliexpress.
ā Are you in germany? ā Look on Joom.
Best regards!
Hello Michael, Iā m pretty aware of that, and not expecting the NIC to work out of the box, or even work at all. I donāt mind fiddling weeks building drivers. But the BPI-R4 is limited without WiFi hardware , so I wonder when it will be availableā¦
Iāve already ordered the main board from the AliExpress
Simply put other wifi cards in the slots, you can simply add a ac + ax card as a temp solution. Thatās how Iām doing it: simply put the 2 wifi cards of my bpi r64 in the minipcie slots
Thats good.
I did not find any timetable (For the whole router parts ā¦ nic, case and fanās). For me it i not clear which development state all the components have. Reliability tests for consumer products lasts usually 1000 houers (heat, humitity ā¦) = 40 days. Mass production also needs time. I find no information which says anything about the actual state of the board.
Thee are other NIC chats you now?:
As ājpsollieā sayed: There are wifi 6 cards.
And I think about not buying any NIC Board 
.
The best solution is the solution that matches your needs. Why not take in the future a ānormalā wifi 7 card from mediathek? Banana PI gives us the freedom to choose.
I would like to have this freedom for the RAM 
.
I think a good solution would be using an existing AP or your actual router.
I actually thought about that, but with common mpciex cards you will get only 2r2t mimo and wifi 6e card selection is pretty limited, basically Intelās ax210 and I actually want to explore 6gHz band , because it is pretty empty ATM Another route is to explore set of be200 card with m2 to mpciex adapter , but you will get same story for channel allocation
I donāt mind to wait some time to unleash full potential of wife 7
Waiting sounds good
You have to be carefull with Intel !!! The Wifi boards do not support AP Mode.
Some in this forum fall in the trap 
.
They do if itās not 6GHz or you override the poorly implemented (and wrong) software regulatory enforcement. But there are better options indeed.
I know this trap , they always had poor software support for STA modes , so I didnāt considered Intel as a goto option. Event if it will run in STA mode there will be a lot of disabled/missing WiFi spec features
Why You even consider to use this tiny card with low power transmitter? Just wait for wifi module like others. Iām sure it will be working nice for everyone.
Did you get the M.2 or MiniPCIe card?
They even sell a bundle currently for $80 with three antennas and pigtails. Though Iām not sure if this expense is worth it, when I want to buy the Wifi NIC anyway.
I have 4 MiniPCIe MT7916 that I bought from a ālocalā (european) retailer which should come with the small heatsink (one was delivered with the larger one sadly) but no antennas (which is fine as I use ufl pcb/flex antennas as I donāt have a case right now). The card alone is reasonable for $40, as for the bundle I cannot speak as I donāt have it. I am also looking forward to the official WiFi 7 NIC but honestly I bought these cards for my R3s. Sadly the setup in the M.2 m-key to miniPCIe was not even close to fitting in the case so I tossed them in a box.
As I said I tried the AX210 that was discussed here as client and it worked but had issues with the BE200. The latter work fine in a Raspberry Pi 5 (only tested as client) but did not even shown with lspci ā at least in my available m.2 to MiniPCIe converters (might by me though). I have to point out that I also had issues with the BE200 in several Atom based SBCs as well with these adapters ā these systems wont even POST afterwards so BE200 is certainly a temperamental card. Either way LAR (location-aware regulatory) is very much annoying to deal with so I would agree with what was said here: even with tildearrowās workaround itās not gonna be pretty.
Support for the BPI-R4 was merged into vanilla OpenWrt main just minutes ago: mediatek: switch to Linux 6.1 and add BananaPi BPi-R4 by dangowrt Ā· Pull Request #14140 Ā· openwrt/openwrt Ā· GitHub.
This means people will now be able to use official OpenWrt snapshots, once those are built and available (today or tomorrow). Itās much newer than Banana Piās fork, which is based on 21.02. Thanks, @dangowrt.
However, there are still a few problems which will have to be addressed before vanilla OpenWrt is ready for production on the BPi-R4:
hardware flow-offloading if using all 4 GiB of RA
right now it only works with mem=2048M appended to kernel cmdline)
pcie@0x11280000 doesnāt work (probably missing clock)
Ethernet driver still misses RSS and LRO for better RX-to-CPU performance (eg. when running iperf3) by aggregating RX packets
no driver for TOPS yet (ie. no hardware tunnel encap/decap offloading)
no driver for EIP-197 yet (no IPSec, TLS or DTLS in hardware, all work has to be done by CPU)
only one out of three PPE is being used
To give the things which already work more testing it makes more sense to continue development on the main branch (which apart from providing us with downloadable binaries also reduces my workload of constantly doing git rebase origin/main on that large series)
I thought patch from elad already fixed this. I rebased current rss/lro state on this as i thought it is a depency
Thanks for that information. And, of course, for those unfamiliar with OpenWrt snapshots in general, keep in mind that there are trade-offs compared to stable release versions.
I think this GREAT work! Thanks to all the devs!
hardware flow-offloading if using all 4 GiB of RA
right now it only works with mem=2048M appended to kernel cmdline)
I thought that was fixed as well. Did you discover something new?
It looks like itās not working on current master without 2G limitation (it was working at some point). I also tried to apply your patch for 3 PPE but it seems to break offloading.
It was pretending. It wasnāt actually offloading because of flow-offloading with nftables being broken in general. That was fixed now, restoring flow-offloading capabilities on all SoC starting from MT7621: [net] netfilter: nf_tables: fix bidirectional offload regression - Patchwork
However, now that the flow offloading entries actually match both directions of traffic, for some not yet clear reason this now results in blocked/dropped packets if using 4 GiB of RAM.
Maybe a dumb question, but how is the 3-pin Fan Header supposed to work with pwm? Iāve never seen a 3 pin fan that supports pwm