X2Go Bug report logs - #806
connection fails with error binding localhost:XXX when creating new session

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Jason Alavaliant <alavaliant@ra09.com>

To: submit@bugs.x2go.org

Subject: connection fails with error binding localhost:XXX when creating new session

Date: Sat, 07 Mar 2015 15:28:59 +1300

Package: x2goclient
Version: 4.0.3.2
Severity: important

All clients trying to create a new sessions on my x2go broker setup 
started failing with the error message

Unable to create ssl tunnel:
Error binding localhost:XXX

and in each case the XXX was a port number lower than 1024


Digging through the client code and looking at the shared session 
database on the backend as far as I can tell the issue is;

1) the session database port numbers have reached values of 65000 and 
greater (for example on the last session I created the database gr_port 
was 65087)

2) the client gets given that data and adds 1000 to it 
(onmainwindows.cpp line "int iport=localGraphicPort.toInt() + 1000;")

3) the resulting port number is over the highest valid port number of 
65535 and hence later on when it is used the value overflows around to 
be port 552

4) ports under 1024 are reserved on Unix and can't be used by normal 
user processes and hence the error and the connection failing.


For now I've worked around the issue by patching the client 
onmainwindows.cpp section under the "int iport=localGraphicPort.toInt() 
+ 1000;" line to add to the various checks an extra check that sees in 
the value is over 65535 and if so to subtract 63382 which causes the 
port value to end up above the 1024 range.        I don't think this is 
a complete fix however since it only covers gr_port (which broke first 
since it gets 1000 added to it which doesn't seem to occur for 
sound_port and fs_port?) and I'm not sure if I what direction I should 
be looking at fixing this in order to make a patch that will be accepted 
upstream.

I'm suspecting this might actually be considered an bug with the 
x2goserver database code (it shouldn't set port so high?)   so I'm 
hoping you can advise on where I should be concentrating on fixing the 
code.       I'm not sure if you'll think it should be patched both in 
the client and in the server code   or if it should only be checked for 
in the server code?

Thanks
Jason

Message #10 received at 806@bugs.x2go.org (full text, mbox, reply):

From: Jason Alavaliant <alavaliant@ra09.com>

To: 806@bugs.x2go.org

Subject: x2goserver database problems was root cause?

Date: Mon, 09 Mar 2015 13:30:08 +1300

Further digging through my install revealed that in the database the 
used_ports   table   had 36108  entries recording every port from 30001 
up to 66109 in use.

The session table didn't have anywhere near that many sessions recorded 
as in use,    so I ran a

"delete from used_ports where session_id not in (select session_id from 
sessions);"
which removed 34683  rows from the table.

My clients are now getting ports in a much more sensible range provided 
back from the x2goserver when establishing a connection.

Reading the database creation code it looks like there should be a 
trigger deletes from used_ports when a session table row is removed so I 
think my database might have somehow failed to create that trigger on 
creation?     Still digging into exactly how the data got into the state 
it was in.

Send a report that this bug log contains spam.