If you have a Sony Ericsson Elm J10i2 phone (the issue probably applies to other models as well) and you’re trying to watch YouTube videos via your home WiFi while accessing the Internet through a TP-LINK router, it probably won’t work. The TP-LINK TL-WR541G V4 (probably other models as well) performs NAT in a way that makes it impossible for the RTSP protocol, which is used for streaming YouTube videos on some Sony Ericsson phones (the Android app uses HTTP), to work.
In an RTSP transaction, application layer data must be consistent with UDP headers (transport layer) of generated traffic. A similar mechanism is used by the FTP protocol (though in its case we’re talking about TCP). In particular it’s all about the Transport RTSP header. The client can use it to define the range of source ports from which the server should expect connections. Most reasonable routers (e.g. Cisco or routers with Linux-based firmware) attempt to preserve source ports while performing NAT. Meanwhile, TP-LINK routers (at least some of them) change source port numbers during address translation. As a result, the client sends a message to the server stating that it should expect connections e.g. from port 12345 (and it generates such traffic) but right after crossing the router that traffic is already sourced e.g. from port 1234. Therefore the traffic is blocked by the server and the connection isn’t established. And that’s about it for watching Nyan Cat at bedtime.
Unfortunately, no TP-LINK firmware update has solved the problem. The only solution is to use a different device on Internet edge.
As a proof I’m attaching two PCAP files (10.79.1.62 is TP-LINK router’s “public” address – ISP performs “actual” NAT to globally routable addresses):
- youtube-tplink.pcap – filtered traffic exchanged between a TP-LINK router and a YouTube server after a connection is initiated by the phone application (compare parameters declared by the client in packets #11 and #13 with source ports in UDP datagrams #16 and #17),
- youtube-linux.pcap – filtered traffic exchange between a Linux-based router and a YouTube server after a connection is initiated by the phone application (parameters declared by the client in packets #11 and #14 match source ports in UDP datagrams #18 and #19).