Can't bind to TCP socket in windows server 2008 r2

[behealed]

I'm using a VPS server that I am accessing through remote desktop. The server is running windows server 2008 r2. I can bind to UDP port 9933, but I can't bind to TCP!

16 Jan 2011 04:30:24,593 WARN [main] bootLogger - Was not able to bind socket: { 127.0.0.1:9933, (Tcp) }
16 Jan 2011 04:30:24,594 WARN [main] bootLogger - Was not able to bind socket: { 168.144.99.115:9933, (Tcp) }
16 Jan 2011 04:30:24,597 INFO [main] bootLogger - Added bound udp socket --> 168.144.99.115:9933

My localhost is 127.0.0.1
My public IP is 168.144.99.115

ipconfig yields the following text:

Ethernet adapter local area connection:
connection-specific DNS suffix: ad3.softcom.biz
IPv4 address....... 168.144.99.115
subnet mask....... 255.255.255.0
default gateway... 168.144.99.1

That's all the info from ipconfig. Also, the server config shows 168.144.99.115 as a bindable IP address in the drop down.

I have added the public IP to the server config in the admin tool for both TCP and UDP.

And in my windows firewall settings, I add port local port 9933 to allow all outbound connections, once for TCP, and again for UDP. Then I went to the inbound connections and did it again to add port local port 9933 for all inbound connections, once for TCP, and again for UDP.

I'm not sure what else to do? I tried typing telnet at the commend prompt and it says I don't have telnet installed. It binds to UDP just fine.

[behealed]

Well I restarted windows and now it won't bind to UPD either, so now both TPC and UPD, both local and public ips, all fail to bind. I didn't change anything in the firewall settings.

So as just a test, I located up my FTP server program that I always use on port 21 and told it to attempt to bind to port 9933 instead (with SFSx2 shut down of course), and it failed to bind to port 9933. But it binds just fine to port 21. And the firewall is set up to enable it (as a program) to bind to ALL ports.

So obviously my server just doesn't want to let any program bind anything on port 9933. Is there another port I can use for SFSx2 instead of 9933?

[behealed]

Well it binds just fine to port 1933 for both TCP and UDP, so that's what I'm going to try to use unless someone comes here and gives me some good reason not to.

[ThomasLund]

You can run it on any ports you like.

Cause of it not binding typically is something else using those ports. Already running SFS2X or something else

[behealed]

It's being really annoying!

Every time I reboot... whatever ports were working before no longer work. At first, the default port 9933 worked for TCP. Then I rebooted, and 9933 wouldn't bind to TCP anymore. So I added UDP on 9933, and it bound. Then I rebooted for some reason, and UDP wouldn't bind to 9933 anymore.

So I added 1933 for TCP and UDP, and both bound. I even restarted the program a few times, and each time it would bind. I even played the demo a few times, and everything worked. Then I rebooted today because of a windows update, and now 1933 won't bind for TCP or UDP, and neither will 9933.

Why is it that every time I reboot, the ports won't bind that previously would bind? The server is a VPS, so is it possible that somehow when the server reboots... the ports are not getting "freed" that had been bound by SFSx2? Since most of these reboots involved SFSx2 being forcefully shut down by the reboot process.

This is really weird behavior that's for sure. I figure I could add the port 1934 and it would bind, but then when I reboot, it's going to not bind anymore. Eventually I'll run out of bindable ports if this behavior continues.

[behealed]

Okay I found that you could type "netstat -p tcp -ano" in the c:\windows directory of a command prompt, and it would tell you what ports are open. I found that 9933 and 1933 are indeed open as "listening" by a process with ID number 1716. I then opened task manager, and found that there are three services with 1716 id...

Net.Tcp Port Sharing Service
Net.Tcp Listener Adaptor
Net.Pipe Listener Adapter

Any idea why, after a full reboot, these services are always listening to any port that I happened to was using with SFSx2 prior to the reboot? :-p

I also use "COREFtp server" on port 21, and it's always open on port 21, and when I reboot... port 21 is still free. So why can coreftp use port 21 without messing it up when I reboot, but SFSx2 can't use port 9933 without it getting messed up when I reboot.

[ThomasLund]

Maybe you installed SFS as a service - and it auto starts on the port you specified in the config and thus occupies it

[behealed]

GAAAAAHHHH !!! SFSx2 service is running on my server!

Does it show up in the task manager processes? NO!
Does it show up in the task manager services? NO!

I saw that netstat still showed that the port 9933 was still being used even after I manually disabled the three processes mentioned above.

So I downloaded advanced task manager to try to find the "hidden" process that must have been using. And what do you know, it's the sneaky fox server causing all these problems after all.

I could sware I never told it to install as a service.

EDIT: it does show up in the task manager services, but the PID id is incorrect there. That's why I didn't find it earlier, because I was sorting by pid. Windows fault. Thanks Thomus for your replies.

[behealed]

Well not all windows fault. All of this proves one thing: the service doesn't work, but the standalone works. Because whatever ports get bound by the service, those are the ports that the clients can't connect to. And the ports that get bound by the standalone, work. So goodbye service!

[Lapo]

For starters the installer has one entire screen devoted to the installation as a service. Maybe you didn't notice it, it's not a problem.
The service does show up in the service list under the Windows management console, and it's called "sfs2x service"

When the server runs a service you can easily monitor any problems with the bound sockets via the log files. In fact at the end of the boot sequence SFS2X lists all sockets he was able to bind.

The problem might be related with a permission problem in Windows where, if the User running the service does not have enough permissions, it will end up not working correctly.
I would definitely recommend to check:
1- the server logs as I explained
2- the windows system logs for possible warnings on permissions

The bottom line is... there is absolutely no difference in how the server works when running standalone or as service, therefore the problem is highly likely to be dependent on your OS config.

Hope it helps

[anasmatic]

I just close the standalone
- then open the task manager
- go to process
-rightclick on "sfs2x-service.exe" and end precess tree
if you find 2 "sfs2x-service.exe", rightclick on the lowest on memory

open the stand alone again, and it's done.

this works for me, I hope it does for u

[wajitarar]

we are using amazon cloud server,
i had the same problem. it has been resolved.

i resolved it by adding elastic ip address
like if ip is "127.0.0.1" the full elastic ip adress is "ec2-127-0-0-1.compute-1.amazonaws.com"

<socket address="ec2-127-0-0-1.compute-1.amazonaws.com" port="9933" type="TCP"/>

it worked for me.