So less than 2 days after I updated from 384.11_2 to 384.12, my Sony TV completely crashed and was unresponsive (I had to pull the plug). While checking things out I noticed that there was constantly around 320 TIME_WAIT TCP connections from the T to port 8200 (UPnP Media Server) on the router. To get that many TIME_WAIT connections constantly, the TV would have to be making tons of connections a second to the router. Anyway, I turned off the UPnP media server on the router since I don't use the router as a media server and those dropped to 0. On a side note, I can't do this in iOS since the toggle does nothing in Safari, Chrome, etc.
The other port with lots of TIME_WAIT status connections is the port miniupnpd is listening on. That has 115 TIME_WAIT connections between all my devices (not just the TV).
Is it normal for there to be that many connections between devices on port 8200? How about the upnpd port?
Also what is the TIME_WAIT timeout time?
I agree...
There is a serious glitch in UPnP media server or Samba processes (see earlier post). It caused errors in my shared disc and started a closed loop that locked up/crashed the router and required a hard router reset. Without the shared media drive (8 TB), all is well. It will not boot without lockup if the usb 3 disc is plugged in, nor will it read the drive successfully after boot. CPU load goes to 100% and never recovers.
___________________________________________________________________
Here is the original write up from page 4 (#78):
So, I tried to do my usual dirty upgrade on my RT-AC5300. It totally failed to accommodate my 8 TB media drive. It caused all sorts of problems, but ultimately failed to mount. These were the log entries, after I had tried every usual solution:
Jun 22 14:41:26 kernel: b_state=0x00000020, b_size=512
Jun 22 14:41:26 kernel: device blocksize: 512
Jun 22 14:41:26 kernel: __find_get_block_slow() failed. block=4766297888, b_blocknr=471330592
Jun 22 14:41:26 kernel: b_state=0x00000020, b_size=512
Jun 22 14:41:26 kernel: device blocksize: 512
This repeated over and over, tying up all the CPU assets (100%). Memory use peaked at 94%, then after 8 minutes, fell to 44% and stable.
Something about the usb change for Windows problems in reading the drive (in some cases, not mine) seems to have really hosed the operating software.
If I left the media drive unplugged, all was well with the system thumb drive in the usb 2.0 slot. I am going to roll back to see if that solves the problem. More shortly...
So, I rolled back to beta 2. After boot, the media drive showed as having a system error. Upon scanning the drive, this was the error message:
MMC could not create the snap-in. The snap-in might have been created incorrectly.
I repaired the drive, deleted all ASUS router written files/folders, played media from the drive, scanned it again (just to be sure), and all was well. I then tried it again with the software update with the same result and the same endless error message.
Again, the router is fine without the large media drive attached.