It's been at least a week or so since I last tackled this. Work has been stressful. I like my job it's just sometimes it can wear me out. So I only started back on this today.
Anyway, I'm able to telnet into the console on the other machine. I still can't connect through Oolite and I haven't tried a compile (yet). But I did get this in the log when I ran it this time and figured it might mean something.
[debugTCP.disconnect]: Debug console disconnected with message Lost connection to remote debug console. Stream status: 7. Stream error: A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied.
[debugTCP.connect.failed]: Failed to connect to debug console at 192.168.1.92:8563.
I'll continue working with it but maybe someone can shed some light on this while I get another beer. Anyone want one while I'm up?
Randy
Maybe it's just a bunch of stuff that happens. -- Homer Simpson
The message you got there should be on all logs whenever there is no console running. You do run the console on the remote computer before starting Oolite, right? Are you sure this message was not coming up at all earlier?
Also (wild guess): Are there any subnet masks defined on any of the two computers? If yes, are they the same? Can one computer ping the other? Can you also tell us what the file structure of the debug.oxp you are using is? More specifically, can you confirm that there is a file called DebugOXPLocatorBeacon.magic in the root folder of the Debug.oxp? Without it, the console will not connect.
I'm puzzled that you can't connect, because when this was tested, it was a PC running Oolite (mine) connecting through the Internet with a Mac running the console (Ahruman's). Back then it had worked perfectly fine and the code has not changed since if I recall correctly. I am assuming it has to be some setting on your network.
[Edit: The code has not changed, but the actual gnustep-base dll did. I guess we may have to set up an over-the-net test again, if we want to be 100% sure.]
Hi A.C. First off, thank you for taking your time to help with this. I'm sure there are more important things like taking out the garbage.
Are there any subnet masks defined on any of the two computers? If yes, are they the same?
They are both 255.255.255.0
Can one computer ping the other?
Oh yes, and I can even telnet into DOS and see the C: drive, do a DIR command, etc.
Can you also tell us what the file structure of the debug.oxp you are using is? More specifically, can you confirm that there is a file called DebugOXPLocatorBeacon.magic in the root folder of the Debug.oxp? Without it, the console will not connect.
Sure. It's C:\Program Files\Oolite\AddOns\Debug.oxp. Within that I have three folders: Config, Contents, Scripts. I have requires.plist and DebugOXPLocationBeacon.magic.
I'm looking for some freeware network utilities to see if I can see anything trying to get through 8563 to find out if it is the sending or receiving computer that may be the problem.
Randy
Edit:
The message you got there should be on all logs whenever there is no console running. You do run the console on the remote computer before starting Oolite, right? Are you sure this message was not coming up at all earlier?
Yes. Bizarre isn't it?
Maybe it's just a bunch of stuff that happens. -- Homer Simpson
No. Time Source Destination Protocol Info
28 1010.151833 192.168.1.93 192.168.1.95 TCP vfo > 8563 [SYN] Seq=0 Win=65535 Len=0 MSS=1360 WS=2
Frame 28 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: MS-NLB-PhysServer-17_09:03:0c:34 (02:11:09:03:0c:34), Dst: AskeyCom_28:aa:67 (00:1b:9e:28:aa:67)
Internet Protocol, Src: 192.168.1.93 (192.168.1.93), Dst: 192.168.1.95 (192.168.1.95)
Transmission Control Protocol, Src Port: vfo (1056), Dst Port: 8563 (8563), Seq: 0, Len: 0
Source port: vfo (1056)
Destination port: 8563 (8563)
Sequence number: 0 (relative sequence number)
Header length: 32 bytes
Flags: 0x02 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0x8bcc [correct]
Options: (12 bytes)
No. Time Source Destination Protocol Info
29 1010.155381 192.168.1.95 192.168.1.93 TCP 8563 > vfo [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=8
Frame 29 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: AskeyCom_28:aa:67 (00:1b:9e:28:aa:67), Dst: MS-NLB-PhysServer-17_09:03:0c:34 (02:11:09:03:0c:34)
Internet Protocol, Src: 192.168.1.95 (192.168.1.95), Dst: 192.168.1.93 (192.168.1.93)
Transmission Control Protocol, Src Port: 8563 (8563), Dst Port: vfo (1056), Seq: 0, Ack: 1, Len: 0
Source port: 8563 (8563)
Destination port: vfo (1056)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 32 bytes
Flags: 0x12 (SYN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 8192
Checksum: 0xbeb8 [correct]
Options: (12 bytes)
[SEQ/ACK analysis]
No. Time Source Destination Protocol Info
30 1010.156775 192.168.1.93 192.168.1.95 TCP vfo > 8563 [RST] Seq=1 Win=0 Len=0
Frame 30 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: MS-NLB-PhysServer-17_09:03:0c:34 (02:11:09:03:0c:34), Dst: AskeyCom_28:aa:67 (00:1b:9e:28:aa:67)
Internet Protocol, Src: 192.168.1.93 (192.168.1.93), Dst: 192.168.1.95 (192.168.1.95)
Transmission Control Protocol, Src Port: vfo (1056), Dst Port: 8563 (8563), Seq: 1, Len: 0
Source port: vfo (1056)
Destination port: 8563 (8563)
Sequence number: 1 (relative sequence number)
Acknowledgment number: Broken TCP. The acknowledge field is nonzero while the ACK flag is not set
Header length: 20 bytes
Flags: 0x04 (RST)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .1.. = Reset: Set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 0
Checksum: 0x9222 [correct]
Every time I run this, I get three packets with the last one being a reset (RST). But I can telnet port 8563 to the debugger and see the packets go back and forth and no resets.
Maybe someone can makes heads-or-tails of this. I'm not a network expert, just a simple computer programmer.
Maybe it's just a bunch of stuff that happens. -- Homer Simpson
Your client computer (ie, the one running Oolite) is requesting a TCP connection (SYN), your Debug-Console computer acknowledges it (SYN,ACK), but then for some reason your client resets the connection (RST) instead of completing the TCP connection setup with an ACK.
Since telnetting to the Debug Console works but your Debug.OXP doesn't, I'd say something has changed on Windows (either GNUstep itself, or something weird in Vista) which is stopping the Debug.OXP from connecting.
The telnet test basically guarantees that the network setup itself is fine though.
I run some tests on my work's network last week. I can confirm that the console can talk to a different computer running Oolite over a network. I have to assume that is something related to Vista that is stopping Randy, as I was using WindowsXP on both my test systems.
Could it be related to user permissions? The accounts Oolite and console are run from are administrator ones, is that correct?
I've tried administrator permissions as well. I'm agreeing that it is probably a Vista thing. I've found websites where people have had problems getting XP and Vista to play well together. The solution supposedly is to install something on top of SP3. Unfortunately SP3 won't install and many people have had problems with that.
I won't complain about a certain company infamous for blue screens and daily "security updates".
I've got another idea though. I'll get back to you. If nothing else, other Vista users might run across this problem and maybe the information will be helpful.
Randy
Maybe it's just a bunch of stuff that happens. -- Homer Simpson
[debugTCP.disconnect]: Debug console disconnected with message Lost connection to remote debug console. Stream status: 7. Stream error: En anmodning om at sende eller modtage data blev annulleret, fordi den pågældende socket ikke er tilsluttet, og der blev ikke angivet nogen adresse (ved afsendelsen på en datagram-socket vha. et sendto-kald).
I was connecting from a Laptop with Vista Home Premium to Vista Ultimate.
So the culprit does indeed seem to be Vista...
EDIT: maybe something entirely different.. I shut down the console.. and I am still getting the same error :S
I'm not at all even sure that there is connection between the two vista systems in regard to the console and Oolite
Last Sunday I wrote a quick program to see if I could intercept it. Well, port 8563 gave me the same results as the console. So changed it to port 999 and changed the configuration in the OXP to match and I had something interesting happen. The data flowed back and forth. The server code was programmed to simply send ":listM" regardless of what came through. The data that came through wasn't what I expected but it was some kind of pure text.
It only happened once. Afterward, I'm right back to the same results in WireShark. I've tried several different ports and nothing new.
I just thought I'd mention that something clicked but I don't know what and I can't reproduce the results thus far.
Randy
Maybe it's just a bunch of stuff that happens. -- Homer Simpson
I changed the IP to the IP of my own machine.. instead of the "loop back" IP known as 127.0.0.1
So I set console-host to 192.168.1.207
left the port on 8563,
and it connected.... I then altered the port setting... 15000, opened it in the routers firewall...
no connection...
I then tried with
console-host 127.0.0.1 (this don't even make it to the router) since it is what i believe is called a loop back IP...
No connection..
So you should not touch the port setting at all, under any circumstances..
now.
When I use the same machine, and use its local network specific ip4 address, it connects fine... however, When I use a different machine like the XP laptop, or the Vista Home Premium laptop (i have two), then it will not work.. which leads me to suspect that this indeed is a security setting in Vista... I have UAC disabled on both Vista Machines (warning this deletes user specific cookies, when altered)
Knowing this, ill try to figure out the correct security setting for the Oolite to connect to the console later...
Cheers Frame...
Edit changing the Port on the XP system, will cause it to fail the connect, the console seems to be expecting usage of port 8563.. and i have not found anywhere how to change that..
however, as someone here said, it should matter...
If you're going to change the port you need to do it both in the OXP config.plist file as well as the debug console - the latter of which you can only do if you run the python version, not the pre-built .exe (I think).
