Hi @psychedelicu 

Thanks for posting in our business forum.

So, I read through your GitHub. I don't think it is a controller issue.

There is nothing changed in the firewall settings which I think they don't correlate to your problem. These firewall parameters are default.

I would assume that there is something on your NPM setup. Something like cache size or threads should be increased to enable a faster and multiple-session connection.

If possible, you can bypass the router. Connect your server PC to the ISP fiber/line to check if you can get a full 600Mbps upload on the bare connection.

Hi @psychedelicu 

Thanks for posting in our business forum.

psychedelicu wrote

  @Clive_A But it was related, unfortunately. I reset everything, software controller, ER605 and the SG 2008 switch. Before that, I disabled Deep Packet Inspection, and every time I deleted the logs it seemed to work... for the first time, the speed jumped to 500mbps, so it works.

 

After a few hundred mb uploaded to nextcloud, I received a warning in the log again and the upload fail, "Detected TCP SYN packets attack and dropped *** packets", although these settings were completely turned off, all the options from settings really. Of course, I rebooted the router after modifying them, but this still appeared in the log. I also tried force provisioning, but the upload was always limited after this detection.

 

I reset everything and now the problems are gone. I wasted almost 2 months trying to find a fix for NPM or Nextcloud, when in fact the problem was with Omada. Before I had an AX1500 router and I had absolutely no such problem.

 

And this is just one problem, I had a lot of other problems that I prefer to forget and regret that I chose Omada, because the support is 0 to none when you need it. 

It seems that you are the only one responding on this forum for some time. TP-Link should make some more hires if they want to stay on the market.

So, HTTP/2, it is TCP. That might trigger TCP SYN packet attack.

"HTTP/2 is based on the TCP protocol. HTTP/2 employs multiplexing technology over a single TCP connection, allowing multiple requests and responses to be transmitted in parallel, solving the head-of-line blocking problem present in HTTP/1.x versions. Moreover, HTTP/2 introduces features such as header compression and server push to optimize performance and reduce latency."

But I still hold a grain of salt here as it is over a single TCP connection.

While /3 seems to be UDP. I cannot relate it to the TCP SYN.

I recall DPI would only block if you enable it for blocking purposes. Or it only records.

You can contact the email support and will get a reply all the time. Forum workload so far is not overwhelming and it is split by a co-worker who's in charge of the Controller and WIFI.

So, overall, it is a myth and I am not convinced by the remarks so far. I am pretty sure it should not be a firewall issue as your Github showed pretty much the basic setting of the controller default. I would assume that you disabled Hardware Offload before the reset?

Hi @psychedelicu 

Thanks for posting in our business forum.

psychedelicu wrote

  @Clive_A Hardware Offload was enabled all the time, even now it is active. There was definitely a bug somewhere, considering that the NAT didn't work either and many times the ports were either closed or open. The router restarted itself almost daily, even twice a day. Now it seems he doesn't do that anymore, because I'm already on the 4th hard reset.

 

And like i said before, those security features were completly disabled, but the logs were still filled with that TCP SYN packet attack detection. Now I'm going to leave it as it comes from the factory by default, because I'm afraid mess it up with the settings again. 

 

I thank the GPT chat for telling me to disable deep packet inspection, otherwise I wouldn't have realized that the router was actually the problem. I'm sure that DPI was not the cause of this issue, maybe only some performance hit on it, but that made me realize that the settings were somehow not being applied on the router. 

DPI and IDS would be demanding in CPU. That would affect the overall Internet speed and this is known.

Since this cannot be replicated as you have reset it, will discuss if someone has the same problem with a backup. That'll be worth a further investigation.

But thanks for bringing this up on the forum as a piece of record.

TCP SYN has a solution post: