DIR-860L hardware nat

Hi, I've been trying to include the hw_nat driver and I managed to compile it. I can see in the kernel log: Ralink HW NAT Module Enabled

I've also tried to add some of the patches to actually integrate it but I'm not experienced in that field.
If anyone wants to help the repo is here.

MT7621 kernel with nat: https://github.com/mqmaker/linux, https://github.com/mqmaker/witi-openwrt

To enable HW-NAT, we need to use the Ralnk RaEth driver as well right??

I don't know about that. Why is it needed?

Because see here at the bottom of the Kconfig, it's integrated with the driver.

I don't think it's required as I don't see any refferences from the hw_nat module.

I will give it a try :sunglasses:

It's definitively not production ready. You should be prepared to do recovery just in case.

I played around with it. We need to install the Ralink Ethernet driver too:

[  461.875819] hw_nat: Unknown symbol ra_sw_nat_hook_tx (err 0)
[  461.881602] hw_nat: Unknown symbol get_foe_table (err 0)
[  461.886922] hw_nat: Unknown symbol ra_sw_nat_hook_ec (err 0)
[  461.892627] hw_nat: Unknown symbol ra_sw_nat_hook_rs (err 0)
[  461.898285] hw_nat: Unknown symbol ra_sw_nat_hook_rx (err 0)

Those symbols are exported by "raether.c" in the raeth driver.

./raether.c:int (*ra_sw_nat_hook_rx)(struct sk_buff *skb) = NULL;
./raether.c:int (*ra_sw_nat_hook_tx)(struct sk_buff *skb, int gmac_no) = NULL;
./raether.c:int (*ra_sw_nat_hook_rs)(struct net_device *dev, int hold) = NULL;
./raether.c:int (*ra_sw_nat_hook_ec)(int engine_init) = NULL;
./raether.c:EXPORT_SYMBOL(ra_sw_nat_hook_rx);
./raether.c:EXPORT_SYMBOL(ra_sw_nat_hook_tx);
./raether.c:EXPORT_SYMBOL(ra_sw_nat_hook_rs);
./raether.c:EXPORT_SYMBOL(ra_sw_nat_hook_ec);

Let me see if I can get the whole ralink ethernet driver to compile on a 4.9 kernel. The only advantage sofar I could see is that it integrates with the ralink proprietary wifi driver as well and we might get the HW-QOS to work. The problem with both HW-NAT and HW-QOS is that it doesn't work together with anything like SQM. (besides that we never can get Lede to officially support these drivers)

I was trying to modify the current driver to work with the hw-nat module but it might be a better idea to port raether.

I did not want to imply that your effort was not good. If we can get it to work together with the open source driver, it will actually be better. I didn't go over all your patches yet but I noticed you are trying to put those hooks into some other Ethernet drivers.

If you manage the get it to work with the open source Ethernet drivers, people use this proprietary part as an add on module (like we can now with the fast path modules). Swapping the Ethernet driver on a running router seems a bit to complicated for most users I would think (if possible at all).

Does performance improve?

I think I managed to get the Ralink Ethernet driver to work. (it is compiling as a separate module without error). I had to remove the mtk/ethernet and the patches for that; clean the tree and now its compiling from a clean tree, so it might take a while.

As soon as it works I will do some testing and report back.

But @gwlim, I think your Fast Path project has more potential and might make it to full support on LEDE, which will benefit a lot of other devices as well.

I got it to compile as well but I could not ping the device. I need to put some UART wires.

Getting the open source Ethernet/switch driver doesn't seem like a very easy job. Adding the Raeth driver on top obviously generates a conflict. Just removing the patch and the files from the target is not enough. Trying to remove everything Ethernet from the kernel-menuconfig now.

Maybe my problem is that I'm trying to build it as a loadable module.

From what I can see from his staging tree, @blogic is already doing work on implementing hardware NAT. You can view the work he has already done here: https://git.lede-project.org/?p=lede/blogic/staging.git;a=shortlog;h=refs/heads/mt7530-dsa-performance

Maybe it is useful for you guys as well :slight_smile:

Very interesting. Looks like the new/patch code is much smaller then the Ralink source I was using. :sunglasses:

AAHH!! this is driving me crazy: as you can see, raeth loads on boot without any error. But it doesnt seem to bring up the switch or any eth(x) device. For sure there is (was) a reason why other (probably more clever people) stopped using this driver long time ago :angry:

[    2.684380] NET: Registered protocol family 10
[    2.690293] NET: Registered protocol family 17
[    2.694777] 8021q: 802.1Q VLAN Support v1.8
[    2.701198] hctosys: unable to open rtc device (rtc0)
[    2.711611] VFS: Mounted root (squashfs filesystem) readonly on device 31:5.
[    2.719142] Freeing unused kernel memory: 196K (804ef000 - 80520000)
[    2.725476] This architecture does not have kernel memory protection.
[    3.142075] random: crng init done
[    3.351596] init: Console is alive
[    3.797187] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[    3.854407] MTK MSDC device init.
[    3.916907] mtk-sd: MediaTek MT6575 MSDC Driver
[    3.924537] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[    3.947076] init: - preinit -
[    6.653734] jffs2: notice: (382) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[    6.670795] mount_root: switching to jffs2 overlay
[    6.693339] urandom-seed: Seeding with /etc/urandom.seed
[    6.852390] procd: - early -
[    7.527741] procd: - ubus -
[    7.659606] procd: - init -
[    7.848391] kmodloader: loading kernel modules from /etc/modules.d/*
[    7.858248] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    7.873056] Ralink APSoC Ethernet Driver v3.2.4 (raeth)
[    7.878349] raeth: PDMA RX ring 512, QDMA TX pool 1024. Max packet size 1536
[    7.885370] raeth: NAPI support, weight 32
[    7.934366] Loading modules backported from Linux version wt-2017-01-31-0-ge882dff19e7f
[    7.942464] Backport generated by backports.git backports-20160324-13-g24da7d3c
[    7.952977] ip_tables: (C) 2000-2006 Netfilter Core Team
[    7.961257] lib80211: common routines for IEEE802.11 drivers
[    7.966995] lib80211_crypt: registered algorithm 'NULL'
[    7.967758] lib80211_crypt: registered algorithm 'CCMP'
[    7.968618] lib80211_crypt: registered algorithm 'TKIP'
[    7.969393] lib80211_crypt: registered algorithm 'WEP'
[    7.973741] nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
[    8.009117] xt_time: kernel timezone is -0000
[    8.017636] kmodloader: done loading kernel modules from /etc/modules.d/*

I got the same situation. I think the driver is not registering somehow (does not have any calls to MODULE_DEVICE_TABLE or platform_driver_register).

Slowly slowly I'm getting to be an expert, but...

Interrupt assignments when loading as a module, or when build into the kernel. Why would that make a difference?? Patching to a different irq will get the driver to bring up eth2. But nothing on the physical port. Looks like the switch doesn't get configured. (It gets turn off during loading of this driver, I might bypass that code to see what happens if I let it remain configured from uboot)

Based on log output from other models posted on the internet, it seems like the only way to bring up the switch, is by using the proprietary Switch app. I'm trying to compile that now (missing references of course).

I think we should wait for or try to use the patches mention above to get hardware Nat working. I don't think that the performance will be better then the fast path patches, but I am hoping it will offload the CPU further so it has more time for other stuff.

On the other hand, I will try a little further, cause these drivers interact with each other. And they interact with the proprietary wifi drivers too. I have those working for the MT7612 and 7603. The 7602 should work too, but could test that yet. Next on my list is the 7628 and the not yet supported as open driver: the mt7610, for another little toy I bought.

@adrian_dsl any progess??

Porting RAETH seems to be more trouble then I expected.