Hardware NAT For LEDE

PPPoE as well?

sorry, right now I don't have access to it, is in a remote location and don't feel like testing a remote sysupgrade

regards

Ok I have isolated the issue to host_helper.c in qca-ssdk
It is a PPPoE code path
Apparently there is 2 code path to try the second code path does not require ppp patching
So there are 2 ways of solving this
1)Disable PPPoE Code
2)Try the second code path
Any Brave Soul with PPPoE wants to try?
To try you simply backup your existing config
Sysupgrade
If it fails do a reset then load your own config

https://github.com/gwlim/Openwrt_Firmware/tree/master/Mutilink-Test-2

Just tried, same behavior once PPPoE established. I was thinking you could setup your own PPPoE server and connect your router to it in order to check... this way you won't need us and you can see what's what.

later edit: made also a build from your git and ruled out everything related to luci and configured pppoe from uci, the same.. Well...I think will have to open the box and put that uart after all, darn.

To begin with, was interested in this because I wanted to put my USB tv tuner (+tvheadend/oscam) on my tplink3600 router, meanwhile I gave up to that thing. While I succeed (using a "normally" build, ie w/o the hnat patches) in compiling that stupid, unsupported MN88473 module for 4.4 and also the software and made everything work (unrestricted TV channels work fine) I will have to find a different way since it chokes on scrambled HD channels, simply not enough processing power (and i tried also the libdvbcsa which is supposedly faster than the tvhcsa that compiles as default in tvheadend) even when streaming an unscrambled channel it loads the processor to 30-40%, so when streaming a scrambled one it manages to do it for a few seconds, simply goes to 100% and chokes there then tvh segfaults (no wonder). Either way, this hwnat with a custom firmware like lede is interesting enough so ...

gwlim, outstanding work! The patches that you put together and all the optimizations - amazing! Thanks a lot!

I wanted to jump on the bandwagon and play with ssdk on my Link TL-WDR4300. Due to some kernel module dependencies (e.g. usb-storage, etc.) I could not use the image that you pre-built for us, since the kernel version had been switched on LEDE and official repo has old incompatible modules with your builds. So, I followed your instructions (https://github.com/gwlim/mips74k-ar71xx-lede-patch) and built locally my own image. Everything finished successfully and I've upgraded my TL-WDR4300 with the image.

Unfortunately, the image contained no traces of ssdk. So, I've started digging into what could be missing and initially thought that it was due to one of your recent changes (https://github.com/gwlim/mips74k-ar71xx-lede-patch/commit/9caf9980574beda834b220103155b89223f46fe7), but I was wrong and the build still did not compile ssdk pieces after I commented out line "sed '$d' feeds.conf.default".

When I unpacked your image, it contained the following files that not only were missing from my image, but also were not built locally (meaning that none of ssdk stuff was compiled by the build):
/etc/modules.d/30-qca-ssdk-hnat
/lib/modules/4.4.59/qca-ssdk.ko
/usr/lib/opkg/info/kmod-qca-ssdk-hnat.control
/usr/lib/opkg/info/kmod-qca-ssdk-hnat.list
/usr/lib/opkg/info/qca-ssdk-shell.control
/usr/lib/opkg/info/qca-ssdk-shell.list
/usr/sbin/ssdk_sh

Can you try building from scratch and see if everything builds fine in your environment, please? I could not figure out how ssdk was suppose to be included into the build, since it gets pulled as a feed, but then gets moved into "packages" folder. Is it supposed to be included into DEFAULT_PACKAGES in "include/target.mk" file to be noticed by the build?

Thanks!

make menuconfig
under kernel modules select qca hardware nat
under utilities select qca ssdk shell

Duh! I should've checked .config file for any ssdk available option before posting here. :-
I did not realize that TL-WDR3500 model does not have hnat, so now it makes sense why you did not include ssdk by default into the build.

Is there a way to only build the packages and install via opkg, or making the full build is the only way?
I'm not sure if building only make tools/install && make toolchain/install && make package/ssdk/qca-ssdk/compile will work

Since ssdk needs kernel modules loaded, anything that you build locally will most likely be not compatible with the official release because it uses a slightly older kernel (at the moment of writing, release 17.01.1 has kernel 4.4.61, while the latest code on 17.01 branch is already switched to 4.4.62). I'm not aware of a way to "rebrand" kernel modules for another version, but why would you risk it anyway?

edit: updated commit, forgot to add network defaults for some devices.

edit2: removed referenced to removed phy4 in d7800 dts

What is the point of making separate VLANs for each port and then bridging them by CPU?

That's the way DSA architecture works, each port is a seperate interface, so switch itself is transparent for the kernel. Bridging goes within the switch itself.

I did not look at the code yet, but it is very unlikely that if you set bridging in the LEDE /etc/config/network it will be a hardware bridging, not just a soft bridge in the kernel.

I looked at your patch and it does not have anything regarding bridging. So we get a soft bridge over separate VLANs. That makes no sense.

https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt

Hi which part of the upstream driver allows traffic offloading.
I read the whole driver but could not see the part which does the hardware offload

I haven't dig deep into the code, but it's not a hardware nat in its meaning. As I get it it's kind of cut through forwarding.
The effect and scale of it is subject to test, that's why I posted it here, I haven't seen anyone using it before.
All I can say is that my load average is mostly zero unlike before, but it's with unintensive traffic.

The main kernel part is in net/dsa.

Did you find the correct sequence of commands? Sorry, but documentation, that you have posted, does not contain any understandable examples.

When I try to apply the patch I got that error:
...
patching file include/kernel-version.mk
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file include/kernel-version.mk.rej

contents of include/kernel-version.mk.rej:
--- include/kernel-version.mk
+++ include/kernel-version.mk
@@ -3,10 +3,10 @@
LINUX_RELEASE?=1

LINUX_VERSION-3.18 = .43
-LINUX_VERSION-4.4 = .70
+LINUX_VERSION-4.4 = .70

LINUX_KERNEL_HASH-3.18.43 = 1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c
-LINUX_KERNEL_HASH-4.4.70 = c0a8b36ca9044a91eccb475cc1c467cee1f5b296f30ca06db2b91e0589072dfa
+LINUX_KERNEL_HASH-4.4.70 = c0a8b36ca9044a91eccb475cc1c467cee1f5b296f30ca06db2b91e0589072dfa

ifdef KERNEL_PATCHVER
LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))

any suggestions?

Because LEDE just bump kernel version to .71
For stuff like this I cannot be always updating the patch in realtime, so you need to realise the change and fix it yourself.
Check the Lede changelog and compare the changes