Modify

Opened 6 years ago

Closed 2 years ago

Last modified 21 months ago

#11779 closed enhancement (invalid)

WDR4300 - hardware nat feature

Reported by: jozsig2ATg-mailDOTcom Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: kernel Version: Trunk
Keywords: wdr4300 ar8327n Cc:

Description

TP-Link has released the source code of it's WDR4300 router: http://www.tp-link.com/resources/gpl/GPL_2.6.31.tar.gz

The router has the AR8327N switch with hardware nat.

Booting Atheros AR934x
Linux version 2.6.31--LSDK-9.2.0_U6.616 (root@localhost.localdomain) (gcc version 4.3.3 (GCC) ) #1 Tue Mar 6 20:40:37 PST 2012
Ram size passed from bootloader =128M
(...)
TP_RULE_NAT:enable hardware nat
INFO13AB: Bind to br0
TP_RULE_SWITCH_WAN_TYPE

(from the original firmware)

Any developer up to the task of porting the hardware nat (hwaccel) feature? According to my testing it about doubles the wan-lan/lan-wan throughput.

Attachments (1)

Bob Foster1.gif (1001 bytes) - added by slavon8 3 years ago.
http://hpac.com

Download all attachments as: .zip

Change History (153)

comment:1 Changed 6 years ago by nbd

  • Resolution set to wontfix
  • Status changed from new to closed

here's why it's most likely not going to happen:

  • the source of the hw nat implementation is not included in the tarball
  • it requires some *extremely* nasty hacks in the netfilter source code

Please provide some numbers of WAN routing throughput in the original firmware with and without hardware NAT, and then also the throughput you get with OpenWrt in a similar configuration.

comment:2 Changed 6 years ago by jozsig2ATg-mailDOTcom

  • Resolution wontfix deleted
  • Status changed from closed to reopened

The one thing I didn't test was the original firmware+hw nat off. Aside from that (tested with iperf + windows network shares):

Openwrt (AVG / MAX) /basic firewall+contrack, everything unnecessary was stopped/

WAN-LAN: ~340 / 360

LAN-WAN: ~410 / 425

Simultaneous ~350 / 380

Original+hwnat (AVG / MAX) /spi firewall on)/

WAN-LAN: ~690 / 795

LAN-WAN: ~720 / 810

Simultaneous: ~1050 / 1200

These results are very similar to what the DIR-827/857 archieved on S.N.B. (which shouldn't be a surprise considering they have the same NAT-offloading switch) and what alphasparc reported on the wdr4310 thread:

(...)Also during testing the NATing Performance took a real beating.
Original firmware was able to almost hit gigabit routing speeds but OpenWRT only managed 30% of Gigabit speeds.
I am quite sure it is due to the missing hardware NATing in OpenWRT, anyway to fix it? 

comment:3 Changed 6 years ago by nbd

  • Resolution set to wontfix
  • Status changed from reopened to closed

comment:4 Changed 5 years ago by openwrt@…

It seems that this open source driver contains HNAT code, but I can't tell if it's complete enough to make a working implementation for OpenWrt out of it.

http://gpl.back2roots.org/source/fritzbox/7270_5.05/GPL-release_kernel/linux/drivers/net/ag7240/

AR8327N HNAT feature mentioned in: http://gpl.back2roots.org/source/fritzbox/7270_5.05/GPL-release_kernel/linux/drivers/net/ag7240/phys/athrs17_phy.c

comment:5 Changed 5 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:6 Changed 5 years ago by nbd

  • Resolution set to wontfix
  • Status changed from reopened to closed

It doesn't change the fact that the way this is implemented is completely messed up and requires lot of hacks all over the network stack. Until we find a clean way to implement this, I won't bother porting any of the code. => wontfix.

comment:7 Changed 5 years ago by openwrt@…

Okay, thanks for the clarification.

comment:8 follow-up: Changed 5 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Maybe we'll try to think on "clean" solution? :)
I think, many people would be glad to get NAT speedup functionality back, while using oWRT.

comment:9 in reply to: ↑ 8 ; follow-up: Changed 5 years ago by starix <mr.starix@…>

Replying to anonymous:

I think, many people would be glad to get NAT speedup functionality back, while using oWRT.

Do you have Gigabit Internet canal from your provider???

comment:10 Changed 5 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

I think mayn developers would be glad to not constantly fight with reopened tickets that add absolutely zero valuable input besides "I want", "please do" or "work on this" requests.

comment:11 Changed 5 years ago by anonymous

I think many users would like developers to do what they want

comment:12 follow-up: Changed 5 years ago by db90h

I am glad this ticket was submitted, as I was just now analyzing this. I am going to work on providing this patch, even if it isn't accepted by OpenWrt (I'm sure it won't be). I haven't checked it out closely yet, but regardless of how well structured the patch is, it clearly works well, and thus is something people will use.

If you are interested in this patch, email ekqathhgopzd@… .

(general)
Seeing the comments here, end users should remember that OpenWrt is really not an end user firmware. It is more a platform from which end user firmwares can be created. You should think of things in that context.

comment:13 Changed 5 years ago by anonymous

Hi db90h,

How is your progress on the Hardware NAT patch?

I think an option for Hardware NAT on the new powerfull routers will be a welcome feature for OpenWRT users owning a router with support for Hardware NAT. It clearly boosts performance, reduces latency, improves throughput and recuces CPU load.

comment:14 Changed 5 years ago by anonymous

I own a TL-WDR4900 router from TP-LINK, and I would really welcome the Hardware NAT feature on this device on OpenWRT.

comment:15 Changed 5 years ago by vincenzo.romano@…

Just comments.

OpenWRT is a "best effort" project done by clearly valuable developers in their spare time. Any expectation on "time to delivery" and "feature list" should be seen under this very light.

OpenWRT is not meant just to drive <=50Mbps internet links. So, the more effective the firmware, the better the product. On the other hand I would say that if you need gigabit routing (usually in an "enterprise grade network"), the the WDR4300/WDR4900 it's not the right product.

There's no hardware NAT in any OpenWRT platform (so far). Adding it requires a fairly large amount of work in order to accommodate it along with all other netfilter and bridging stuff.

So I'd say, let's wait! Or join the development team.

comment:16 Changed 5 years ago by svanders38@…

Interestingly the HW NAT feature on the TP-Link WDR4300 appears to cause stability issues

http://forum.tp-link.com/showthread.php?1731-TL-WDR4300-crashes-after-about-24-hours

comment:17 in reply to: ↑ 12 Changed 5 years ago by chrisrenzhen@…

Replying to db90h:

I am glad this ticket was submitted, as I was just now analyzing this. I am going to work on providing this patch, even if it isn't accepted by OpenWrt (I'm sure it won't be). I haven't checked it out closely yet, but regardless of how well structured the patch is, it clearly works well, and thus is something people will use.

If you are interested in this patch, email ekqathhgopzd@… .

(general)
Seeing the comments here, end users should remember that OpenWrt is really not an end user firmware. It is more a platform from which end user firmwares can be created. You should think of things in that context.

you can try to go to gargoyle ,they may accept this feature

comment:18 Changed 5 years ago by caterpillar86@…

I would donate a certain amount of money if someone will start working onto hwnat chip ;)

comment:19 Changed 5 years ago by alphasparc@…

I am not sure if this helps but I notice HNAT Code for the AR8327N Switch Driver here
http://gpl.back2roots.org/source/fritzbox/7270_5.05/GPL-release_kernel/linux/drivers/net/ag7240/phys/athrs17_phy.c
I am not that good to be able to read and understand the driver but I hope this can help.

comment:21 in reply to: ↑ 20 Changed 5 years ago by anonymous

Replying to alphasparc@…:

Hardware DataSheet available here
http://downloads.codico.com/misc/Comsat/AR8327_DS_100.pdf

Parent folder also contains a switch SDK (with a command line switch configuration utility) and other interesting documents and some source code.

Using a shell from SSDK and a conntrack command from conntrack-tools, a very basic hardware NAT support could be implemented in userspace as a bash script (create an entry in hardware NAT for each entry in Linux NAT). At least hardware port forwarding should be easy to implement.

I'm new to OpenWRT and would like to know if other AR8327 featrues, like port mirroring, QoS or rate limiting are available in OpenWRT.

comment:22 in reply to: ↑ 20 Changed 4 years ago by romulo@…

Replying to alphasparc@…:

Hardware DataSheet available here
http://downloads.codico.com/misc/Comsat/AR8327_DS_100.pdf

That folder has been removed. Can you send me its contents?
romulo at susanayunai dot info

comment:23 Changed 4 years ago by anonymous

comment:24 in reply to: ↑ 9 Changed 4 years ago by anonymous

Replying to starix <mr.starix@…>:

Replying to anonymous:

I think, many people would be glad to get NAT speedup functionality back, while using oWRT.

Do you have Gigabit Internet canal from your provider???

honestly speaking yes,I have wired 1 gigabit ethernet connection, 3 IPs, for $19/mo, Kharkov Ukraine so HW NAT would be hihgly usefull

comment:25 Changed 4 years ago by anonymous

It seems like no nasty hacks are required - just a trick to add/remove records in switch NAT table according to adding/removing conntrack items into iptables...

comment:26 Changed 4 years ago by caterpillar86@…

@#25
In what part of code did you find out that?

comment:27 Changed 4 years ago by anonymous

It looks like the functions are defined here:

http://gpl.back2roots.org/source/fritzbox/7270_5.05/GPL-release_kernel/linux/drivers/net/ag7240/include/athrs_hw_accels.h

It appears at first glance that there's a support for HW NAT and ACLs, although there's only 96 entries. Just as a general question, are there any current implementations of hw nat/acls around (not just openwrt)? It certainly seems easier and perhaps more logical to have a separate tool to manage the hw accelerated functions of a given switch rather than map the functions to netfilter, unless there's an existing method to do so, I've never looked at the nf code.

comment:28 Changed 4 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:29 Changed 4 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

comment:30 Changed 4 years ago by caterpillar86@…

I think we have to say farewell to this feature

comment:31 Changed 4 years ago by anonymous

Too bad .. romania's RDS&RCS ISP has 1gbit PPPoE for its users .. wndr3700 can barely get at 300 .. :|

comment:32 Changed 4 years ago by anonymous

It can be possible... Please somebody add the hardware nat support on openwrt... I miss the openwrt firmware, i dont like the stock firmware...

comment:33 Changed 4 years ago by alLittleBitAnonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Will anyone please work on this? Would be really perfect to get AR8327N working at its full capabilities....

comment:34 Changed 4 years ago by nbd

  • Resolution set to not_a_bug
  • Status changed from reopened to closed

Maybe somebody will find the time to work on it someday, maybe not. Reopening useless feature request tickets will not make any difference at all (aside from wasting people's time), so please stop it.

comment:35 Changed 4 years ago by anonymous

guys, only a few countries have gigabit internet connection. too bad that romanian programmers aren't involved in openwrt. hopefully, maybe some from the first ten countries listed here will feel the need. the others do not care, they have low speeds.

http://www.netindex.com/download/allcountries/

comment:36 Changed 4 years ago by anonymous

  • Resolution not_a_bug deleted
  • Status changed from closed to reopened

comment:37 Changed 4 years ago by nbd

  • Resolution set to not_a_bug
  • Status changed from reopened to closed

comment:38 Changed 4 years ago by anonymous

  • Resolution not_a_bug deleted
  • Status changed from closed to reopened

comment:39 Changed 4 years ago by anonymous

This is why China is wining :))
No competition :) no determination :) we want cars, villas, holydays, blowing jobs :) big sallaries, free time

comment:40 Changed 4 years ago by nbd

  • Resolution set to not_a_bug
  • Status changed from reopened to closed

comment:41 Changed 4 years ago by anonymous

To that guy who posted that Youtube link:
Why don't you implement it yourself and then post a patch here?

comment:42 Changed 4 years ago by anonymous

  • Resolution not_a_bug deleted
  • Status changed from closed to reopened

I assume that when this feature will be available in OpenWRT will be available for all models ...

comment:43 Changed 4 years ago by nbd

  • Resolution set to not_a_bug
  • Status changed from reopened to closed

comment:44 Changed 4 years ago by nbd

Guys, repeatedly reopening this ticket is just stupid for reasons that I've already explained above. Please stop it.

comment:45 follow-up: Changed 4 years ago by anonymous

The next person that opens this ticket confirms that he has pea brain and no manhood organ.

comment:46 Changed 4 years ago by anonymous

  1. Keep anonymous users from bein able to change ticket status.
  2. Once it's clear that's a joke, suspend those accounts.
  3. God bless you, OpenWRT.

comment:47 in reply to: ↑ 45 Changed 4 years ago by anonymous

Replying to anonymous:

The next person that opens this ticket confirms that he has pea brain and no manhood organ.

Let's have it opened by a "she" than.

comment:48 Changed 4 years ago by poweruser@…

happy new year, openwrt.
are you going to enable hardware nat on wdr4300 on the next version or we're all going to just revert to stock firmware so we can benefit +300mbps access + a ton of stability tradeoffs?
cheers,
/shark.

comment:49 Changed 4 years ago by anonymous

  • Resolution not_a_bug deleted
  • Status changed from closed to reopened

comment:50 Changed 4 years ago by olmari

Can't you f*king read? Do not reopen this unless you have like a patch to make it happend or something...

comment:51 Changed 4 years ago by caterpillar86@…

What about donating money for implementing this feature? How much should we collect? We could open a kickstarter topic

comment:52 Changed 4 years ago by olmari

Well... we would need a programmer knowing this stuff really, that would help more than money :) So far whole hardware NATting seems like black hole... only some mysterious propietary developer seems to know what is involved... :(

comment:53 Changed 4 years ago by anonymous

Hardware nat will not come :(
Available source code is not complete it´s missing ~75% importened stuff

it only good for make custom iptables modules with hw nat usable nothing more.

comment:54 Changed 4 years ago by caterpillar86@…

Instead of keep reopening tickets and asking about "we" and "you" and "openwrt", start saying things like "I will" and do the shit that you want. If you don't know or can't do it, shut the fuck up and go back to stock firmware. WTF man.

comment:55 Changed 4 years ago by caterpillar86@…

I did not reopen anything, so calm down

comment:56 Changed 4 years ago by umrzyk

I'm just posting on this legendary feature request, carry on.

comment:57 Changed 4 years ago by anonymous

guys we can do some crowdfunding here if you can implement this
just post an price you want to fix this and stop the curses at all

comment:58 Changed 4 years ago by nbd

  • Resolution set to wontfix
  • Status changed from reopened to closed

comment:59 Changed 4 years ago by anonymous

Hi, I'm not reopening, not complaining, not whining, just please think about it. Cheap wr1043nd v2 has hw nat feature too now, wr1043 v1 was very popular between openwrt users, v2 will be that popular soon too. Gigabit connections are available through the EU, mainly in eastern europe, and for a few bucks, so why not use it. If I'd know how to do it myself, I'd do it.

comment:60 Changed 4 years ago by anonymous

until atheros do the right thing and properly release the source codes and have them implemented in linux kernel tree, i don't think we'll see the hardware nat supported in openwrt.

and properly supporting open source (tm) isn't exactly a high priority for the wireless makers. cause otherwise you'd see stable and reliable open sourced drivers for all those 11ac chips already.

my guess is that they've got some pretty incompetent coders, and are afraid if they release the source, people will find out how buggy it's, with all sorts of exploits available for nsa and the likes to "use". or, they're just resource-strapped... or, both.

it's similar to the graphic chips, in particular, nvidia, of whom mr. linus gave a middle finger, has terrible support for linux. some argue that it's because of IP issues, but i don't buy it. they're either too lazy or too incompetent to find a solution.

comment:61 follow-up: Changed 4 years ago by nobody

Well, we *are* seeing stable and reliable open source drivers for 802.11ac chips, from Qualcomm/Atheros. See ath10k. Yes, the VERY SAME qualcomm/atheros as who makes the hardware this thread is about.

As far as upstream providing source for this, https://lists.openwrt.org/pipermail/openwrt-devel/2014-April/025098.html

That appears to be an upstream offer to push code directly HERE, and implies that they already HAVE the code available in their upstream (CAF).

comment:62 in reply to: ↑ 61 Changed 4 years ago by anonymous

Replying to nobody:

Well, we *are* seeing stable and reliable open source drivers for 802.11ac chips, from Qualcomm/Atheros. See ath10k. Yes, the VERY SAME qualcomm/atheros as who makes the hardware this thread is about.

As far as upstream providing source for this, https://lists.openwrt.org/pipermail/openwrt-devel/2014-April/025098.html

That appears to be an upstream offer to push code directly HERE, and implies that they already HAVE the code available in their upstream (CAF).

It is not clear to me how all this relates to the hardware NAT, anyway.

comment:63 Changed 4 years ago by anonymous

This is my first time posting in WRT, at the first, sorry for my sucks English. I'm from china. Recently, i learning AR8327N/AR8328N function of HNAT, but i can't work it out. so, i would like to discuss with you. I will upload about AR8327N source SSDK, which contains the HNAT function source code. I downloaded from the internet.I'm sorry, i must climb over the wall to visit foreign websites.The speed is very slow, i can't upload the source code, so , i provide a mailbox of china , you can find the source code and download .
mail website: www.126.com
username: openwrt_hnat@…
passoword: openwrt

thanks.

comment:64 Changed 4 years ago by anonymous

hello, just another vote for hardware NAT acceleration!
some of you don't give a damn about this because in your countries you still have slow WAN speeds. well, in east-european countries REAL 1Gbps is at every corner and millions and millions of people have access to this and the numbed is rapidly growing as this became available only in the last months.
don't ignore this, it is rapidly expanding, if OpenWrt doesn't cope with this in a few months it will become a serious issue.

comment:65 Changed 4 years ago by Caterpillar

#comment 64
You are right, then start looking for good software developers. In Eastern Europe there are a lot

comment:66 Changed 4 years ago by nbd

Guys, "votes" are meaningless here. The OpenWrt project does not have enough people to take care of all the things that users want. The only thing that will help to fix this is more people writing software and sending patches - without that, further discussion on this is redundant and useless.

comment:67 in reply to: ↑ description Changed 4 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to jozsig2ATg-mailDOTcom:

TP-Link has released the source code of it's WDR4300 router: http://www.tp-link.com/resources/gpl/GPL_2.6.31.tar.gz

The router has the AR8327N switch with hardware nat.

Booting Atheros AR934x
Linux version 2.6.31--LSDK-9.2.0_U6.616 (root@localhost.localdomain) (gcc version 4.3.3 (GCC) ) #1 Tue Mar 6 20:40:37 PST 2012
Ram size passed from bootloader =128M
(...)
TP_RULE_NAT:enable hardware nat
INFO13AB: Bind to br0
TP_RULE_SWITCH_WAN_TYPE

(from the original firmware)

Any developer up to the task of porting the hardware nat (hwaccel) feature? According to my testing it about doubles the wan-lan/lan-wan throughput.

comment:68 Changed 4 years ago by anonymous

If the code is in the sdk y not use it?

comment:69 Changed 4 years ago by nbd

  • Resolution set to wontfix
  • Status changed from reopened to closed

the relevant pieces are not in that GPL code, as far as I know.
also, the code will not be usable as-is. it has an number of insane hacks in various parts of the netfilter subsystem.

comment:70 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:72 Changed 3 years ago by anonymous

Thank you for your useless bump

comment:73 Changed 3 years ago by notorand

Please, stop this insane war.
There is no opensource driver for that hw NAT, so it cannot be added to any router, not just the 4300.
These friendly developers, while quite good at their job, cannot (still) do any miracle. That is the time consuming reverse engineering.

If anyone has enough money to buy the driver sources from Atheros and is willing to donate them to this project, she/he will be welcome to do so.
The same goes if anyone has enough spare time to reverse engineer the existing binary-only drivers.

In any other case, please, stop reopening this ticket.

comment:74 Changed 3 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Please I like to have this.

comment:75 Changed 3 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

comment:76 Changed 3 years ago by anonymous

lulz

comment:77 Changed 3 years ago by robnitro@…

Rtft- read the f€$%ING thread lol

Even the DDWRT official buffalo firmware lacks hw nat. They even didnt fix the slow up/down simultaneous speeds switch issue.
Meanwhile buffalo's own fw works fine and has much higher wan -lan throughput. Bs that ddwrt said they had special access to buffalo's drivers etc. Nope, same crap performance as the normal ddwrt.

Anyway, how about they get rid of anonymous posting, not just ticket reopening. In a lot of cases it causes confusion in diagnosing/testing issues/fixes.

Openwrt keep up the good work!

comment:78 Changed 3 years ago by notorand

To stop this nonsense war just leave the ticket open.
Non anonymous access just makes trolling a few clicks away.

Last edited 3 years ago by notorand (previous) (diff)

comment:80 Changed 3 years ago by anonymous

Source code for Hardware NAT driver development is at
https://dev.openwrt.org/ticket/11779#comment:23

comment:81 Changed 3 years ago by anonymous

Как же вы затрахали.

comment:82 Changed 3 years ago by anonymous

It's clear it's not just the driver (hardware). It's also (mainly) the integration with the iptables (software).
Not undoable, but it's clear that resources are scarce.
So, unless there is a bunch of volunteers outta there, please stop this insane nonsensical reopening war.

comment:84 Changed 3 years ago by notorand

That's for kernel v2.6!
OpenWRT is on v3.10 (14.07).

comment:85 follow-up: Changed 3 years ago by anonymous

I'd have no problem going back to kernel 2.6 for gigabit speeds. Hell I'd even drop wireless support completely. I can always just buy a separate dumb 802.11 ac AP for the wifi.

I just need the f!ing speed to be maxed out through my fiber installed in my home.

comment:86 in reply to: ↑ 85 Changed 3 years ago by anonymous

Replying to anonymous:

I'd have no problem going back to kernel 2.6 for gigabit speeds. Hell I'd even drop wireless support completely. I can always just buy a separate dumb 802.11 ac AP for the wifi.

I just need the f!ing speed to be maxed out through my fiber installed in my home.

.. at least 900 Mbps. I don't think I'm asking that much.
DAMN I wish I knew how to go about with programming those things..

comment:87 Changed 3 years ago by anonymous

We'll have a cheap available 10Gbps router next year. It's getting ridiculous with openwrt not supporting HW NAT.
Can't wait for this baby:
http://www.pcworld.com/article/2142569/got-gigabit-wi-fi-pshaw-quantenna-says-it-will-deliver-10-gigabit-wi-fi-in-2015.html
Too bad we won't be able to run OpenWRT on it due to missing HW NAT implementation

comment:89 Changed 3 years ago by anonymous

It's so sad users are blaming OpenWrt for this. Instead they should blame the chip maker for not having made a clean Linux implementation for their switch chip...

comment:90 follow-up: Changed 3 years ago by anonymous

stop harassing the devs with this. If you need gigabit WAN->LAN throughput just use the stock firmware till the openwrt or ddwrt will get it fixed. It's not a question of IF they get it fixed, it's just a matter of time. I foresee standard gigabit internet in 2015 for everyone and sure enough 10Gbps or even more in 2016 as an option.

comment:91 in reply to: ↑ 90 Changed 3 years ago by anonymous

Replying to anonymous:

I foresee standard gigabit internet in 2015 for everyone and sure enough 10Gbps or even more in 2016 as an option.

You must not live in Italy where the normal household bandwidth is 7Mbps down/512Kbps up, or in metropolitan areas 20Mbps down/1Mbps up... Of course with ZERO Kbps of guaranteed bandwidth. Yeah... this has been Internet in 2014 in Italy.

comment:92 Changed 3 years ago by anonymous

Well here we've got 60-80 Megabites per second internet on the mobile phone. As for fiber internet, even if you live in the woods you can get very cheaply 1000Mbps internet.
Tested not only advertised. (Romania)

comment:93 Changed 3 years ago by anonymous

Currently OpenWRT is on kernel v3. I hope they won't get back to kernel v2.
You could try dd-wrt which is still on v2.6 but I don't know whether they support this hardware.
Finally, whatever the pros can be to have HWaNAT, it will never happen if there is no developer working on it.
We can still revert to stock firmware, though.

comment:94 Changed 3 years ago by robnitro@…

If you want a Gigabit router, get a mini-itx dual core intel x86, and run zentyal or some other router sw on it.

The reason most of us run openwrt, is because the NEWER kernels, such as 3.14+ have better management of latency. That helps us with sub 100 mbit speeds when link gets saturated.

Stock firmware was never able to do this reliably for me. FIFO? LOL. Give me fq_codel or give me death, hahaha.

comment:95 follow-up: Changed 3 years ago by robnitro@…

Oh and the person that posted about 10 Gbps internet... what kind of NIC would be able to handle that? You do know that Gigabit nics top out at around 800-900 mbit realistically (with overhead, etc) on a LAN!?

So, tell me how are you planning to link to a 10G WAN? I can understand if it were a fiber directly in, and 10 fully dedicated Gigabit ports, but otherwise, you are talking some future ware that is way beyond any scope of even normal home LANs.

I have 75/75 mbit fiber, and even then I cannot always saturate my connection because most web providers have more than ONE customer at a time... lol

comment:96 in reply to: ↑ 95 Changed 3 years ago by anonymous

Replying to robnitro@…:

Oh and the person that posted about 10 Gbps internet... what kind of NIC would be able to handle that? You do know that Gigabit nics top out at around 800-900 mbit realistically (with overhead, etc) on a LAN!?

So, tell me how are you planning to link to a 10G WAN? I can understand if it were a fiber directly in, and 10 fully dedicated Gigabit ports, but otherwise, you are talking some future ware that is way beyond any scope of even normal home LANs.

If you plan to use 10Gbps you dont use a 1Gbps NIC. Or a 1Gbps switch. 10Gbps at home is not really worth it yet, but cost is not *completely* whack anymore with the latest generation of equipment.

I have 75/75 mbit fiber, and even then I cannot always saturate my connection because most web providers have more than ONE customer at a time... lol

I rarely have a download go slower than 500Mbps. Youtube and Akamai has no problems handing me ~600Mbps. Torrents often 8-900Mbps. FTP mirrors within the same country or some euro contries ~930Mbps. Transferring data to/from work at about 930-940 Mbps. I have not checked what Netflix is up to, but pre-buffering is never going on for more than 1 second, even for Ultra-HD.

Thats on fiber to the home in Norway, fwiw. Some areas have 10 Gbps available for residential, but that tier costs both your arms, both your legs and your first born at the moment, so I doubt any residential customer has dared to take the leap ;-)

I'm using a mini-itx i3 computer as gateway. It does gigabit routing/NAT in software, no problems. No ugly hardware "nat offload" required if the hardware is sufficiently fast. I think it could run OpenWRT too.

comment:97 Changed 3 years ago by anonymous

That's for kernel v2.6!

What's the trouble in porting it to 3.1?

comment:99 Changed 3 years ago by anonymous

People who think it is easy/straightforward to complete this task should attempt to do it themselves before opening this ticket.

comment:100 Changed 3 years ago by Dr-Shadow

Hi,

Maybe this task is not easy but should be still discussed. We got not that much information about the hwnat feature (what need to be implemented and such) and from where did you find hwnat was closed source (which parts at least in stock firmware for example).

I discussed some time ago with [florian] on IRC and he told me there was some work done on kernel to support generic flows of packets through HW but not yet for NAT.

comment:101 Changed 3 years ago by nasho

What is reasonable is to make patched Attitude Adjustment version with 2.6.32.66 kernel and hwnat drivers.
Attempt to make anything newer than that will make you pull your hair.

comment:102 follow-up: Changed 3 years ago by nbd

In my opinion that does not count as reasonable at all. Porting that kernel to OpenWrt is a big task, and even if you succeed (and that's a big if!), the binary-only crap will break with even simple things such as kmod-* package selection changes.

comment:103 Changed 3 years ago by robnitro@…

Look, I am not a programmer, nor pretend to know how much they go through to get things working. What I can say, is that a lot of programs are written in a cheap manner, to get things done- but are not very portable. Same problem exists in my field, electrical- where some specialized manufacturers are exempt from following normal code requirements, this making their devices propietary and strange to connect to standard devices. Think of how apple made their phones with a NON-USB connector, and how that would pertain to code that is non-standardized.

So, think about this: the OEM's made their code to work for their firmware. They took shortcuts to make it work the easiest they could.
Openwrt, being designed to be modular and work across a range of devices, cannot use the same framework.

If you want hw-nat, use the stock firmware. Nowadays, I stick with gargoyle based on OPENWRT, but overclock the router cpu to 800 mhz.
Best would be to run a low power x86 PC, much less hassle and no cpu limitation.

comment:104 in reply to: ↑ 102 Changed 3 years ago by anonymous

Replying to nbd:

kmod-* package selection changes.

or move that part to make kernel_menuconfig.
https://www.codeaurora.org/patches/external/qca/

comment:105 Changed 3 years ago by anonymous

Maybe you all should get Qualcomm to implement this properly rather than trying to coerce the OpenWrt developers into it. If Qualcomm gets it in the mainline kernel, and does it in the right way so that it doesn't break other things (e.g. netfilter), then that makes it easy for OpenWrt devs. The devs here have made it clear that they're not chasing this down at this point. This benefits Qualcomm in terms of OEM that may want to use this, so there is potentially motivation for them.

comment:106 Changed 3 years ago by anonymous

The only serious move is to push Qualcom/Atheros/Whoever to put those stupid sources in the public domain. At the very worst they will sell more boxes because of this. Not fewer.
Unluckily, they don't listen to normal users like me, you and the openWRT community.

comment:107 Changed 3 years ago by Cutty201

This thread provided me much enjoyment. Since no one on the requesting side seems interested in taking any actions (it reminds me of the humans in Wall-E). I made this:

https://www.change.org/p/qualcomm-create-a-clean-linux-implementation-for-hardware-nat-in-their-switch-chips-so-that-in-can-be-cleanly-implemented-into-3rd-party-firmwares?just_created=true

Before commenting, sign it. Thanks.

While I'm here, OpenWRT Rocks, thanks :)

comment:108 Changed 3 years ago by notorand

Besides considering Cutty201's petition an actual action, I am wondering how much Qualcomm will take it in any consideration.
In a scale between 0 and 10, I would say 0.
Qualcomm is a shortsighted company.
They just need to sell silicon. It's the same with mobile phones.
They just want to obtusely sell as much silicon as possible.
They don't understand that disclosing those sources would boost their sales.

BTW, the petition is closed.

comment:109 Changed 3 years ago by FloMo

Is there any progress?

comment:111 Changed 3 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Ok time for direct action. Email them and make a polite well written request to "Create a clean Linux implementation for Hardware NAT in their switch chips, so that in can be cleanly implemented into 3rd Party firmwares."

Mention how this will increase demand for their product.

Contact details

http://www.qualicom.com/about-us/contact-us/index.html

If successful getting the needed code please paste it back here.

Devs can you also please email them. your requests carry more weight

comment:112 Changed 3 years ago by notorand

First, it should be Qualcomm at https://www.qualcomm.com/company/about (check the spelling!)
Second. It won't move the situation by a single bit.

comment:113 Changed 3 years ago by jow

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:114 Changed 3 years ago by anonymous

  • Resolution set to Not there yet!!!
  • Status changed from closed to will finish just before heat death of visible universe

hahah just kidding. Keep up the good work.

comment:116 Changed 3 years ago by robnitro@…

You guys are something else, now to reopen it quoting me?

Why don't you appreciate what you have, these developers bust their humps with tons of issues. They don't need to cater to your SPECIFIC hardware if they didn't want to.

comment:117 Changed 3 years ago by anonymous

going outside the dev-pool. When I google openwrt software sevices i see the following names:
www.paxym.com Paxym SW
www.opennwrt-consulting.com OpenWRT onsulting
www.systemajik.com/blog/tag/openwrt SysteMagic Consulting

how do we go about talking to see if they have resources, interest and are hungry enough?

Changed 3 years ago by slavon8

comment:119 Changed 3 years ago by anonymous

If you really need this feature implemented, consider a donation at: https://www.bountysource.com/issues/22146362-wdr4300-hardware-nat-feature

Maybe this is a better motivation for a developer than bitching around like a child.

comment:120 Changed 2 years ago by anonymous

I would like to coin a new rule of thumb regarding the 1% rule. 1% of people (or even less) try to make a concept work, even if not optimized, going through a lot of constraints (time, information, organization, etc.); while the 99% gets their work for free and still feels entitled to complain. The sad thing is that this type of behaviour seems everywhere, even in a remote ticket for collaboration between developer and 'testers'.

With an analogy, 99% of people have their 'driver for the hardware nat' in their brain broken.

comment:121 Changed 2 years ago by anonymous

BEWARE: the site linked above by slavon8, "hpac dot com" is a trojan dropper.. my antivirus started screaming when i tried to access that.

comment:122 Changed 2 years ago by anonymous

To everyone who needs that functionality:

You can just use a normal 64bit computer with 2 gigabit LAN connectors and a cheap gigabit switch. You can run openwrt on this 64bit computer. You can drop the power usage of it up to 10-15W in total by using efficient hardware. If you would like to have wifi - just connect a wifi pcie/pci/usb card to this computer and enable it in the openwrt image you are running.

Yes, it would be nice if we could use cheap router with 5W of power usage. But thats not that a huge problem. Its just bit more power usage. Thats not worth the huge amount of work that have to be spend into developing that.

comment:123 Changed 2 years ago by anonymous

We need to stop trying to use crap, like most of these 600 or so mhz routers

https://lite.turris.cz/en/

open hardware designed for open software
high power dual core ARM CPU at 1.6 GHz capable of forwarding on gigabit speeds
1 GB of DDR3 RAM
4 GB of flash storage
5 LAN and 1 WAN gigabit ports
SFP for optical connectivity
OpenWrt based TurrisOS with automatic updates
secure by default with advanced protection
highly extensible and tweakable - miniPCIe, USB 3.0, mSATA, SPI, I²C, UART, GPIO
less than USD 200 for premium model and USD 100 for basic version

comment:124 follow-up: Changed 2 years ago by anonymous

  • Resolution invalid deleted
  • Status changed from closed to reopened

I think OpenWRT has the most retard dev team ever. They keep closing this ticket. When in this age we all have 1GBit connections or most of us. The user who started this already released a source. But you are head is too shoved into the ground. You guys are really lame. NAT HARDWARE IS A NECESSITY now more then ever. Not a "feature" . I am using Chaos Calmer on Archer C5 and between this and BB there is 0 performance difference. Like literally 0 ... so what you guys done ? Nothing. You want donations , I even donated for you suckers at the beginning but now you starting to become annoying. Now I am forced to use stock firmware because you guys are to busy circle jerking.

comment:125 follow-up: Changed 2 years ago by jow

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:126 in reply to: ↑ 125 ; follow-up: Changed 2 years ago by anonymous

Replying to jow:
Yeah keep closing it. What you guys will do when this shit gets real and more people realize that OpenWRT is now bullshit vs. Stock firmwares ?

comment:127 in reply to: ↑ 124 ; follow-up: Changed 2 years ago by anonymous

(I'm not a dev, just a user that tries to help with finding bugs etc)
Dumbass, did you see the reason why they can't do this? It's easy to bitch and complain and demand when you have no clue as to what it takes. I work with plenty of people like you who don't have a clue but demand things that are hindered by other factors that they are too lazy to find out about.

Just so you know and don't have to strain your 2 brain cells: the router mfr's don't release the propietary parts of the source code of their soc's. Sometimes they release source that uses many hacky things that would cause issues with openwrt. So, you want them to try to make it work with these issues?

HOW ABOUT THESE ROUTERS GET SOME REAL CPU'S INSTEAD OF CRAP?

Replying to anonymous:

I think OpenWRT has the most retard dev team ever. They keep closing this ticket. When in this age we all have 1GBit connections or most of us. The user who started this already released a source. But you are head is too shoved into the ground. You guys are really lame. NAT HARDWARE IS A NECESSITY now more then ever. Not a "feature" . I am using Chaos Calmer on Archer C5 and between this and BB there is 0 performance difference. Like literally 0 ... so what you guys done ? Nothing. You want donations , I even donated for you suckers at the beginning but now you starting to become annoying. Now I am forced to use stock firmware because you guys are to busy circle jerking.

comment:128 in reply to: ↑ 127 Changed 2 years ago by anonymous

Yeah sure. I am the moron. Not them right ? :) Sure. Fuck off. I am moving off OpenWRT bullshit. And never donate ever again to this kind of projects. Seems like they get to full of themselves at a certain point and do nothing for the users that supports them. I waited for this update or some movement on this ground for months. But seems like they are to stupid to do anything right. And yes with CC they did nothing VS. BB is just a waste of time. Literally 0 improvements. And still they bitching about users making requests.

Replying to anonymous:

(I'm not a dev, just a user that tries to help with finding bugs etc)
Dumbass, did you see the reason why they can't do this? It's easy to bitch and complain and demand when you have no clue as to what it takes. I work with plenty of people like you who don't have a clue but demand things that are hindered by other factors that they are too lazy to find out about.

Just so you know and don't have to strain your 2 brain cells: the router mfr's don't release the propietary parts of the source code of their soc's. Sometimes they release source that uses many hacky things that would cause issues with openwrt. So, you want them to try to make it work with these issues?

HOW ABOUT THESE ROUTERS GET SOME REAL CPU'S INSTEAD OF CRAP?

Replying to anonymous:

I think OpenWRT has the most retard dev team ever. They keep closing this ticket. When in this age we all have 1GBit connections or most of us. The user who started this already released a source. But you are head is too shoved into the ground. You guys are really lame. NAT HARDWARE IS A NECESSITY now more then ever. Not a "feature" . I am using Chaos Calmer on Archer C5 and between this and BB there is 0 performance difference. Like literally 0 ... so what you guys done ? Nothing. You want donations , I even donated for you suckers at the beginning but now you starting to become annoying. Now I am forced to use stock firmware because you guys are to busy circle jerking.

comment:129 in reply to: ↑ 126 Changed 2 years ago by jow

Please refrain from further insults and please do not reopen this ticket.

It has been decided that we'll not invest any work on this particular feature in the foreseeable future and you cannot enforce any work on this by continuously reopening this issue or yelling curses here.

comment:130 Changed 2 years ago by anonymous

  • Resolution invalid deleted
  • Status changed from closed to reopened

Ignorant lazy fucks

comment:131 Changed 2 years ago by jow

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:132 Changed 2 years ago by anonymous

do you have to find a way to solve this problem?

comment:133 Changed 2 years ago by qualquadrachenoncosa

Dear anonymous idiot,

We do not need lusers like you in the OpenWrt community. You just cannot say that OpenWrt has not evolved since BB, because you didn't get that stupid gigabit routing. If you ONLY want OpenWrt on your crappy-CPU router because of gigabit routing, and express your idiocy that way instead of understanding the problem, sorry you are in the wrong place and we are HAPPY to see you go. I hope you will be able to reflash the stock firmware without bricking your router, and goodbye, you are not welcome here anymore. If I was an OpenWrt admin I would refund your donation now.

comment:134 Changed 2 years ago by qualquadrachenoncosa

P.s.: it's OpenWrt, not OpenWRT.

comment:135 Changed 2 years ago by anonymous

Lol, you really lazy guys...
What do you think about HW NAT placed on the actual routers? It's for crappy shit cpu?
It's for idiots who buying 100$-200$ low energy routers instead Raspberry-PI stove?

Okay, I bought it with really cost(cheap Nexx wt3020) because this router marked with hw nat supporting, and what i have got with OpenWrt:

Strong encrypted http://softether.org/ client eat 50%cpu on 8Mbit - OK
Nice HFSC and FQ CoDel QoS queueing(qos-scripts package) eat 40% cpu on 24Mbit transit speed - OK

Simple 64Mbit loading via ethernet ISP eat about 70%cpu and didn't work on full speed if uses with QoS only, not VPN nay...
WTF?! Where hw_nat?
Really it is not a fun with OpenWrt?

So it not fully with nice qos-scripts but i will flash Russian firmware http://wive-ng.sourceforge.net/?WN-MT_MT7620N%2FH:Istoriya_izmeneniy its supports ralink_hw_nat yea for ipv6

comment:136 follow-ups: Changed 2 years ago by anonymous

WTH are you talking about?! Hardware NAT, even if it was implemented, is not compatible with QoS or encryption or other fancy things you can do with Linux and OpenWRT.

comment:137 in reply to: ↑ 136 Changed 2 years ago by anonymous

  • Resolution invalid deleted
  • Status changed from closed to reopened

Replying to anonymous:

WTH are you talking about?! Hardware NAT, even if it was implemented, is not compatible with QoS or encryption or other fancy things you can do with Linux and OpenWRT.

It's posiible to writing kernel module that just gets not nated packets from virtual network device kernel stack and pull out it to hardware nat. No?

comment:138 in reply to: ↑ 136 Changed 2 years ago by anonymous

Replying to anonymous:

WTH are you talking about?! Hardware NAT, even if it was implemented, is not compatible with QoS or encryption or other fancy things you can do with Linux and OpenWRT.

It's posiible to writing kernel module that just gets not nated packets from virtual network device kernel stack and pull out it to hardware nat. No?

Please read "hw_nat" entries here http://wive-ng.sourceforge.net/?WN-MT_MT7620N%2FH:Istoriya_izmeneniy

comment:139 in reply to: ↑ 136 Changed 2 years ago by anonymous

Replying to anonymous:

WTH are you talking about?! Hardware NAT, even if it was implemented, is not compatible with QoS or encryption or other fancy things you can do with Linux and OpenWRT.

It's posiible to writing kernel module that just gets not nated packets from virtual network device kernel stack and pull out it to hardware nat. No?

DEVELOPERS, please read "hw_nat" entries here http://wive-ng.sourceforge.net/?WN-MT_MT7620N%2FH:Istoriya_izmeneniy

comment:140 Changed 2 years ago by anonymous

yea looks like russian guys know how to do it.

one thing i wonder why devs here so stubborn and don't want to add proprietary nat/wifi modules for targets/devices they can't make functional with opensource driver, except for stupid broadcom which is worhtless either way no matter what driver it use

comment:141 Changed 2 years ago by cyrus

  • Resolution set to invalid
  • Status changed from reopened to closed

Feel free to fork OpenWrt and add / maintain support for proprietary NAT or Wifi modules to your fork. You know our decision so stop reopening this ticket or we will eventually delete it after all.

comment:142 Changed 2 years ago by anonymous

you are wrong. somebody else reopened it, i just posted a reply.

comment:143 Changed 2 years ago by common sense

Wow, looking for things to be wrong about.
You do realize that everyone's comment here shows up as "anonymous" right?

If the Russian fw works so well, just use it. You see that they support very few devices, right? It's like developing games for Consoles vs PC. The console games can use more proprietary techniques because they can pick and choose exactly what to do.
PC developers have to make it compatible along many differing hardware configuations. What may work for hw nat for one router may create issues on other routers.
I can only imagine the headache involved.

What Cyrus wrote was quite fair: Anyone who wants to use openwrt and develop special hw nat versions are free to do so! Beggars can't be choosers here, or anywhere.

comment:144 Changed 2 years ago by anonymous

Most broken English I have ever seen in this thread. Learn to properly speak English before making nonsense tickets over and over and over again.

comment:145 Changed 2 years ago by BORAT

Why you make fun of me. In Kazakstan we have hardware nat in every horse and cow! This is why you are lazy english speaker

comment:146 Changed 2 years ago by anonymous

  • Resolution invalid deleted
  • Status changed from closed to reopened

Why this has been closed??? Please leave it open as a reminder for the developers.

comment:147 Changed 2 years ago by anonymous

It needs to stay closed as there's no viable way to implement it.
There is no source code available, the tech specs are undisclosed (AFAIK) and there's none willing to spend months and years in such a project.
If anyone has money to hire programmers or the power to force Atheros to release the code, then I beg her/him to go on.
Otherwise it's all a waste of bytes and time.
(The same concepts are explained better and earlier in the above comments).

comment:148 Changed 2 years ago by nbd

  • Resolution set to invalid
  • Status changed from reopened to closed

We have too many open tickets already. Leaving this ticket open is completely useless as a reminder.

comment:149 Changed 2 years ago by anonymous

Yes, there are over 3000 bugs open. We did not need a reminder on one more.

comment:150 Changed 2 years ago by zloop

Just an overview:

  • HW NAT support depends on many things
  • There are several issues preventing hw nat support/make it "not worth" for some devs:

1: it may limit configuration of firewall rules
2: no support in mainline Linux Kernel for QCA switches (or other switches supported in OpenWrt)
3: information difficult to obtain
4: QCA not really interested in pushing this issue (it seems at least that the case for now)

1: afaik this is already documented by hw vendor firmware

2: some OpenWrt patches for switch hw were rejected from Kernel (2013):

see https://lwn.net/Articles/571390/ or https://lwn.net/Articles/634787/ (b53 and general OpenWrt API)
dont know the current status of the QCA stuff from: https://lwn.net/Articles/646595/

AFTER the switch driver is in mainline THEN adding offloading / "hwnat" patches to kernel or keeping them in OpenWrt might be more manageable for devs

3: there are some (leaked?) datasheets with registers of AR8327N - however the Kernel situation is still unclear (which api/driver approach would be best ... - see discussions on LKML/netdev lists)

4: http://vger.kernel.org/switch_info.html has links for qca/codeaurora stuff that might have info or some code

comment:151 Changed 2 years ago by anonymous

I found on the internet datasheet of the QCA8337N switch chip which support NAT offload. Good document for developing features like this topic, but...
It can hold only 1024 entries in the translation table. It is not too much and it supports only TCP,UDP,GRE protocols. It could overflow with a simple torrent client, and then comes the real headache.
So as I see, HW NAT in branch market devices is good for speedtests and similar but not for everyday production use.

comment:152 Changed 2 years ago by notorand

Simple NAT has 32 entried and is maintained only by CPU (!)
NATP is 1024 entries and should be "switch maintained" (!!).
I agree with previous comment. I am not sure if it'd be worth it.

comment:153 Changed 2 years ago by anonymous

The hardware NAT is different from how Kernel does it.
It unlike the kernel it is stateless so it will actually not limit based on the number of connections.

comment:154 Changed 2 years ago by valentt

Also regarding hardware vs software nat, Mikrotik guys developed something called Fasttrack, they claim this is much better than hardware nat. Has anybody taken a look at how their technology works? Maybe it could inspire kernel devs also...

comment:155 Changed 2 years ago by valentt

It looks like Fasttrack has lots of limitations also, but FastPath looks a bit better - http://wiki.mikrotik.com/wiki/Manual:Fast_Path

Mikrotik developer explaining what are benefits of fasttrack vs hwnat in this forum post - http://forum.mikrotik.com/viewtopic.php?f=3&t=101670&hilit=openwrt#p511206

Last edited 2 years ago by valentt (previous) (diff)

comment:156 Changed 2 years ago by anonymous

If you want to know, how doing big vendors /like cisco/ HW NAT, for example on their a9k routers CGN module, download the CGN module's software and extract/analyse it. It uses a lot of general purpose intel x86 CPUs and a special NAT binary handle those CPU cores. In cisco IOS there are a lot of optimizations as in MikroTik RoS and maybe in Linux kernel too. But the Linux kernel's goal is not providing routing platform but only a good base for it like in MikroTik RoS.
NAT ASICs has a lot of limitations or that ASIC is not a cheap one.

comment:158 Changed 2 years ago by anonymous

Bummer...

https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/030214.html

"Our request for uploading the sources is pending approval from
Marvell's legal department."

and no more

comment:159 Changed 21 months ago by anonymous

Could these be theoretically implemented and improve the routing performance in OpenWrt?

http://www.openfastpath.org/
http://www.opendataplane.org/

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.