Debug Console

For test results, bug reports, announcements of new builds etc.

Moderators: winston, another_commander, Getafix

User avatar
Randy
Competent
Competent
Posts: 34
Joined: Fri Mar 27, 2009 5:00 pm
Location: Wherever I am, I'm there.
Contact:

A Status Update

Post by Randy » Sun Apr 12, 2009 1:20 am

Hi all,

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.

Code: Select all

[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

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5400
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander » Sun Apr 12, 2009 2:25 pm

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.]

User avatar
Randy
Competent
Competent
Posts: 34
Joined: Fri Mar 27, 2009 5:00 pm
Location: Wherever I am, I'm there.
Contact:

What I know so far

Post by Randy » Sun Apr 12, 2009 4:37 pm

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

User avatar
Micha
Commodore
Commodore
Posts: 815
Joined: Tue Sep 02, 2008 2:01 pm
Location: London, UK
Contact:

Post by Micha » Sun Apr 12, 2009 9:28 pm

you can use wireshark to look at the packets on the network
The glass is twice as big as it needs to be.

User avatar
DaddyHoggy
Intergalactic Spam Assassin
Intergalactic Spam Assassin
Posts: 8501
Joined: Tue Dec 05, 2006 9:43 pm
Location: Newbury, UK
Contact:

Post by DaddyHoggy » Sun Apr 12, 2009 11:07 pm

Yup, that was what I was going to recommend!
Selezen wrote:Apparently I was having a DaddyHoggy moment.
Oolite Life is now revealed here

User avatar
Randy
Competent
Competent
Posts: 34
Joined: Fri Mar 27, 2009 5:00 pm
Location: Wherever I am, I'm there.
Contact:

Results from WireShark

Post by Randy » Sat Apr 18, 2009 7:35 pm

Code: Select all

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. 8)
Maybe it's just a bunch of stuff that happens. -- Homer Simpson

User avatar
Micha
Commodore
Commodore
Posts: 815
Joined: Tue Sep 02, 2008 2:01 pm
Location: London, UK
Contact:

Post by Micha » Sat Apr 18, 2009 8:36 pm

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.
The glass is twice as big as it needs to be.

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5400
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander » Sat Apr 18, 2009 8:44 pm

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?

User avatar
Randy
Competent
Competent
Posts: 34
Joined: Fri Mar 27, 2009 5:00 pm
Location: Wherever I am, I'm there.
Contact:

Tried the Administration

Post by Randy » Sat Apr 18, 2009 9:49 pm

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

User avatar
Micha
Commodore
Commodore
Posts: 815
Joined: Tue Sep 02, 2008 2:01 pm
Location: London, UK
Contact:

Post by Micha » Mon Apr 20, 2009 5:59 pm

Interesting.
Stepping through the code in a debugger, it connects fine.
Running the same code outside the debugger, same problem as Randy.

Possibly something timing-related on Vista?


(Ps. this was Oolite compiled using the 0.22 GNUstep package on Vista)
The glass is twice as big as it needs to be.

User avatar
Frame
---- E L I T E ----
---- E L I T E ----
Posts: 1474
Joined: Fri Mar 30, 2007 8:32 am
Location: Witchspace

Post by Frame » Tue Apr 21, 2009 2:22 pm

Trying on two vista systems,

Oolite 1.72.2 will not connect either, getting the same message in the log (all though in danish for some reason)

Code: Select all

[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
Bounty Scanner
Number 935

User avatar
Micha
Commodore
Commodore
Posts: 815
Joined: Tue Sep 02, 2008 2:01 pm
Location: London, UK
Contact:

Post by Micha » Tue Apr 21, 2009 3:45 pm

In my test environment I was definitely seeing packets go between the machines (wireshark running on both).
The glass is twice as big as it needs to be.

User avatar
Randy
Competent
Competent
Posts: 34
Joined: Fri Mar 27, 2009 5:00 pm
Location: Wherever I am, I'm there.
Contact:

It's Weird But...

Post by Randy » Tue Apr 21, 2009 11:29 pm

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

User avatar
Frame
---- E L I T E ----
---- E L I T E ----
Posts: 1474
Joined: Fri Mar 30, 2007 8:32 am
Location: Witchspace

Post by Frame » Fri Apr 24, 2009 12:40 pm

I did something else


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...
Bounty Scanner
Number 935

User avatar
Micha
Commodore
Commodore
Posts: 815
Joined: Tue Sep 02, 2008 2:01 pm
Location: London, UK
Contact:

Post by Micha » Fri Apr 24, 2009 7:49 pm

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).
The glass is twice as big as it needs to be.

Post Reply