hi guys, for about a month my tv's youtube app stopped working.(thumbs and videos descriptions are loading but video can not start playing). Youtube on PC works good. When I change ISP for my backup one (low speed and transfer) everything works like a charm. The primary ISP says that everything is OK with my connection. I think i could run wireshark on primary and backup ISP,and then could see what is the difference, but have no Idea how to do it in wireshark . Any suggestions? I Can have a ubuntu laptop with wireshark as a router , or should I use windows version but windows PC wouldn't be a router then. asked 26 Feb '16, 11:50  Stanisław Ła... |
One Answer:
As for "how to capture", a But I'm afraid you'll have a tough time "seeing what is the difference" because if the TV accesses Youtube using https, you'll be unable to get the pre-master TLS key from it, making it impossible for you to see what goes wrong if it goes wrong after the TLS session establishment. If you are "lucky", the TV will attempt to establish a new TCP connection for the video and its SYN packet will not be ever responded due to some routing error between Google's video server and your primary connection's public IP; if you are "not lucky", the issue will be invisible because either an existing TLS session will be re-used or a new one established successfully, and Google will refuse to send the stream requested (possibly based on some IP ranges' blacklist) but you'll be unable to see the request and response as they'll be encrypted. answered 26 Feb '16, 14:07  sindy edited 26 Feb '16, 14:08 |
Thanks a lot for your help. I've made a wireshark dump for those 2 scenarios. I would appreciate if you could take a look at those files. http://we.tl/kIcqcEpjdm Stan
Not much to see there about the reason.
Try to apply a display filter
(tcp and ip.addr == 46.134.194.15) or (dns.a == 46.134.194.15)in both captures. You shall see thatthe TV sends a DNS query for the same fqdn to be resolved to an IP address in both cases, and the DNS answer contains the same IP address in both cases
the TV then opens two TLS sessions towards that IP's TCP port 443 simultaneously (don't ask me why it does so, the data volume is approximately similar for both streams so it cannot be that e.g. one is the complete AV stream and the other one is an additional sound track in a different language)
The difference between the two captures is that in the successful one, the TLS handshake in both streams succeeds and the TCP session continues, while in the failing case the seq and ack numbers show that the server has not received the response of the TV to the Change Cipher Spec (btw it has a different size than in the successful case) and since then the server doesn't send anything else (which is quite logical as the cipher negotiation has probably failed).
There is a difference in the establishment phase of the TCP sessions, though. In the working case, the MSS received in the SYN,ACK packet from the video server says 1220 bytes, while in the failing case, it says 1460 bytes. So there may be an MTU handling issue in the primary providers' network or the CPE you use to connect to it.
Have a look at this link and search for the TCPMSS target (capital letters), read the associated explanation, and then try to
--set-mssto set some value like 1000 for the start on the ubuntu machine used as router, so that you could confirm or deny the theory. If it helps, you may talk to your primary ISP about the issue, or replace the ubuntu laptop by some other box as a permanent workaround.