So my Sony Blu-Ray player can't play Netflix today. Wonder why? Well it's not Netflix, that works great on my PC. And my iPhone and my Wii. tcpdump to the rescue!
That's all fine an dandy if my DD-WRT device was my router instead of just an AP, I'd have to mount a CIFS share and download a package in order to do a tcpdump.
Instead, I've got a hand-me-down Juniper with ScreenOS. Not being intimately familiar, I did recall it had some equivalent facilities if using the CLI, so without further ado, here's a cheat sheet for working with snoop:
ssg-> clear dbuf
ssg-> snoop info
Snoop: OFF
Filters Defined: 1, Active Filters 1
Detail: ON, Detail Display length: 96
Snoop tunnel traffic: ON
Snoop filter based on:
id 1(on): IP src-ip 172.16.37.101 dir(B)
ssg-> snoop filter ip src-ip 172.16.37.100 direction both
snoop filter added
ssg-> snoop
Start Snoop, type ESC or 'snoop off' to stop, continue? [y]/n y
clear dbuf clears the in memory buffer, then snoop info shows the current snoop state. Then I use a filter to just watch one device, so I can determine what destination IPs are involved. Later, we can re-run with a different filter to get a better sampling.
I did a quick telnet test to www.google.com then stopped the snoop trace.
ssg-> snoop off
Snoop off
To view the trace, we send the dbuf to stream output and page through results. If you're using a more detailed filter it will decode unencrypted HTTP requests a bit more.
ssg-> get dbuf stream91638.0: bgroup0(i) len=74:0019d28739e8->001db5ba738b/0800
172.16.37.100 -> 8.8.8.8/17
vhl=45, tos=00, id=2844, frag=0000, ttl=128 tlen=60
udp:ports 56461->53, len=40
00 1d b5 ba 73 8b 00 19 d2 87 39 e8 08 00 45 00 ....s.....9...E.
00 3c 0b 1c 00 00 80 11 4e 11 ac 10 25 64 08 08 .<......N...%d..
08 08 dc 8d 00 35 00 28 51 91 61 1e 01 00 00 01 .....5.(Q.a.....
00 00 00 00 00 00 03 77 77 77 06 67 6f 6f 67 6c .......www.googl
65 03 63 6f 6d 00 00 01 00 01 e.com.....
91638.0: bgroup0(i) len=66:0019d28739e8->001db5ba738b/0800
172.16.37.100 -> 173.194.33.17/6
vhl=45, tos=00, id=2845, frag=4000, ttl=128 tlen=52
tcp:ports 49295->80, seq=787237732, ack=0, flag=8002/SYN
00 1d b5 ba 73 8b 00 19 d2 87 39 e8 08 00 45 00 ....s.....9...E.
00 34 0b 1d 40 00 80 06 4f 5f ac 10 25 64 ad c2 .4..@...O_..%d..
21 11 c0 8f 00 50 2e ec 4b 64 00 00 00 00 80 02 !....P..Kd......
20 00 73 98 00 00 02 04 05 b4 01 03 03 08 01 01 ..s.............
04 02 ..
91638.0: bgroup0(i) len=60:0019d28739e8->001db5ba738b/0800
172.16.37.100 -> 173.194.33.17/6
vhl=45, tos=00, id=2846, frag=4000, ttl=128 tlen=40
tcp:ports 49295->80, seq=787237733, ack=1688811284, flag=5010/ACK
00 1d b5 ba 73 8b 00 19 d2 87 39 e8 08 00 45 00 ....s.....9...E.
00 28 0b 1e 40 00 80 06 4f 6a ac 10 25 64 ad c2 .(..@...Oj..%d..
21 11 c0 8f 00 50 2e ec 4b 65 64 a9 37 14 50 10 !....P..Ked.7.P.
00 43 38 5b 00 00 00 00 b7 3d 3e 89 .C8[.....=>.
91641.0: bgroup0(i) len=60:0019d28739e8->001db5ba738b/0800
172.16.37.100 -> 173.194.33.17/6
ssg-> snoop filter delete
All filters removed
ssg-> clear dbuf
ssg->
Lastly, I drop my filter and clear the in memory buffer to clean up.
Later I facilitated this with a filter between my device and the device provisioning service over at Sony to determine why my Blu-Ray player couldn't play Netflix. Sure enough, the device makes a connection to ssm1.internet.sony.tv and does a GET for /BDP/stv/STVgetTime/ and gets an HTTP 404 response. Using IE10's F12 Developer Tools, I captured the response header and confirmed it's an Apache host. Beyond that reverse lookup tricks and tracert didn't tell me much.
For fun, I also tested the Slacker radio plugin, and it fails hitting a similar host, ssm.internet.sony.tv and ssm2.internet.sony.tv, but there were also some exciting UDP packets going by on 1900.
So after contacting Sony support, I was directed to call their support team as my issue couldn't be solved on chat. I feel sorry for the CS agent I spoke with because their first reaction after demonstrating my case was to use an HDMI cable instead. So much for the OSI model. This really points at how DRM can affect customer experience, especially if it's something the hardware vendor tacked on to their device on top of a 3rd party service that doesn't require it for other devices. Even though I was (and still am) a PlayStation 3 fanboy, I'm having second thoughts about Sony devices.
I watched Netflix on Wii today. Because it just worked.
Friday, July 19, 2013
Wednesday, May 22, 2013
Troubleshooting 101: The Power of netstat
I was reading up on ETW, and discovered the TCPView tool. Having recently worked with the joys of ip_conntrack on Linux hosts with iptables and bad PHP frameworks leaving TCP sessions in TIME_WAIT, this was a nice find for Windows.
But in reviewing this article, its curious that Microsoft doesn't demonstrate the use of native OS tools to triage a simple port binding issue. So here's a quick example to help you find what's listening on TCP 80.
C:\> netstat -p TCP -on | find ":80 "
TCP 172.16.37.100:80 157.56.98.83:443 ESTABLISHED 320
This shows us a list of TCP ports with the numeric port value and the PID.
C:\> tasklist /FI "PID eq 320"
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
w3wp.exe 320 Services 0 99,344 K
Pass the PID in a predicate filter to tasklist, and we find the process name. Since it's an IIS worker process, we must go a step further to identify the Application Pool:
C:\> %windir%\system32\inetsrv\appcmd.exe list wp
WP "320" (applicationPool:WsusPool)
Another great feature of netstat is it's statistics feature, which a peer pointed out to me:
C:> netstat -s
It's left as an exercise to the reader to peruse the value that single command can have in troubleshooting down the stack before you worry about data link and the physical layer. You've already swapped out that crossover cable for a regular patch, right?
But in reviewing this article, its curious that Microsoft doesn't demonstrate the use of native OS tools to triage a simple port binding issue. So here's a quick example to help you find what's listening on TCP 80.
C:\> netstat -p TCP -on | find ":80 "
TCP 172.16.37.100:80 157.56.98.83:443 ESTABLISHED 320
This shows us a list of TCP ports with the numeric port value and the PID.
C:\> tasklist /FI "PID eq 320"
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
w3wp.exe 320 Services 0 99,344 K
Pass the PID in a predicate filter to tasklist, and we find the process name. Since it's an IIS worker process, we must go a step further to identify the Application Pool:
C:\> %windir%\system32\inetsrv\appcmd.exe list wp
WP "320" (applicationPool:WsusPool)
Another great feature of netstat is it's statistics feature, which a peer pointed out to me:
C:> netstat -s
It's left as an exercise to the reader to peruse the value that single command can have in troubleshooting down the stack before you worry about data link and the physical layer. You've already swapped out that crossover cable for a regular patch, right?
Sunday, April 7, 2013
Now on IPv6!
On a whim, I configured CloudFlare today. Then happily discovered, it helps my site go into the future, and not just faster, but also with IPv6. On a side note, since they'll be handling my name servers for the purposes as a CDN, I can eliminate my name server hosting costs, saving $12/year, unless I put those $12 towards premium features as the site grows.
Looking at their apps, I found Blitz.io, which is a sweet simple load-testing service. After testing it out a bit, I misspelled Brazil, and found this fun fact:
Hm, those regional mappings seem very familiar. Quick to the bat-lookup (or bat-dig, your preference):
C:\>nslookup www.blitz.io
Server: google-public-dns-b.google.com
Address: 8.8.4.4
Non-authoritative answer:
Name: elb014717-1106725811.us-east-1.elb.amazonaws.com
Addresses: 54.243.112.187
54.243.77.105
54.243.229.217
Aliases: www.blitz.io
mie-8036.herokussl.com
Ha, I thought so. It looks like they're using Heroku, who's a well know user of AWS.
When I first ran the query, I mistakenly specified the apex zone:
C:\>nslookup blitz.io
Server: google-public-dns-b.google.com
Address: 8.8.4.4
Non-authoritative answer:
Name: blitz.io
Address: 50.31.209.229
They aren't using the ELB in their apex zone. I happen to know that feature is an AWS specific implementation of Route 53. So let's check name servers:
C:\>nslookup -q=ns blitz.io
Server: google-public-dns-b.google.com
Address: 8.8.4.4
Non-authoritative answer:
blitz.io nameserver = ns4.dnsimple.com
blitz.io nameserver = ns2.dnsimple.com
blitz.io nameserver = ns3.dnsimple.com
blitz.io nameserver = ns1.dnsimple.com
Yup, they're using name servers elsewhere. But why not use CloudFlare for the optimizations? Perhaps its something that only their engineers can answer.
But wait, there's more!
Looking at their apps, I found Blitz.io, which is a sweet simple load-testing service. After testing it out a bit, I misspelled Brazil, and found this fun fact:
 |
| "s" isn't just British anymore |
C:\>nslookup www.blitz.io
Server: google-public-dns-b.google.com
Address: 8.8.4.4
Non-authoritative answer:
Name: elb014717-1106725811.us-east-1.elb.amazonaws.com
Addresses: 54.243.112.187
54.243.77.105
54.243.229.217
Aliases: www.blitz.io
mie-8036.herokussl.com
Ha, I thought so. It looks like they're using Heroku, who's a well know user of AWS.
That's not all, Bob. Tell 'em what they've won!
When I first ran the query, I mistakenly specified the apex zone:
C:\>nslookup blitz.io
Server: google-public-dns-b.google.com
Address: 8.8.4.4
Non-authoritative answer:
Name: blitz.io
Address: 50.31.209.229
They aren't using the ELB in their apex zone. I happen to know that feature is an AWS specific implementation of Route 53. So let's check name servers:
C:\>nslookup -q=ns blitz.io
Server: google-public-dns-b.google.com
Address: 8.8.4.4
Non-authoritative answer:
blitz.io nameserver = ns4.dnsimple.com
blitz.io nameserver = ns2.dnsimple.com
blitz.io nameserver = ns3.dnsimple.com
blitz.io nameserver = ns1.dnsimple.com
Yup, they're using name servers elsewhere. But why not use CloudFlare for the optimizations? Perhaps its something that only their engineers can answer.
Subscribe to:
Posts (Atom)