so with main kernel its working by default,when i load hnat kernel it’s not even if i dont load hnat module( loading it not helps) @frank-w i will try tomorrow 
With mtk_eth.c from main it works,so it seems that there is something missing.
@garywang have you an idea?
Maybe we must first get gmac #2 working. Does anybody know how this can be done?
The HNAT related patches are under review (mainline kernel), so please wait.
Anything new? I still see no patches for hnat/2nd gmac. Lede-patches for 4.14 are not working (still no response on my bug-reports [github-commit,lede bugtracker,johncrispin,sean wang])
- 1.HNAT framework patch is not accepted so far.
- 2.In my opinion, 2nd GMAC is not important because 1st GMAC is TRGMII and can reach up to 2Gbps. In other words. The ideal LAN<->WAN NAT bi-direction throughput can up to 2Gbps.
Anything new for hnat?
after we got gmac#2 working i returned to hnat-branch
the only issue i currently have so far is:
WARNING: drivers/net/ethernet/mediatek/mtk_hnat/mtkhnat.o(.text+0x620): Section mismatch in reference from the function hnat_probe() to the function .init.text:hnat_init_debugfs()
The function hnat_probe() references
the function __init hnat_init_debugfs().
This is often because hnat_probe lacks a __init
annotation or the annotation of hnat_init_debugfs is wrong.
drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:236:static int hnat_probe(struct platform_device *pdev)
drivers/net/ethernet/mediatek/mtk_hnat/hnat.h:422:extern int __init hnat_init_debugfs(struct hnat_priv *h); drivers/net/ethernet/mediatek/mtk_hnat/hnat_debugfs.c:426:int __init hnat_init_debugfs(struct hnat_priv *h)
tried removing __init from both hnat_init_debugfs and adding it to hnat_probe, but this results in this:
WARNING: drivers/net/ethernet/mediatek/mtk_hnat/mtkhnat.o(.data+0x0): Section mismatch in reference from the variable hnat_driver to the function .init.text:hnat_probe()
The variable hnat_driver references
the function __init hnat_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
with * it brings many compile-errors…any idea?
currently i dropped the __init, hoping it works 
btw. @moore your picture seems wrong…we get gmacs only running after both are same mode (rgmii or trgmii). actual both running with trgmii. if we set them different, cpu_port0 have damaged traffic outgoing
currently i have not the problem, that i got no traffic through wan-port like without 2nd gmac, but i havn’t set up a NAT on wan yet.
anyone here who can test hnat in 4.14?
seems like hnat is not working so far…
#v4-routing activating
root@bpi-r2-ubuntu:~# nano /etc/sysctl.conf
root@bpi-r2-ubuntu:~# sysctl -p /etc/sysctl.conf
root@bpi-r2-ubuntu:~# wifi.sh
root@bpi-r2-ubuntu:~# ipt=/sbin/iptables
root@bpi-r2-ubuntu:~# if_wan=wan
root@bpi-r2-ubuntu:~# modprobe mtkhnat
root@bpi-r2-ubuntu:~# ${ipt} -t nat -A POSTROUTING -o ${if_wan} -j MASQUERADE
#...make some traffic over wlan
root@bpi-r2-ubuntu:~# cat /proc/interrupts|grep ethernet
215: 13618 0 0 0 MT_SYSIRQ 199 Level 1b100000.ethernet
216: 20569 0 0 0 MT_SYSIRQ 198 Level 1b100000.ethernet
@garywang have you an idea? Is there a way to look if the driver receives any packets?
i added some debug-info on init-procedure to look if that completes successfully:
root@bpi-r2-ubuntu:~# modprobe mtkhnat
root@bpi-r2-ubuntu:~# dmesg | grep -i 'HNAT'
[ 50.510736] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:252) of_node=hnat
[ 50.510771] mediatek_soc_hnat 1b100000.hnat: wan = wan
[ 50.510788] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:265) res:-559325376
[ 50.510876] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:273) host-fe_base:-505561088
[ 50.511577] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:281) err (debugfs):0
[ 50.517816] mediatek_soc_hnat 1b100000.hnat: hwnat start
[ 50.517828] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:293) err (hnat_start):0
root@bpi-r2-ubuntu:~# ${ipt} -t nat -A POSTROUTING -o ${if_wan} -j MASQUERADE
root@bpi-r2-ubuntu:~# dmesg | grep -i 'HNAT'
[ 50.510736] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:252) of_node=hnat
[ 50.510771] mediatek_soc_hnat 1b100000.hnat: wan = wan
[ 50.510788] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:265) res:-559325376
[ 50.510876] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:273) host-fe_base:-505561088
[ 50.511577] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:281) err (debugfs):0
[ 50.517816] mediatek_soc_hnat 1b100000.hnat: hwnat start
[ 50.517828] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:293) err (hnat_start):0
[ 50.517833] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:299) register reached
[ 50.723766] [HNAT] hnat_probe: (drivers/net/ethernet/mediatek/mtk_hnat/hnat.c:303) ret (hnat_register):0I am playing with mtkhnat in kernel 4.4. Hope that we can also share some common information in this thread. I only use the native dsa driver with 1 cpu port, but it is no matter to mtkhat.(I hope so.)
There is a interested item of mtkhnat in debugfs.
cat /sys/kernel/debug/hnat/all_entry
It shows the original ip/port and new ip/port translated by mtkhant. This log may show more magic information for debug.
[hant/all_entry@ debugfs ]
“https://github.com/frank-w/BPI-R2-4.14/blob/83c0e4f280a5df7526581ff3b00d9a85193caeb1/drivers/net/ethernet/mediatek/mtk_hnat/hnat_debugfs.c#L457”
[before & after information]
“https://github.com/frank-w/BPI-R2-4.14/blob/83c0e4f280a5df7526581ff3b00d9a85193caeb1/drivers/net/ethernet/mediatek/mtk_hnat/hnat_debugfs.c#L62”
1 Like
thank you for the information, i will try it when i’m back home with 4.14…
have you a output for working hnat? i guess if it is not working the table is empty.
imho 4.4 has 2 cpu-ports (eth0/eth1 for lan/wan) but no dsa (splitting lan-ports) where 1 cpu-port (imho eth1) is linked directly to wan-port and the other (eth0) is linked to all lan-ports (which are still bridged). 4.14 has dsa (all ports are accessable separately) but only 1 cpu-port (in mainline), so all Traffic goes through this 1 cpu-port.
Finally I got the time to learn how to post the code.
There is the output from cat /sys/kernel/debug/hnat/all_entry when test TCP traffic between LAN and WAN with no VLAN.
"state=BIND" means that the traffic is handled by mtkhnat where "state=UNBIND" is not.
The CPU usage becomes lower when the state of the entry changes from "state=UNBIND" to "state=BIND".
[Topology]
LAN_DEV(192.168.1.2) ----- (192.168.1.1)DUT(192.168.20.2) ----- (192.168.20.1)WAN_DEV(000000004a040b80)0x0002e|state=BIND|type=IPV4_HNAPT|192.168.1.2:60492->192.168.20.1:5000=>192.168.20.2:60492->192.168.20.1:5000|9a:a1:8c:1f:43:73=>9e:7c:af:b7:12:08|etype=0x0800|info1=0x2140789b|info2=0x63f040|vlan1=0|vlan2=0
(000000004a060a80)0x0082a|state=UNBIND|type=IPV4_HNAPT|192.168.20.1:5000->192.168.20.2:60490=>0.0.0.0:0->0.0.0.0:0|00:00:00:00:00:00=>00:00:00:00:00:00|etype=0x0000|info1=0x10000098|info2=0x0|vlan1=0|vlan2=0
(000000004a070980)0x00c26|state=BIND|type=IPV4_HNAPT|192.168.20.1:5000->192.168.20.2:60492=>192.168.20.1:5000->192.168.1.2:60492|f6:83:fe:8c:a8:6a=>62:f6:0b:4b:1a:63|etype=0x0800|info1=0x2140789b|info2=0xe3f020|vlan1=0|vlan2=0
BTW, it takes me lots of time to find out this line. I enlarge this value or iperf3 negotiation would fail. 
cr_set_field(host->ppe_base + PPE_BNDR, BIND_RATE, 0x20);
1 Like
Have you tried hnat in 4.14 or do you only link to my repo only for me to change this value?
Great feedback. On kernel 4.9 with mtkhnat, all entries in cat /sys/kernel/debug/hnat/all_entry are set to state=UNBIND|type=IPV4_HNAPT. If i understand correctly this mean it is not leveraging the hardware?
Is there a way to set it to BIND state?
as rainfall83 wrote, change following line
in hnat.c
As my testing result:
- When this setting is set to ‘1’, every LAN <–> WAN stream will be bound.
- When this setting is set to ‘0x20’, the traffic only exchanging few packets will not be bound. For example, control stream of iperf3 will not be bound. Everyone who wants above behavior can change the value.
@frank-w I refer to the patches in kernel 4.9 from graywang’s github to port hnat to kernel4.4 with 1cpu port dsa. I am interested in how does it look like in kernel 4.14 with 2cpu port dsa, so I check some points and put the reference from your github in this thread.
1 Like
Then in my 4.9 (was native 4.9.44 with garys lede patches) seems to not working as stated by xbgmsharp.this 4.9-branch contains also second gmac-patches from garys repo…
my 4.14-hnat uses same code only ported to newer iptables callbacks
Yes, state=UNBIND means it is not leveraging the hardware.
I do not know how to make an entry state=BIND manually.
I only can try to observe network stack to make sure the LAN <–> WAN stream can pass the checking in reasonable nf_hook registered by mtkhnat, and then reach this line.
[Reasonable path]
eth0 --> lanX --> xxx_pre_routing() hook --> Network stack & SW NAT --> xxx_post_routing() hook --> wan ---> eth0 or eth1, depending on dsa setting.In 4.14 (with 2nd gmac) the path imho should be this:
Client => lanx => (eth0) => nfprerouting-hook => sw/hwnat (postrouting) => (eth1) => wan/ppp => internet
reverse way (answer from internet-server):
Server => wan/ppp => (eth1) => sw/hw nat (prerouting) => postrouting => (eth0) => lanx => clientI updated the file drivers/net/ethernet/mediatek/mtk_hnat/hnat.c with
cr_set_field(host->ppe_base + PPE_BNDR, BIND_RATE, 0x20);
However now iptables is very slow and all sys entries are still set as UNBIND.
# cat /sys/kernel/debug/hnat/all_entry
(fb8c1c80)0x00072|state=UNBIND|type=IPV4_HNAPT|
Is there anything else require?