Please try the multi Link test binaries
If it still doesn't work I have to check again what is missing from LEDE PPP versus the CodeAuora PPP
https://github.com/gwlim/Openwrt_Firmware/tree/master/Mutilink-Test
WDR3600x1, PPPoE
just tried the multilink test, the same... i only tested w/o opening the box, and had a continuous ping on it
flashes ok, LAN client connects once done (ping ok) when i setup PPPoE it's also ok (ping ok), connects to the ISP and gets his config (WAN IP ...) the crazy stuff starts once i try to connect from a LAN client (the moment i try to open an Internet page), crashes and bootloops forever, seemingly random and only stays seconds so not enough time for flashing an old bin (safe at least). i remoted (fast 
) a ssh (Luci was inoperable) and did quickly a firstboot & reboot so that it restored the config to the w/o PPPoE so it was stable afterward and i could restore my previous firmware to it
i will open the box and put my UART on it and so i can grab some useful stuff (logs and so), i know just saying "not works" is not too much.
mine crashed on dhcp too, behind primary router
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
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.
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.