Forums Archived

This forum has been archived. No new posts can be made and no new users can sign up. It remains here for reference only.

Find the new forums here

7 Days to Die module change - Game port should be TCP+UDP

  • 366 Views
  • Last Post 18 September 2020
  • Topic Is Solved
AbhorrentJoel posted this 25 August 2020

As in the title, game port should be both TCP and UDP (important if using the ampfirewall.timer as opposed to manually adding rules). Using the latest version (Alpha 19 (b180)), it is necessary to have TCP open alongside UDP otherwise the client will fail to retrieve server information.

I can't think of any other changes to the ports right now.

Order By: Standard | Newest | Votes
Mike posted this 03 September 2020

Noted, this is in the next nightly.

AbhorrentJoel posted this 09 September 2020

Nightly v20200909.1 (ADS and SevenDays instances) is still only showing UDP (as opposed to TCP+UDP) in the port usage for the instance when editing the port bindings. I do not know if the ampfirewall actually opens the ports on both protocols since I am not running it on the Linux system (testing on a local Windows installation), but probably not if it is not showing both in the bindings.

Mike posted this 09 September 2020

AMP only provides automatic firewall management on Linux.

AbhorrentJoel posted this 09 September 2020

Understood. But as mentioned, the port is only showing for one protocol (UDP) as opposed to both.

Mike posted this 10 September 2020

That's been fixed in a recent update. Only new instances will get the updated rules though.

AbhorrentJoel posted this 17 September 2020

Which update fixed this? I am now running v2.0.6.6 and it's still showing UDP only in the AMP panel (port bindings), even on a new instance.

On the main (Linux) system, the ufw rules for the new instance are also only showing for UDP:

root@[redacted]:~# ufw status numbered | grep 27016
[34] 27016/udp                  ALLOW IN    Anywhere                   # AMP:SevenDays03:SevenDaysModule.Server.ServerPort
[66] 27016/udp (v6)             ALLOW IN    Anywhere (v6)              # AMP:SevenDays03:SevenDaysModule.Server.ServerPort

To further this, I installed the Nightly (v20200917.6) on my Windows system, and the port bindings in AMP panel are still only UDP.

When is this going to be updated?

Mike posted this 18 September 2020

Do you have the latest version of ampinstmgr ? I'm seeing in the metadata that it's listed as "TCPUDPPort" (AMPs internal representation for 'Both' protocols)

Can you also post the output of ampinstmgr dumpports amp as root?

Also which distro are you using?

AbhorrentJoel posted this 18 September 2020

I am using Ubuntu 20.04.1 LTS. The package manager has the latest version installed: ampinstmgr/stable,now 2.0.6.6 amd64 [installed]. All instances, including the ADS, are running v2.0.6.6.

Grep'd output from dumpports:

root@[redacted]:~# ampinstmgr dumpports amp | grep SevenDays03
[Info] TCP/2232 (AMP:SevenDays03:FileManagerPlugin.SFTP.SFTPPortNumber)
[Info] UDP/27016 (AMP:SevenDays03:SevenDaysModule.Server.ServerPort)
[Info] TCP/8768 (AMP:SevenDays03:SevenDaysModule.Server.WebServicePort)
[Info] TCP/27017 (AMP:SevenDays03:SevenDaysModule.Server.TelnetPort)

Note: SevenDays03 is a new instance, which was created after the upgrade.

Mike posted this 18 September 2020

Can you remove the ampinstmgr package, flush your apt cache to remove the package, then re-install ampinstmgr and run the same command again please.

AbhorrentJoel posted this 18 September 2020

Have followed your instructions and can confirm now that ampinstmgr dumpports amp grepping for the instance shows the ports for both TCP and UDP:

[Info] TCP/2232 (AMP:SevenDays03:FileManagerPlugin.SFTP.SFTPPortNumber)
[Info] TCP/8768 (AMP:SevenDays03:SevenDaysModule.Server.WebServicePort)
[Info] TCP/27017 (AMP:SevenDays03:SevenDaysModule.Server.TelnetPort)
[Info] TCP/27016 (AMP:SevenDays03:SevenDaysModule.Server.ServerPort)
[Info] UDP/27016 (AMP:SevenDays03:SevenDaysModule.Server.ServerPort)

The ports also show for the ufw:

2232/tcp                   ALLOW       Anywhere                   # AMP:SevenDays03:FileManagerPlugin.SFTP.SFTPPortNumber
8768/tcp                   ALLOW       Anywhere                   # AMP:SevenDays03:SevenDaysModule.Server.WebServicePort
27017/tcp                  ALLOW       Anywhere                   # AMP:SevenDays03:SevenDaysModule.Server.TelnetPort
27016/tcp                  ALLOW       Anywhere                   # AMP:SevenDays03:SevenDaysModule.Server.ServerPort
27016/udp                  ALLOW       Anywhere                   # AMP:SevenDays03:SevenDaysModule.Server.ServerPort
2232/tcp (v6)              ALLOW       Anywhere (v6)              # AMP:SevenDays03:FileManagerPlugin.SFTP.SFTPPortNumber
8768/tcp (v6)              ALLOW       Anywhere (v6)              # AMP:SevenDays03:SevenDaysModule.Server.WebServicePort
27017/tcp (v6)             ALLOW       Anywhere (v6)              # AMP:SevenDays03:SevenDaysModule.Server.TelnetPort
27016/tcp (v6)             ALLOW       Anywhere (v6)              # AMP:SevenDays03:SevenDaysModule.Server.ServerPort
27016/udp (v6)             ALLOW       Anywhere (v6)              # AMP:SevenDays03:SevenDaysModule.Server.ServerPort

These rules have also been applied to existing instances, too.

Just to note, it is still showing only UDP for the port bindings in the panel. Obviously I know it isn't, but I just wanted to make that clear. Is that a problem my side or in AMP itself? On a fresh AMP install on Windows (deleting the existing data store), it was still only showing UDP in the port bindings via the panel.

Thanks for the help here.

Just one more thing, I've noticed that the ampfirewall.timer doesn't seem to re-enable itself after an update to ampinstmgr via apt. I can certainly make a separate thread if necessary when it next happens if that is not expected behaviour.

Mike posted this 18 September 2020

Try doing ampinstmgr --nocache upgradeall if the panel isn't showing it.

As for the ampfirewall timer, that's not an intended behaviour but no need to make a new thread - I'll look into it.

AbhorrentJoel posted this 18 September 2020

Looks like that's solved it all. Thank you.

In regards to the ampfirewall timer, I wish I had made a better log. But if you can't find a problem and it occurs again, I will have to do some digging as it could be something my end.

Close