d***@kixeye.com
2016-01-28 00:37:32 UTC
The following is a direct copy and paste from a ssh terminal session from the machine demonstrating the problem.
OS is Ubuntu LTS 12.04
--- cut here --- cut here ---
[DEV] root@<*****>:/<*****># tshark -i eth1 port 843
tshark: Lua: Error during loading:
[string "/usr/share/wireshark/init.lua"]:45: dofile has been disabled
Running as user "root" and group "root". This could be dangerous.
Capturing on eth1
0.000000 38.99.56.154 -> 169.54.34.176 TCP 66 58344 > 843 [SYN] Seq=0 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1
0.000044 169.54.34.176 -> 38.99.56.154 TCP 54 843 > 58344 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
0.663137 38.99.56.154 -> 169.54.34.176 TCP 66 [TCP Port numbers reused] 58344 > 843 [SYN] Seq=0 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1
0.663181 169.54.34.176 -> 38.99.56.154 TCP 54 843 > 58344 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
1.263222 38.99.56.154 -> 169.54.34.176 TCP 62 [TCP Port numbers reused] 58344 > 843 [SYN] Seq=0 Win=8192 Len=0 MSS=1380 SACK_PERM=1
1.263269 169.54.34.176 -> 38.99.56.154 TCP 54 843 > 58344 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
^C6 packets captured
[DEV] root@<*****>:/<*****># netstat -n -l -p | grep 843
tcp 0 0 169.54.34.176:843 0.0.0.0:* LISTEN 459/BattleServer
--- cut here --- cut here ---
This is somewhat backwards, but the single line output from netstat says to me that pid 459, BattleServer is listening on port 843. This is for the benefit of a Flash client that will attempt to connect there to get a cross domain policy file.
The upper section is the result of a client trying to connect, all three SYN packets have 169.54.34.176:843 as the destination ip/port, which matches the LISTEN line, and yet the response is RST, ACK, not SYN, ACK.
I'm completely at a loss as to why this might be happening, but needless to say, things go downhill quite rapidly from here.
OS is Ubuntu LTS 12.04
--- cut here --- cut here ---
[DEV] root@<*****>:/<*****># tshark -i eth1 port 843
tshark: Lua: Error during loading:
[string "/usr/share/wireshark/init.lua"]:45: dofile has been disabled
Running as user "root" and group "root". This could be dangerous.
Capturing on eth1
0.000000 38.99.56.154 -> 169.54.34.176 TCP 66 58344 > 843 [SYN] Seq=0 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1
0.000044 169.54.34.176 -> 38.99.56.154 TCP 54 843 > 58344 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
0.663137 38.99.56.154 -> 169.54.34.176 TCP 66 [TCP Port numbers reused] 58344 > 843 [SYN] Seq=0 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1
0.663181 169.54.34.176 -> 38.99.56.154 TCP 54 843 > 58344 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
1.263222 38.99.56.154 -> 169.54.34.176 TCP 62 [TCP Port numbers reused] 58344 > 843 [SYN] Seq=0 Win=8192 Len=0 MSS=1380 SACK_PERM=1
1.263269 169.54.34.176 -> 38.99.56.154 TCP 54 843 > 58344 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
^C6 packets captured
[DEV] root@<*****>:/<*****># netstat -n -l -p | grep 843
tcp 0 0 169.54.34.176:843 0.0.0.0:* LISTEN 459/BattleServer
--- cut here --- cut here ---
This is somewhat backwards, but the single line output from netstat says to me that pid 459, BattleServer is listening on port 843. This is for the benefit of a Flash client that will attempt to connect there to get a cross domain policy file.
The upper section is the result of a client trying to connect, all three SYN packets have 169.54.34.176:843 as the destination ip/port, which matches the LISTEN line, and yet the response is RST, ACK, not SYN, ACK.
I'm completely at a loss as to why this might be happening, but needless to say, things go downhill quite rapidly from here.