MT7621 HW NAT Offloading broken

In 18.06.5 it worked. Never tried 18.06.6, but I can indeed confirm it is broken in 19.07.0.

Thanks. I will compile with the patch to disable flow control on switch (the famous transmit timed out kernel error) and I am uncertain whether to compile, 19.07 or 18.06.x. HW NAT is decisive.

Just follow the wiki, you’ll be fine.

I myself just finished compiling it, with the patch you mentioned.

Edit: Dose flow control have anything to do with offloading?

Yes, i have compiled other times but my pc takes many hours and i wanted to be sure which version to use before doing so. This patch is only for disable switch flow control on eth ports that causes (apparently) kernel crash in MT7621. Nothing to do with hardware flow offloading (HW NAT).

I'm looking for a way to enable HW NAT in 19.07 or master branch, otherwise i will compile 18.06.x.

Although HW offloading may be broken in 19.07.0, it seems work okay with master branch.

BTW, HW offloading do not necessarily let you get higher scores in a speed test. For me it's the same with or without offloading.

Well, in some post i read that it was also broken in master branch.
With FTTH 1000/300, the download speed reaches ~500Mbps without HW NAT and ~930 with it. For less than 500Mbps it is not essential, but it also helps not load the cpu and leave it for other tasks (vpn for example).

How did you verify whether it is working? Because you can enable it just fine, but packets aren't actually being offloaded. CPU load is just as high as if offloading isn't enabled.

It depends also if you are using pppoe or not...

Ah, I am using PPPoE. Is that the reason it's broken? It worked fine on 18.06.5 for me though. What broke it?

As Mushoz said, that can enable (on LuCI or CLI) does not mean that it works.

MT7621 HW Flow Offloading can do it on PPPoE, but on 19.07 and master (maybe) are also broken.

I can confirm that HW NAT Offloading works on 18.06.6.

Thanks for the info. Now I am trying to build the 18.06.6 with the flow control off patch.

Edit: Tested my own compiled 18.06.6 with HW offloading, for some reason I cannot get good speed with dslreport tests, only 320M/406M and not steady speed. With speedtest.net however, I can get 858M/844M with my 1Gbps fiber.

A few more tests are made, it seems HW offloading is not working right after applying the disabling of flow control patch. The downloading throughput with HW offloading on is worse than it off, not only lower but not even as steady anymore.

Can someone confirm wether the HW offloading is connected with flow control in anyway, somehow?

BTW, the resource usage did down a lot with HW offloading on.

I have not tried it. I have stopped compiling 18.06.6 because i am testing the official build, and HW Flow Offloading must have some problems opening and/or keeping many connections or close it too fast because the P2P are very slow (especially when uploading). So now i'm compiling 19.07.0. I'd rather have a stable router, connection and performance than reach full speed.

Does that mean you don't care about HW Flow Offloading anymore, since 19.07.0 has bug with it?

In 19.07 it does not work at all, but in 18.06.6 it seems to have bugs, at least p2p does not perform the same as with the deactivated one. You say that it also does not work as it should with the patch, therefore i prefer to have 19.07 even if HW Flow Offloading is not working. But with the patch to disable flow control. For months i haved crash kernel errors and i want stability. I hope to get it with the patch. Of course when in the master branch or 19.07 HW Flow Offloading works, i will try it again.

What exactly do you mean by the possible bug in 18.06.6 regarding hw offloading?

There seems to be a patch that fixes HW Flow Offloading on 19.07+/master. I will prove it. https://github.com/openwrt/openwrt/pull/2815

3 Likes

Works for me on 18.06.8