I’ve found this post on Sony’s user support forum. It seems that other expirience this problem as well, and found solution on Juniper’s SSG5… Any RouterOs guru that can point out how to solve this on ROuteros ?
Here is the message taken from Sony’s board:
So I finally figured it out yesterday, though I’m not sure why the behavior changed. After swapping through two firewalls (a Juniper SSG5 and SRX210) without a change, I decided to bypass my Internet provider and tether the Dash to my phone. Lo-and-behold, I was able to get my Dash connected to the Sony infrastructure behind ssm.internet.sony.tv when tethered to my phone!
So I ran a little test. I tried to connect to ssm.internet.sony.tv from my laptop using both my ISP and my phone, and I took Wireshark traces of both. When I tried via my home ISP, the browser session never connected and eventually timed out. When I tried with my latop tethered to my phone, I got a fairly immediate “Bad Gateway” response from Sony. That sure sounds like a successful TCP and HTTP setup!
Now to the Wireshark traces. (You can find the Dash via ISP here, and laptop via phone here, if you want to follow along.) Frames 1-3 in the Dash trace show the TCP 3-way handshake, as do frames 1, 3, 4 in the laptop trace. The key is the [SYN,ACK] packet from the web server (frame 2 in the Dash trace, frame 3 in the laptop trace). When I was connected via my ISP, the [SYN,ACK] packet shows a window size value of 0, while the [SYN,ACK] packet received via my mobile shows a value of 5512. So why the difference?
I did some reading about how firewalls proxy the TCP 3-way handshake, and I found that common practice is to set the Window = 0 in the [SYN,ACK] packet while the firewall brokers the connection on each end. Once the firewall has completed the 3-way handshake in both directions (firewall to client, and firewall to server), it then sends an ACK to the session initiator (the host who received the Window = 0 message) with an appropriate value to open the connection to traffic flow. So now I knew that (a) my firewall, or rather both of my firewalls were proxying the 3-way handshake, (b) for whatever reason, the Window was never being opened up, and (c) the Window = 0 in the [SYN,ACK] packet, in the absence of an ACK that opens the window, was preventing my Dash from issuing any commands to pull data from Sony.
Solving (a) was relatively easy; I simply configured my firewall to stop proxying the 3-way handshake (“unset flow tcp-syn-check” and “set flow no-tcp-seq-check” on mt SSG5). Disabling the 3-way handshake proxy on my firewall solved (c), as both Dash’s are now operational again.
That leaves only (b), and the obvious question, “What changed?” The boxes simply stopped working one day, on the same day. I made no changes to my firewall that day, or recently, and no one else has management access to my firewall. (It’s my own personal firewall, not the ISP’s firewall.) Furthermore, the TCP proxy functionality is the default (and preferred) behavior for my firewall. So either Verizon instituted some new NAT/firewall capability as part of FiOS last week, or Sony made some change to their firewall/backend system that broke a behavior that has worked flawlessly for the past four years. I’m not sure which it was, or how I would ever find out, but I’d much like to turn the TCP proxy back on and still be able to use my Dash.
– Greg
Any clue hot to disable this TCP SYN check on RouterOs ?
please if anyone can help ?