[0.13.20] [Oxyd] RCON always times out

[riking]

I am starting the server with these parameters:

bin/x64/factorio --start-server saves/mpmap.zip --rcon-port 33197 --rcon-password dcxxxxxxxxc6

And the startup log says it started the RCON server:

Code: Select all

  11.361 Info PosixUDPSocket.cpp:50: Opening socket at port 34197
  11.361 Info Router.cpp:594: Router state -> Connected
  11.361 Info Synchronizer.cpp:56: NetworkTick(0) initialized Synchronizer local peer(0) latency(6).
  11.362 Hosting game at port 34197, peerID 0, session magic 1799
  11.362 Info HttpSharedState.cpp:44: Downloading https://auth.factorio.com/generate-server-padlock
  11.918 Info HttpSharedState.cpp:108: Status code: 200
  11.919 Info AuthServerConnector.cpp:106: Obtained serverPadlock for serverHash (kiRMcwmVxeuyUNlQwiJBj8qlBnKtLScW) from the auth server.
  11.919 Info MultiplayerManager.cpp:1000: networkTick(0) mapTick(6900673) changing state from(CreatingGame) to(InGame)
  11.919 Info NetworkInputHandler.cpp:45: mapTick(6900673) networkTick(0) initialized NetworkInputHandler local peer(0).
  11.920 Info RemoteCommandProcessor.cpp:94: Starting RCON interface at port 33197

netstat says it's listening:

Code: Select all

# netstat -tulpn | grep factorio
tcp        0      0 0.0.0.0:33197           0.0.0.0:*               LISTEN      32206/factorio  
udp        0      0 0.0.0.0:34197           0.0.0.0:*                           32206/factorio  
udp6       0      0 :::34197                :::*                                32206/factorio  

But when I try to connect to it, it always fails:

Code: Select all

	conn, err := net.DialTimeout("tcp", address, 2*time.Second)
	if err != nil {
		return nil, err
	}

connecting to rcon: dial tcp 127.0.0.1:33197: i/o timeout

Reading the forum, people clearly have RCON working on 0.13.6. Am I doing something wrong, or is this a regression?

Also that RCON isn't listening on the ipv6 localhost, which is definitely a bug.

* This is also happening on 0.14.7

[Ratzap]

I have RCON working fine on 0.14.7 running on a windows host

[Oxyd]

Does this also happen on 0.14.8?

[credomane]

connecting to rcon: dial tcp 127.0.0.1:33197: i/o timeout

Out of curiousity your Factorio server and the computer you are running the rcon go program from are the same computer right?

[riking]

> Out of curiousity your Factorio server and the computer you are running the rcon go program from are the same computer right?

Of course; if the server isn't running I get "connection refused" instead.

I'll test with 0.14.8 now.
edit: tested on 0.14.9, still seems to be timing out :/ I'm so confused.

Here's the code I'm using:

Code: Select all

func (m *factoriodata) pingServer() error {
        c, err := rcon.DialTimeout("127.0.0.1", m.PortNumber()+RCON_PORT_OFFSET, RconPassword(), 1*time.Second)
        if err != nil {
                return errors.Wrap(err, "connecting to rcon")
        }
        resp, err := c.Command("/c print 'hello'")
        if err != nil {
                return errors.Wrap(err, "executing command")
        }
        fmt.Println(resp)
        m.RconDebug = resp
        return nil
}

and that chains to a simple net.DialTimeout, proto=tcp, as specified here https://godoc.org/net#DialTimeout

[credomane]

Where is rcon.DialTimeout coming from? Is that a package of some sort?

The DialTimeout I know of works like your previous example of

Code: Select all

net.DialTimeout("tcp", address, 2*time.Second)

Now your second example shows a different version

Code: Select all

rcon.DialTimeout("127.0.0.1", m.PortNumber()+RCON_PORT_OFFSET, RconPassword(), 1*time.Second)

[riking]

Okay, so the code is here: https://github.com/riking/homeapi

rcon is a vendored package because I needed to make a few edits. Look at factorio.go and rcon/rcon.go.

I just swapped the net.Dial to use "tcp4" instead of "tcp", but it didn't help.

Before Factorio binds to the port, this is the error message:

Code: Select all

connecting to rcon: dial tcp4 127.0.0.1:33197: getsockopt: connection refused

After, it's this:

Code: Select all

 connecting to rcon: dial tcp4 127.0.0.1:33197: i/o timeout

The command line is:

Code: Select all

bin/x64/factorio --start-server "saves/$MAP_NAME.zip" --rcon-port "33197" --rcon-password "$RCON_PASSWD"

[RobertHamblin]

Posted by spammer. Not deleted to keep the sense of the follow-up. -- ßilk

It gets timed out every often.Let me try the above code.Thanks!

[Oxyd]

Does it also timeout if you try with some other client, such as mcrcon?

[riking]

Does it also timeout if you try with some other client, such as mcrcon?

Yep:
$ time ./mcrcon -H 127.0.0.1 -P 33197 -p XXXXXX '/c print "hello"'
^C
real 0m7.537s
user 0m0.000s
sys 0m0.000s

Maybe it's something about my server?
-------
OKAY, FOUND IT (? maybe?)

strace reveals that it's never calling accept().

We can see that the server calls bind() for port 33197, and calls listen() - which registers the server for listening on that port - but accept() is never called, the system call that actually connects the two sides of the network connection.



edit: i'm not seeing any accept() calls for normal player connections, and those clearly work.. do I need to trace child processes?
Edit 2: listen() is /NOT/ called for the normal player connection socket.
Edit 3: Duh. Of course.

Player connections are UDP. So of course no accept() call is necessary. As you can see in the first post of the thread....

RCON is TCP, so accept() is needed to establish a file descriptor for the connection.

[riking]

For more background info, here's what a successful "waiting for TCP connection" strace looks like:

Code: Select all

$ strace nc -l 1234
.... blah blah blah pre-main() garbage....
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 1)                            = 0
accept(3, ^Cstrace: Process 17350 detached
 <detached ...>

[credomane]

It has got to be something with your linux server itself. I tested on my linux box and I could talk just fine over rcon. 0.13.20, 0.14.7 and 0.14.9 all worked for me.

I tested connecting from a different station from both the 127.x.x.x interface and from the other ip on the box. Rcon worked everytime. Localhost itself is the only one that didn't work as expected since that opens a unix socket not a tcp socket.

Running Debian GNU/Linux 8.5 (jessie) on Debian kernel 3.16.7-ckt25-2.

[Oxyd]

strace reveals that it's never calling accept().

Did you run strace -f? Without -f, you won't see anything from the thread where the accept call is done.

Also, you're on OSX, is that right?

Localhost itself is the only one that didn't work as expected since that opens a unix socket not a tcp socket.

You mean Factorio opens a Unix socket?

[riking]

Did you run strace -f? Without -f, you won't see anything from the thread where the accept call is done.

Also, you're on OSX, is that right?

Yeah, I ran strace -ff (places each thread in its own output file) and grepped all of them :/

My most recent client is on OSX, yeah. Server info:

Code: Select all

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.1 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.1 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
UBUNTU_CODENAME=xenial

iptables is empty. Any other information about the server that could help figure this out?

[credomane]

You mean Factorio opens a Unix socket?

I was talking about when I used rcon to connect to Factorio over "localhost". On Linux that is bit of a "special" name. Many programs will try to connect to a Unix socket when they see localhost instead of resolving it through the internel DNS (which becomes 172.0.0.1).

Since Factorio doesn't create a unix socket then naturally trying to rcon to factorio over a unix socket fails as expected.

[Oxyd]

Did you run strace -f? Without -f, you won't see anything from the thread where the accept call is done.

Yeah, I ran strace -ff (places each thread in its own output file) and grepped all of them :/

It sounds like the connection never reaches Factorio for some reason. Could you run strace -e trace=socket,bind,listen,accept,select -f ./bin/x64/factorio --start-server saves/mpmap.zip --rcon-port 33197 --rcon-password dcxxxxxxxxc6, attempt an RCON connection and post the complete strace result here?

Though this is starting to sound like some server issue and not a Factorio issue. Especially since you seem to be the only one having this problem. If someone else is having this problem, definitely let us know.

[computerdruid]

For what it's worth, this sounds like a firewall configured to drop packets, but I wouldn't expect a firewall to apply to localhost connections.

[riking]

Yep, definitely a server issue. I rebuilt the box for an unrelated reason and the problem no longer occurs.

However, I have a different issue now...