The following is the output from running the command line again (with java, instead of javaw):
java.net.BindException: Address already in use: JVM_Bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(Unknown Source)
at java.net.ServerSocket.bind(Unknown Source)
at java.net.ServerSocket.(Unknown Source)
at java.net.ServerSocket.(Unknown Source)
at VASSAL.launch.ModuleManager.(ModuleManager.java:250)
at VASSAL.launch.ModuleManager.main(ModuleManager.java:150)
VASSAL: Couldn’t open socket on port 62616
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.(Unknown Source)
at java.net.Socket.(Unknown Source)
at VASSAL.launch.ModuleManager.main(ModuleManager.java:170)
Here’s what I see: VASSAL tries to bind to a socket, but that fails.
Normally, this would mean that there’s another instance of VASSAL already
running. Then, VASSAL tries to connect to the already-open socket on
port 62616, but that also fails.
We need to see what it is that has port 62616 open in the first place.
Do this:
Run VASSAL again, as before.
Then, run ‘netstat -a’. (This will show us what ports are in use, and
what is using them.)
netstat shows nothing using port 62616 on the loopback interface, so either
whatever was bound to that port stopped using it between when you started
VASSAL and when you ran netstat, or (more probably) Vista was blocking
VASSAL from binding to that port, despite its being unused.
Are you running any firewall software which would prevent you from connecting
to local ports?
BTW, I saw this when googling “local ports” and “vista” “firewall”: social.msdn.microsoft.com/Forums … 83ef399f8/
You think this has something to do with the problem?
I am not knowledgeable enough to make that call.
Good idea. If it’s possible to run VASSAL without the local firewall on,
then we need to find a way to get the local firewall not to block the
loopback device, since I imagine that lots of Vista users will have this
same problem.
Out of interest, I just turned the firewall on and started up Vassal. I got a popup saying Java was trying to access the network, did I want to unblock it. I clicked unblock and the Module Manager ran ok. Starting a module, same thing. I can now run Vassal with no problems and no popups on Vista with firewall running.
I tried turning the Firewall off and on.
I tried opening up the VASSAL.exe from the shortcut on the desktop.
No change in either mode.
I then proceeded to try and run VASSAL using the command window, but no change there in either mode.
Lastly, I tried running the diagnostic program in both modes from the command line and there were no change when switching modes on the firewall.
After switching modes, I did not reboot or anything, but i doubt that it is necessary as Vista says the computer is not secure from incoming malware etc. after turning the Firewall off.
That’s perplexing. It appears that we’re not being blocked by Vista’s
firewall.
Ok, I’d like to see if you can get VASSAL to run using a different port.
Try this:
In your user directory, there should be a directory called VASSAL which
contains a file called Preferences. Rename this file to something else.
(This way, the next time you try to start VASSAL, it will pick a different
port on which to listen.)
Then, try to start VASSAL from a terminal and tell me what you see.
(If this doesn’t work, then I’m going to write a small test program for
you to try. We’ll get this yet.)
How do we make this permanent and what do yuo need further from me to make sure we find the error that may cause other Vista owners to scratch their head.
See, I expected that to work, but was kind of hoping that it woudln’t,
because I knew that if it worked, I’d have no explanation for why this
works but the other port didn’t.
VASSAL is listening on port 53466 now (with your firewall on?).
It was trying to listen on port 62616, and failing to bind. According to
netstat, there wasn’t anything bound to port 62616 immediately after you
tried to start VASSAL. Having the firewall on or off made no difference.
Tonight I’m going to write a little test program which tries to connect
to each port in the dynamic range on your loopback device, just to see
which ones are available and if there’s a weird cutoff or something.
Watch this space…
Attached to this post is a tester which will check which ports in the
non-reserved range are available for binding on your system.
To use it:
Unzip the archive.
In your shell, cd to the directory (called “local-ports”) created when you
unzipped the archive.
Run: java Test
You should get a list of ports which can’t be bound to. Copy that list
here for me.
While I was writing this test, I discovered that the Module Manager tries to
bind to all interfaces, and not just the loopback. That might be the cause
of your problem. In any case, it’s a bug, which I’ll fix for 3.1.4.
