1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Strange Networking / MediaShare Issues

Discussion in 'DIRECTV HD DVR/Receiver Discussion' started by phat_b, Sep 3, 2009.

  1. Sep 3, 2009 #1 of 26
    phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    Sorry for the very lengthy post but...

    Thanks to D*'s free 72 swap program, this Monday I was upgraded(?) from my trusty old series 2 TiVos (SD-DVRx0s, may they R.I.P.) to four shiny, new HR23-700 DVRs. I have much love for my recently obsoleted TiVo hardware, but I will beat that horse in another thread. So to start let me state that by day I setup and troubleshoot networking installations and know the intricacies of twisted pair ethernet and ipv4 well enough that I feel comfortable ruling out the obvious. All the networkable hardware in my home (excluding a couple portable devices) is connected to a 24 port 10/100 switch via dedicated cat5 pulls.

    At this point I set out to build a dedicated Ubuntu machine to run a uPNP server. However, in my impatience to test drive the MediaShare functionality I loaded up TVersity on one of my (cringe) windows machines. This was Monday evening. It worked as well as could be expected, even transcoded xvids played well. If shuttle commands (ff / rw) were implemented in the DVRs renderer I'd hardly remember why I loved my TiVos so much. At this point I've statically addressed two of the DVRs, and everything seems to be peachy.

    Moving on. The electric utility cut power to our home in the early hours on both Tuesday and Wednesday for scheduled upgrades. I don't know if this is related to my problem or not, just mentioning it. In the mean time I did not test or even think about MediaShare until Tuesday afternoon when I'd finished compiling MediaTomb and all it's dependencies and had some test media loaded up on what will eventually (hopefully?) replace my old media server.

    Unfortunately my DVRs aren't cooperating. After pulling my hair out for a few hours recompililing MediaTomb, I decided it a good idea to make sure that the DVRs were still seeing the TVersity server that had worked 24 hours earlier. No luck. They're not even responding to pings. After some research it appears the ICMP issue is a given, probably the result of thoughtful firewalling on the DVRs. But I have no idea why MediaShare is no longer seeing my TVersity server.

    So after much searching, reading and digesting everything I can on this and a couple other forums, I've decided to post here in hopes of finding some ideas. Here's where I'm at:

    statically addressed dvr
    IP: 192.168.24.20
    NM: 255.255.255.0
    GW: 192.168.24.1 (router running base openwrt with iptables, dnsmasq, dhcp, upnpd)
    DNS: 192.168.24.1

    Nothing else on the LAN has changed, and everything else still works as it has for the past 18 months or so.

    Experimenting last night, I found that if I reboot the boxes with the ethernet unplugged and then connect them to the lan while running a ping on my router I see replies for a short time until the DVR's firewall is presumably enabled. The flashing leds on the DVR's ethernet ports indicates there is some network traffic occurring, though it must be local traffic because nothing shows up from the DVR IPs in my router's ip_conntrack.

    The last thing I tried yesterday evening was to reset the DVRs to default settings on the network screen. This gets even better - now they won't even get a dhcp lease. This was also working Monday afternoon. Also, I'm relatively sure they were able to connect to the internet at some point, because the On Demand option has appeared in the menu - something I'm almost positive was not there Monday afternoon.

    So, any ideas what is up? I've become quite familiar with the whole 'connect now' screen - everything comes back with 'OK' status except for the dreaded error 22. What's even more puzzling is that if I watch ip_conntrack on my router during the 'Connect Now' process, it doesn't even appear that the DVR is trying to connect to anything outside of my LAN (i.e. the internet). :confused:

    I'm thinking the next thing to try is doing a 'Reset Everything' which I assume reformats the DVR hard disk and starts from scratch.

    Any thoughts, comments, ridicule? Is it possible that D* disabled MediaShare because I'm a lowly SD only subscriber?
     
  2. Sep 3, 2009 #2 of 26
    phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    Forgot to mention previously, all boxes are running 0x0312 firmware. I attempted a force download last night, but no love (0x034c).
     
  3. Sep 3, 2009 #3 of 26
    Spanky_Partain

    Spanky_Partain Active Member

    5,500
    0
    Dec 7, 2006
    Ping should always work.

    I would start with rebooting the complete network first. I do not think 'Reset Everything' is going to get you anything in the network world.

    There is also a link in my signature with a bunch of network help.

    Here is a link that will help getting the DHCP service back to working, http://www.dbstalk.com/showpost.php?p=1071193&postcount=21
     
  4. Sep 3, 2009 #4 of 26
    phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    That's what I thought, because I recall pinging all four units before messing with statically addressing two of them. But now I only get replies for about 5 seconds after plugging the DVR up to the ethernet. So I believe something else is going on with networking on the DVR.

    The only reason I mention this is because I thought it might get rid of the 'On Demand', which was absent when MediaShare was working.

    Thanks, but this is all pretty remedial info to me. In my profession I manage a MPLS and VPN corporate network that spiders all over the country. The only thing I'll accomplish by rebooting my router is resetting the uptime. :(

    That explains something... may be worth a shot. But I'd still prefer having them statically addressed.
     
  5. Sep 3, 2009 #5 of 26
    Spanky_Partain

    Spanky_Partain Active Member

    5,500
    0
    Dec 7, 2006
    I use Reserved DHCP in my home network. It has been rock solid and that way I know which DVR has what address and I can forward ports for correctly assigned addresses. I find your scenario very unusual, in the fact that it should work. That is why I suggested a reboot. Home routers are not always as solid as some of the business stuff! ;)

    EDIT
    The IP address is a little different than expected, but as long as everything is in the same subnet, then that should not matter.
     
  6. Sep 3, 2009 #6 of 26
    rudeney

    rudeney Hall Of Fame

    4,266
    1
    May 28, 2007
    I've had much better results from my networked HR20's by setting reserved IP address via DHCP in my router. I don't like defining static IP's on the devices themselves because then I have to keep up with a list "somewhere" and it usually means having to manually configure the DNS and gateways. By reserving the IP's in the router, the devices are easy to setup with DHCP configuration, but I can still control which IP gets assigned to which device and see the entire list in one central place (i.e. on the router).
     
  7. Sep 3, 2009 #7 of 26
    phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    Aside from the port forwarding (which I also tried in hopes of resolving the error 22 problem) there's little reason for statically addressing them. But even the two in my kid's rooms that I did not statically address are acting the same way (no MediaShare, error 22).

    Amen brother. Although there is a web GUI on my router, I manage it and most everything else important to me with ssh. Until I installed upnpd on my router yesterday, it had 114 days of uptime. And truth be told I only rebooted to make sure upnpd started from the init scripts...

    Code:
    > /etc/init.d/S40network restart
    > /etc/init.d/S45firewall restart
    
    ... pretty much handles it. Though it is not for the timid, I swear by OpenWrt.
     
  8. Sep 3, 2009 #8 of 26
    Spanky_Partain

    Spanky_Partain Active Member

    5,500
    0
    Dec 7, 2006
    Nothing wrong with a penguin in the house! ;)

    Perhaps someone else can chime in then. I really don't have any other suggestions. The network has always been very staright forward and simple to change, just as you would expect. That is why I find it strange that it is not working.

    Maybe it is your firewall! Have you tried turning it off?
     
  9. Sep 3, 2009 #9 of 26
    phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    I'm thinking I've probably looked at the 'advanced setup' screen on every box. If the issue referred to in the 'True DHCP' thread is still present in current firmwares, that would explain why the DHCP boxes aren't working (DHCP is being disabled, but no dns or gateway). I'll try enabling DHCP per Doug's instructions tonight and will report back.

    The only thing it doesn't explain is why the statically addressed boxes aren't responding to pings all the time / seeing uPNP servers, internet, etc.
     
  10. Fabuloso

    Fabuloso AllStar

    58
    0
    Jun 13, 2009
    i had the same problem as you with the media share just randomly disappearing for no reason but i never did get any error messages when i did a connection test.

    the problem i found was the for some reason tversity on my media server stops sharing. when i restart sharing the problem is resolved.
    make sure that tversity is actually sharing with your clients. thats one solution.

    2nd if i read your posts correctly you do have on demand on your DVRs thats a good thing. have you tested to make sure your DoD works? if it does another thing that happened to me once is to make sure your DVRs arent all trying to squeeze throught the door at the same time.
    in other words make sure they all have their own ip address.

    3rd just restart your media server, router/switch and your modem just to be on the safe side but do not restart your DVRs let them sense a new connection and they will acquire a network address on there own.
    Hang in there man!!:)
     
  11. Spanky_Partain

    Spanky_Partain Active Member

    5,500
    0
    Dec 7, 2006
    I would try turning off the firewall stuff on your router, reboot it, and try it again.

    Uptime? :D

    Uptime is a measure of the time a computer system has been "up" and running. It came into use to describe the opposite of downtime, times when a system was not operational. The uptime and reliability of computer and communications facilities is sometimes measured in nines (similar to the unit of metallic purity). "Five nines" means 99.999% availability, which translates to a total downtime of approximately five minutes and fifteen seconds per year.
     
  12. phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    Here are some interesting things I've discovered after several hours of trial and error.

    To start out I reset the DHCP settings from the 'Advanced Setup' - after ~15 seconds it comes back with connection failed, so I clicked 'Connect Later'. I then restarted the DVR and it comes up with bogus 169.254.x.x in system info (no DHCP config supplied).

    So out of desperation I think back to plugging the ethernet cable into these boxes after the installer left - when they were already up. So I restart the box with the ethernet disconnected. After it acquired the guide data I plugged it into the ethernet and look for the dhcp lease on my router. I launch a pinger and immediately start receiving replies. My uPnP servers show up, and I can play media.

    I now statically address the box. I click 'Connect' and it passes the 'Internet' test immediately. The pinger is receiving replies at the new IP, and uPnP still works.

    Figuring the problem must be related to my DHCP server's response time when the DVR is running it's startup scripts, I restart the box with the static address and ethernet connected. No networking.

    I restart it again without ethernet connected. After the guide is acquired I plug in the ethernet cable, and start receiving icmp replies. Then a strange thing happens - after four or five seconds it stops replying to pings. 'Music, Pictures & More' appears in the main menu, but as I expect it's unable to browse the one uPnP box that is listed. I'm going to presume it sent a discovery packet during the short window when networking was up.

    So I go back and enable DHCP again with 'Restore Defaults'.

    Restart w/o ethernet, plug in after guide, network working, stays working.

    Restart with ethernet, no networking. Bogus 169.254.x.x IP in system info.

    Restart w/o ethernet, working... you get the picture.

    So I apply what I've learned to my #2 DVR. And it works.

    I would like to apply some sort of logical progression to this data to figure out where the problem truly lies, but I'm way too tired to think clearly, and incredibly perplexed. Most notably by the part where a statically addressed box replies to pings for a short time and then stops. I think the next step will be to try debug logging on my DHCP daemon to see whether the DVRs are renewing their leases at startup.

    Having gone through all this, I'm wondering if anyone has been sucessful using statically assigned IPs. And if so on what firmware version.

    The good news out of all of this is that both of my uPnP servers showed up after figuring out how to boot the boxes. Unfortunately I've wasted the last two evenings troubleshooting something that should Just Work (tm) when I should have been fine tuning the transcoding configuration on my uPnP server.
     
  13. Spanky_Partain

    Spanky_Partain Active Member

    5,500
    0
    Dec 7, 2006
    I never saw a test where you turned off the firewall on your router. I think you need to try this.

    I have used Static/Reserved DHCP/DHCP with success and NEVER had to unplug the network during boot to get it to work. I do remember a time back someone else doing this for some reason and I do not recall the reason why.

    Will you post your equipment and model of the router or are you using a software router?
     
  14. phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    That's because I didn't feel perturbing the kids by disconnecting them from xbox live for something completely pointless. However if setting up DCHP reservations doesn't change anything tonight, I will humor you by substituting an unmolested, plain vanilla consumer router at my gateway. I'll even do an nvram reset twice, and drip hot wax on it before I apply power. ;)

    Please forgive my sick sense of humor this morning, I know you're trying to help. But I fail to understand how your thought process takes you to pointing the finger at the parts of my network that have worked flawlessly for years and not the four new devices exhibiting identical symptoms?

    On the other hand, I suppose it is possible there is some obscure bug in the dnsmasq implementation I'm using that has gone unreported over the three plus years since the distro was released.

    OpenWrt White Russian RC5 on a Motorola WR850G - MIPS running @ 125mhz, 8mb ram. All the other info has been given elsewhere in the thread.

    I'm really curious if anyone with a HR2x dvr without the HD package could report their experiences with networking. I say this because it seems to me like the DVR is deliberately not configuring, or even deconfiguring the interface - thinking back to plugging in the statically addressed DVR and receiving ping replies for a short time, and then drop city.
     
  15. phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    I believe I've found the problem, or at least narrowed it down to something I don't like the looks of...

    After configuring my dhcp daemon to log all requests, here's what a normal DHCP transaction looked like - this would be my IP security cam.

    Code:
    Sep  4 23:52:46 (none) kern.info dnsmasq[4747]: DHCPDISCOVER(br0) 00:03:ea:04:35:7e
    Sep  4 23:52:46 (none) kern.info dnsmasq[4747]: DHCPOFFER(br0) 192.168.24.225 00:03:ea:04:35:7e
    Sep  4 23:52:46 (none) kern.info dnsmasq[4747]: DHCPREQUEST(br0) 192.168.24.22500:03:ea:04:35:7e
    Sep  4 23:52:46 (none) kern.info dnsmasq[4747]: DHCPACK(br0) 192.168.24.225 00:03:ea:04:35:7e iGuard
    While I was in the config file I also setup reservations for all the dvrs, this is what it looks like when I plug one in after it's started up (i.e. watching live TV).

    Code:
    Sep  4 23:56:13 (none) kern.info dnsmasq[4747]: DHCPDISCOVER(br0) 00:1c:c3:xx:xx:xx
    Sep  4 23:56:13 (none) kern.info dnsmasq[4747]: DHCPOFFER(br0) 192.168.24.20 00:1c:c3:xx:xx:xx
    Sep  4 23:56:13 (none) kern.info dnsmasq[4747]: DHCPREQUEST(br0) 192.168.24.20 00:1c:c3:xx:xx:xx
    Sep  4 23:56:13 (none) kern.info dnsmasq[4747]: DHCPACK(br0) 192.168.24.20 00:1c:c3:xx:xx:xx DIRECTV-.........
    And here's what the DCHP log looks like when I cold boot that same box.
    Code:
    Page intentionally left blank.
    I waited at least fifteen minutes without seeing a single DHCPDISCOVER packet.

    So Spanky_Partain, do you still think I should disable my 'firewall' and reboot my router? :)

    I'm getting the feeling that if I called Dave about this, they would happily fix it if I purchased the HD package. I will pay close attention to how this works when the new firmware rolls around however.

    I also think I've found another detail related to the conditions where networking works for a short time and then is disabled. When I setup my daughter's DVR, the first time I booted it without the ethernet and then connected, it worked for 10-20 seconds, and then no more. I found that this is the only one I haven't clicked 'Connect Now' on. Once I did this and then rebooted, networking stays up after 'hot plugging' onto the lan.
     
  16. dennisj00

    dennisj00 Hall Of Fame

    9,689
    195
    Sep 27, 2007
    Lake Norman, NC
    You need to get back to basics and forget about the router until you find what's blocking PING and cutting off the connections. We've diagnosed a lot of problems on this board but I don't think I've ever heard of network problems of this extent.

    You mention a 24 port switch. . . if this is some type of managed switch, it could be your problem. It could be blocking ICMP and also waiting on some approval list and timing out the connection.

    Take a small 8 port switch and connect your 4 HRs and assign them static addresses. They should ping from any workstation on your network with no mumbo-jumbo, no plug-in after reboot, no waving of the voo-doo stick!! It's simple they boot, they ping or there's something else wrong on the network. (or if you have 4 HRs with defective network ports, you need to run out and buy some lottery tickets!!)

    BTW, the 169.254. x. x address isn't 'bogus'. It indicates your device has not received a routable network address. There's a thread on here that discusses using a direct connect cable between two units (w/no dhcp server) for MRV using the 169.254. x. x

    In fact, Linksys has started shipping devices with this range as a default address for configuration.

    Keep us posted on your progress. PM me if you have any questions or comments.
     
  17. phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    Did you miss my previous post? The one where I outlined how the boxes (DVRs) are not broadcasting DHCPDISCOVER packets if I have the ethernet cables connected when they start. This is happening on all four DVRs, and only on the DVRs.

    It's an unmanaged switch.

    If i statically address the DVRs as I've outlined previously, they work fine until a reboot. Then no network. I have to boot the DVRs and then connect the ethernet.

    The problem is not my network. Grief...

    Thanks for the remedial history lesson on the APIPA block btw. <shaking head>
     
  18. dennisj00

    dennisj00 Hall Of Fame

    9,689
    195
    Sep 27, 2007
    Lake Norman, NC
    Glad I could help! You're the one that called it 'Bogus'.
     
  19. Spanky_Partain

    Spanky_Partain Active Member

    5,500
    0
    Dec 7, 2006
    Looks like you got things well taken care of. Hope you get it going! :D
     
  20. phat_b

    phat_b Legend

    103
    0
    Apr 19, 2005
    After a little experimentation with tcpdump, I found that I wasn't waiting long enough to see the DVR broadcast a DHCPDISCOVER message after a restart (with ethernet connected). It doesn't attempt to configure with DHCP until 12 minutes after a restart. Unfortunately it doesn't complete the transaction after the DHCP server offers it an address lease.

    Code:
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
    16:38:42.973687 IP 169.254.8.48.49152 > 239.255.255.250.1900: UDP, length 338
    [ 26 similar packets removed ]
    16:50:56.501485 IP 169.254.8.48.49152 > 239.255.255.250.1900: UDP, length 322
    
    <dvr restarted>
    
    16:52:37.010108 IP 169.254.8.48.49152 > 239.255.255.250.1900: UDP, length 160
    [ 4 similar packets removed ]
    16:52:37.024777 IP 169.254.8.48.49152 > 239.255.255.250.1900: UDP, length 224
    16:56:04.010700 IP 169.254.8.48 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s)
    16:56:04.213438 IP 169.254.8.48.49169 > 239.255.255.250.1900: UDP, length 137
    [ 28 similar packets removed ]
    16:57:02.778428 IP 169.254.8.48.49153 > 239.255.255.250.1900: UDP, length 364
    16:57:59.115628 arp who-has 192.168.24.1 tell 169.254.8.48
    16:58:05.227814 arp who-has 147.21.176.18 tell 169.254.8.48
    17:02:57.325627 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1c:c3:xx:xx:xx (oui Unknown), length: 548
    
    Sep 10 17:02:57 (none) kern.info dnsmasq[777]: DHCPDISCOVER(br0) 00:1c:c3:xx:xx:xx
    Sep 10 17:02:57 (none) kern.info dnsmasq[777]: DHCPOFFER(br0) 192.168.24.23 00:1c:c3:xx:xx:xx
    
    17:05:22.569711 IP 169.254.8.48.49153 > 239.255.255.250.1900: UDP, length 373
    [ broadcasts continue ]
    
    The only other thing I'm seeing here that could be causing a problem is the IGMP request from the DVR. My router is not running any type of IGMP proxy. Still, it's somewhat confusing that the box will successfully acquire a lease (see previous post) when I connect an already started DVR's ethernet port to the same LAN...
     

Share This Page