Hardware NAT For LEDE

**gwlim** · June 29, 2017, 4:42am

I have been trying to port QCA Hardware NAT over to stock LEDE.
This is from Code Aurora Repo
After some monkey patching the compile works and I got the binaries.
You can try it at my repo, targeting WDR4300

To compile select the Hardware NAT Module in Kernel Modules and the SSDK Shell in utilities
Unfortunately I got the following errors while loading the kmod
Anyone can make head and tails off it?

[ 126.429985] qca_ssdk: Unknown symbol ppp_hold_channels (err 0)
[ 126.436355] qca_ssdk: Unknown symbol ppp_release_channels (err 0)
[ 126.442761] qca_ssdk: Unknown symbol f1_phy_init (err 0)
[ 126.448378] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)
[ 126.455151] qca_ssdk: Unknown symbol ppp_is_multilink (err 0)

Thanks

**komawoyo** · January 23, 2017, 5:15pm

Not familiar with this error but just wanted to say this is awesome. I use your performance orientated builds for my WDR3600 <3

EDIT: Removed unrelevant links

**gwlim** · January 22, 2017, 2:33pm

I look at the source, it seems that their ppp driver isn't mainline, it has some special functions that QSDK Hardware NAT uses, looks like some patching is needed.

**komawoyo** · January 22, 2017, 9:33pm

ppp_hold_channels and other ppp_*** functions

github.com

paul-chambers/netgear-r7800/blob/eeac2e10190f6f45e32e4c7012c4babc351898d8/git_home/linux.git/sourcecode/drivers/net/ppp/ppp_generic.c

/*
 * Generic PPP layer for Linux.
 *
 * Copyright 1999-2002 Paul Mackerras.
 * Copyright (c) 2013-2015 The Linux Foundation. All rights reserved.
 *
 *  This program is free software; you can redistribute it and/or
 *  modify it under the terms of the GNU General Public License
 *  as published by the Free Software Foundation; either version
 *  2 of the License, or (at your option) any later version.
 *
 * The generic PPP layer handles the PPP network interfaces, the
 * /dev/ppp device, packet and VJ compression, and multilink.
 * It talks to PPP `channels' via the interface defined in
 * include/linux/ppp_channel.h.  Channels provide the basic means for
 * sending and receiving PPP frames on some kind of communications
 * channel.
 *
 * Part of the code in this driver was inspired by the old async-only
 * PPP driver, written by Michael Callahan and Al Longyear, and

This file has been truncated. show original

**lukasubo** · January 23, 2017, 2:38am

Would this work for all the hardware targeted by the ar71xx builds (such as the Archer C7)?

**gwlim** · January 23, 2017, 3:54am

It should.
The story (base on what I see) is that Qualcomm has combined all their switch driver under QCA-SSDK
The switches are
GARUDA (AR8316)
ATHENA (AR8216)
SHIVA (AR8227/AR8228/AR8229)
HORUS (AR8263)
ISIS ((AR8325/AR8327/AR8328),without HNAT, AR8327N/AR8328N with HNAT)
ISISC (??)
DESS (Should be the new IPQ ARM Processors)
And the QCA-SSDK build targets are ALL-CHIP so it should be some sort of auto detect
If your router has the switches above it should be gd

**lukasubo** · January 23, 2017, 7:10am

Thanks. It seems the Archer C7 has the AR8327.

**dissent1** · January 23, 2017, 11:07am

Seems like it should work on ipq806x boards also.
Any chance to include it in packages, not in feeds?

**gwlim** · January 23, 2017, 12:18pm

It is in package.
The script clone it in feeds then moves it into package
For IPQ there are more components like NSS-ECM etc

**gwlim** · January 23, 2017, 4:21pm

Looks good from here
[ 49.302585] ssdk_plat_init start
[ 49.306188] Register QCA PHY driver
[ 49.310468] PHY ID is 0x4dd033
[ 49.378695] qca probe f1 phy driver succeeded!
[ 49.383219] qca-ssdk module init succeeded!
I have uploaded the patch into my git repo
Will continue testing tmr

**komawoyo** · January 23, 2017, 5:18pm

Wow awesome work

Just for reference, was it the missing functions from ppp_generic.c (linked above)?

**gwlim** · January 23, 2017, 5:23pm

Yes it is from 2 files
ppp_generic.c describing the function
and ppp_channel.h containing the function headers
Feel free to clone and build, the patching has been scripted and no additional effort is required except that you have all the buildroot dependencies installed on your Linux machine.

**lukasubo** · January 24, 2017, 5:10am

Is there any chance of this making it into mainline LEDE? Or does it suffer from the same issues that were outlined in this old OpenWrt feature request, preventing it from potentially being accepted?

It's really cool that you're working on this feature, especially as the world moves towards more FTTH for gigabit WAN access.

**gwlim** · January 24, 2017, 5:39am

Nope don't think so.
The integration is very very ugly I don't think it is acceptable to devs.
Anyone wants it can make it from my git source
We still need to work on integration with LEDE firewall components

**komawoyo** · January 25, 2017, 1:27am

Edit: Removed

**stangri** · January 24, 2017, 8:19am

Does it mean that it's not going to work at all or does it mean it's not going to utilize the full capabilities of the ipq806x?

**gwlim** · January 24, 2017, 8:49am

I am really not sure.
Because if you check Code Auroa you see a lot of IPQ dependencies on other packages I did not touch
They have encryption driver etc so I do not know to what extend of dependencies does IPQ require.
MIPS is way simpler only 2 components the QCA-SSDK driver and the shell program to configure the driver kind of like swconfig in LEDE.

**gwlim** · January 24, 2017, 1:01pm

I have uploaded the SSDK Command Guide

**komawoyo** · January 24, 2017, 9:55pm

Wow, I just wanted to say that these patches makes a world of a difference in performance. I use my WNDR3700v4 with LEDE-17.01 as a repeater and the wireless performance would be quite unstable initially increasing to 25 mbps then gradually dropping on the speed test to ~ 11-15 mbps fluctuations, each test had inconsistent values.

With these patches, the wireless keeps a sustained 40 mbps download from start to finish. Upload speed was smooth too! Really great job on the patches. Thank you, I will definitely install a patched firmware for my TL-WDR3600 asap.

Just to note, I did not get to use patches #001-005 in addition, I was unable to find Hardware NAT Module in Kernel Modules and the SSDK Shell in Utilities so I may be missing out on some additional performance gains, but all is well and performance is much better than the base LEDE-17.01 on WNDR3700v4

**gwlim** · January 25, 2017, 12:36am

Kernel Modules -> Network Device -> QCA-nat-something
Utilities -> QCA-SSDK-SHELL
Follow the github README.
You don't need to patch manually
copy the whole repo into a untouch LEDE clone and run ./patch_LEDE.sh and it will autopatch.