Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

First of, let me apologize for this getting a bit technical. Several weeks ago, I found that while using NPR's media player (e.g. click on 'Listen to the Show' - this is what I've been using as a test) the stream would suddenly halt after a minute or three. I could not get the stream to restart without reloading the page. Now, I assumed this was an issue with NPR's player and Linux (or just a bug in their stuff in general) so I began to dig, the following is what I have tried to date (please note, the tldr; option is to skip to the latest thing as I think I know what is causing the problem).

Note: All testing has been done, for consistency purposes, on a clean install of Chromium with no pluggins running. My machine is Ubuntu 10.10x64.

  1. First thing I always try, I disabled all firewall stuff on the system (UFW, default deny all, allow ssh). No change, firewall back up for all additional tests unless otherwise noted. In any case, UFW is stateful, so connections it started on a non-specified on different ports will continue to work.
  2. I deleted my ~/.macromeda and ~/.adobe folders, restarted (just to be sure) and tried. Program still froze.
  3. I decided the problem might be with my install of flash, so I purged the version I had (and the home folders again). I installed the x64 version of flash from a PPA. This had no effect.
  4. I decided that the problem might be with the version of flash, so I purged the x64 version and installed the standard x32 version that comes with Ubuntu. No luck.
  5. Back to the x64 version for consistency, I decided to set up a 64-bit mini 'clone' of my system in VirtualBox. I was able to run the media player with no problem.
  6. I rsynced (in archive mode) my home directory from my real machine to the virtual machine (with bridged networking, so it was fully visible on the network). I also used a few tricks to install ALL of the same software (and repositories) from the real machine to the virtual machine. I was still able to listen to the player.
  7. I decided that the problem was with my install (after all, it had gone through two major version upgrades). As I have /home/ on a separate partition it was easy to reinstall and use the same trick from #6 to have my system up and running again within about an hour. I continue to have issues with the NPR Media Player.
  8. By this point the weekend had come. At work, I use a wired connection while at home I use a wireless connection. For some reason I forgot that I was having problems and used the NPR Media Player over the weekend. Low and behold it worked just fine at home on wireless (note: for various reasons, I could not test this on wired at home).
  9. Following from #6, I decided that the problem was either something with the network at work or still something with my account. As the latter was easier to test, I created a new account on my system and used that at work. The Media Player worked.
  10. At a loss, I decided to watch the traffic with tshark (the text based brother of wireshark) - X's to protect the innocent, I am the XXX.24.200.XXX:

sudo tshark -i eth0 -p -t a -R "ip.addr == XXX.24.200.XXX && ip.addr == XXX.166.98.XXX"

As you would expect, there were tons and tons of packets, but each and every time the player froze, this is what I got

08:42:20.679200 XXX.166.98.XXX -> XXX.24.200.XXX TCP macromedia-fcs > 56371 [PSH, ACK] Seq=817686 Ack=6 Win=65535 Len=1448 TSV=495713325 TSER=396467

08:42:20.718602 XXX.24.200.XXX -> XXX.166.98.XXX TCP [TCP ZeroWindow] 56371 > macromedia-fcs [ACK] Seq=6 Ack=819134 Win=0 Len=0 TSV=396475 TSER=495713325

08:42:21.050183 XXX.166.98.XXX -> XXX.24.200.XXX TCP [TCP ZeroWindowProbe] macromedia-fcs > 56371 [ACK] Seq=819134 Ack=6 Win=65535 Len=1 TSV=495713362 TSER=396475

08:42:21.050221 XXX.24.200.XXX -> XXX.166.98.XXX TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] 56371 > macromedia-fcs [ACK] Seq=6 Ack=819134 Win=0 Len=0 TSV=396508 TSER=495713362

08:42:21.680548 XXX.166.98.XXX -> XXX.24.200.XXX TCP [TCP ZeroWindowProbe] macromedia-fcs > 56371 [ACK] Seq=819134 Ack=6 Win=65535 Len=1 TSV=495713425 TSER=396508

08:42:21.680605 XXX.24.200.XXX -> XXX.166.98.XXX TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] 56371 > macromedia-fcs [ACK] Seq=6 Ack=819134 Win=0 Len=0 TSV=396571 TSER=495713425

08:42:22.910354 XXX.166.98.XXX -> XXX.24.200.XXX TCP [TCP ZeroWindowProbe] macromedia-fcs > 56371 [ACK] Seq=819134 Ack=6 Win=65535 Len=1 TSV=495713548 TSER=396571

08:42:22.910400 XXX.24.200.XXX -> XXX.166.98.XXX TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] 56371 > macromedia-fcs [ACK] Seq=6 Ack=819134 Win=0 Len=0 TSV=396694 TSER=495713548

08:42:25.340458 XXX.166.98.XXX -> XXX.24.200.XXX TCP [TCP ZeroWindowProbe] macromedia-fcs > 56371 [ACK] Seq=819134 Ack=6 Win=65535 Len=1 TSV=495713791 TSER=396694

08:42:25.340517 XXX.24.200.XXX -> XXX.166.98.XXX TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] 56371 > macromedia-fcs [ACK] Seq=6 Ack=819134 Win=0 Len=0 TSV=396937 TSER=495713791

08:42:30.170698 XXX.166.98.XXX -> XXX.24.200.XXX TCP [TCP ZeroWindowProbe] macromedia-fcs > 56371 [ACK] Seq=819134 Ack=6 Win=65535 Len=1 TSV=495714274 TSER=396937

08:42:30.170746 XXX.24.200.XXX -> XXX.166.98.XXX TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] 56371 > macromedia-fcs [ACK] Seq=6 Ack=819134 Win=0 Len=0 TSV=397420 TSER=495714274

08:42:39.801738 XXX.166.98.XXX -> XXX.24.200.XXX TCP [TCP ZeroWindowProbe] macromedia-fcs > 56371 [ACK] Seq=819134 Ack=6 Win=65535 Len=1 TSV=495715237 TSER=397420

08:42:39.801784 XXX.24.200.XXX -> XXX.166.98.XXX TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] 56371 > macromedia-fcs [ACK] Seq=6 Ack=819134 Win=0 Len=0 TSV=398383 TSER=495715237

08:42:59.032648 XXX.166.98.XXX -> XXX.24.200.XXX TCP [TCP ZeroWindowProbe] macromedia-fcs > 56371 [ACK] Seq=819134 Ack=6 Win=65535 Len=1 TSV=495717160 TSER=398383

08:42:59.032696 XXX.24.200.XXX -> XXX.166.98.XXX TCP [TCP ZeroWindowProbeAck] [TCP ZeroWindow] 56371 > macromedia-fcs [ACK] Seq=6 Ack=819134 Win=0 Len=0 TSV=400306 TSER=495717160

08:43:00.267721 XXX.24.200.XXX -> XXX.166.98.XXX TCP 56371 > macromedia-fcs [FIN, ACK] Seq=6 Ack=819134 Win=0 Len=0 TSV=400430 TSER=495717160

08:43:00.267827 XXX.24.200.XXX -> XXX.166.98.XXX TCP 56371 > macromedia-fcs [RST, ACK] Seq=7 Ack=819134 Win=65535 Len=0 TSV=400430 TSER=495717160

So, as you can see, my machine is sending out a ZeroWindow packet (which I think means some buffer or another filled up) which causes the Media Player to halt (unfortunately, terminally - no controls on it really do anything anymore). Any ideas, at all, what would cause this? Why only on eth0 under my main account?

share|improve this question
    
Sorry for the tome there! –  Calcipher Dec 1 '10 at 16:29
    
It looks like your comment to the first answer indicates that you believe that the packet capture isn't helpful -- i.e., "My question is not is it crashing, but why and how do I fix it. Moreover, I want to know what it could be about one user account on one system that could cause problems with flash." Seems like this should go in your question if I understand you correctly. Also, in your explanation, I'm not always clear when your 'system' is your work system or a home one. Did this work on a different interface than eth0 at your work? –  belacqua Jan 31 '11 at 2:46
    
Oh, wait -- this is just one system? A laptop you take back and forth? Did you test the wireless at work or wired at home? –  belacqua Jan 31 '11 at 2:46
    
Without clarification, helping further with this is impossible. –  belacqua Mar 2 '11 at 7:14

1 Answer 1

Copying from wireshark's link:

http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers

TCP ZeroWindow - Occurs when a receiver advertises a receive window size of zero. This effectively tells the sender to stop sending because the receiver's buffer is full. Indicates a resource issue on the receiver, as the application is not retrieving data from the TCP buffer in a timely manner.

So my guess is that all this logging is just "normal" session (TCP) activity from a hanged application (flash plug-in).

As you already mentioned, the logs provided are found after the crash, so it shouldn't matter that much.

I guess that more important is to find some logs from your internet browser regarding the crash of the flash plug-in in the first place..

share|improve this answer
    
Actually, I never said that that TCP dump was after the crash. This happens at the same time as the crash. Clearly the message indicates a hung application (flash) as that is what is having problem. My question is not is it crashing, but why and how do I fix it. Moreover, I want to know what it could be about one user account on one system that could cause problems with flash. –  Calcipher Dec 2 '10 at 19:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.