Thanks this looks like we need to know how flowcontrol in nftables need to be enabled…maybe nftables tools are need to patched too. Can you export nftables to file (maybe nftables-save) so we see the command to apply flowtables rule? List does not show it
It crashes too quick that I cannot save it all… maybe I should omit “treat oops as panic” option.
but I managed to get this:
iptables -A FORWARD -m comment --comment "!fw3: Traffic offloading" -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD --hw
Don’t know if nft or xt userspace tools (nft, iptables command) need to be patched, but seems that xt_FLOWOFFLOAD and nft_flow_offload kmod must be loaded.
So these packets are put in separate chain “flowoffload” with a hw flag…it will be interesting what happens in this chain…have you serial console working? Then you could remove rj45 cables and look on it,maybe there is no crash because no traffic on lan/ports. If serial not working you could try removing only wan,because i guess offloading only happens only if nat is activated on wan.
I think we ahould create new topic for it
Sure, we’d better discuss in standalone thread only about this hwnat issue
could you summarize it? as i don’t see the issue i cannot create opening-post…just trace you’ve got in openwrt, bug-report and iptables/nftables setting…
We’re going to have a whole new HWNAT subsystem in mainline kernel. MTK will be the first vendor to adapt it.
1 Like
Will this work for IPV6 flows as well? Currently in openwrt, it can do full gigabit at 0% CPU load, but only on IPV4.
That chain is processed by xt_OFFLOAD, in this patch: https://github.com/openwrt/openwrt/blob/master/target/linux/generic/hack-5.4/650-netfilter-add-xt_OFFLOAD-target.patch
Will mt7623 also supported too? Can this also be used with “legacy” iptables?
work for all hwnat platforms.
I’ve updated my branch with 5.10 support.
You can enable it from: menuconfig -> Global build settings -> use the testing kernel version.
Hi guys. I have build image for R64 with kernel 5.10 https://cloud.mail.ru/public/cq89/AVqxejYqM. During building I have got one issue. Midnight Commander can’t compile.
1 Like
You can try to enable ext4 journaling (CONFIG_TARGET_EXT4_JOURNAL), it should help in cases of power loss.
Support for BananaPi BPi-R64
OpenWrt UBI installer image generator
is there a mainline-series to add hw-nat?
in openwrt it is pending, and i do not see the previous selection to mt7622 (and 7621/7629) only
Hi, I want to tell about my experience with new firmware update. Fist you need flash openwrt-mediatek-mt7622-bananapi_bpi-r64-boot-sdcard.img file to SD and load. After that you see new u-boot:
Recovery system this openwrt-mediatek-mt7622-bananapi_bpi-r64-initramfs-recovery.itb, production system this openwrt-mediatek-mt7622-bananapi_bpi-r64-squashfs-sysupgrade.itb.
I have load openwrt-mediatek-mt7622-bananapi_bpi-r64-squashfs-sysupgrade this is status screen:
.
root@OpenWrt:/# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 25.8M 25.8M 0 100% /rom
tmpfs 496.7M 3.0M 493.8M 1% /tmp
tmpfs 496.7M 504.0K 496.2M 0% /tmp/root
overlayfs:/tmp/root 496.7M 504.0K 496.2M 0% /
tmpfs 512.0K 0 512.0K 0% /dev
But I have one big trouble. System can’t save settings after reboot (I use sysupgrade image). And other trouble, serial console does not react to keyboard (you must reboot some times and then it start react, I don’t understant how It work)
There has been a problem with the new way we deal with mmc/block storage and GPT partitions which lead to overlay being reinitialized on every boot. This is fixed in more recent builds after
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ec76cbc521e182d04bc07339e3c7b5a7a8f15a5b
If you are running an image where you still encounter that bug, you can fix it in the meantime by doing
ln -s 2 /overlay/.fs_state
I’ve also encountered the slightly weird behavior of the serial console which makes navigating the bootmenu more tricky than on other MT7622 boards I’ve been dealing with. Probably there is still something wrong/missing in DTS or pinctrl driver in U-Boot – the faulty red LED (always on despite GPIO88 being wired up) is an other indicator of that. The OpenWrt build of U-Boot is U-Boot 2020.10 with MediaTek’s patches on top plus adding defconfigs and environments for boards. For the BPi-R64 I’m using the dts contained in the U-Boot repository and just add LEDs and buttons to it (so that factory reset of the environment works by holding the button during power-on). For Linux it’s similar. So it’d be interesting to know if other people also encounter this when running recent U-Boot and Kernel, and if not, are they using the DTS from those upstream sources?
Other than that U-Boot works fine, I’ve just have it run 4 passes of Memtest86 9.0 EFI 
And everything needed for eMMC installation is now already integrated on the SD Card image to make it easier.
I’ve also made an OpenWrt wiki page:
Feel free to edit/complete stuff there.
Remaining issues are:
- the red LED
- serial console weirdness
- no way to load mt7622 wifi EEPROM from mmc (mt76 driver needs to be extended for that, ideally we put mt7622 wifi eeprom and maybe MAC addresses in the unused boot1 partition of the eMMC)
- add SPI-NAND to DTS
- boot from SPI-NAND (are bootselect pins exposed for that?)
Regarding the RED led, check my comment here from MT7622 programming manual: Official OpenWrt Support for BananaPi BPi-R64 & what is missing
I think GPIO88 pin needs to be told do do GPIO and not I2C1_SDA
Can you describe this a bit more? I have same behaviour like on r2 and no üroblems in bootmenu/uboot. Do you use a modified or upstream uboot? Maybe compare config with my one