Networking now kills my 5040

I switched internet to HughesNet and in the process had to renumber my network (because the HughesNet modem's LAN address is unchangeable).

My 5504 took the change in stride. However, my 5040 is VERY unhappy now and I hope someone has some ideas to try.

I have these fun issues:

1. If I boot the unit up with the network cable plugged in, as long as I have a DHCP server enabled on my network, the unit continually reboots. It gets to the last splash screen before it would actually go live before rebooting. If I disable DHCP or unplug the network cable, it boots.

2. Once booted, I can plug in the network cable. If I initiate a net connect, it goes through the process as usual. It gets to a message like 'getting new phone numbers' and sits there a LONG time... then reboots.

3. I am using a manually configured address (the 5504 uses dhcp, and I am pretty sure the 5040 did too, before). When I set the address, when it checked for the network connection, the countdown timer would hang for a while and eventually the system would reboot. I was able to work around this by unplugging the network cable momentarily at the time of the hang. Voila, the process would complete.

I don't seem to be able to switch to dhcp at all. The countdown similarly hangs, and if I remove the cable momentarily it continues, but eventually fails completely and wants to retry - then again hangs during the countdown and reboots.

I have cleared the guide data (twice in a row) to no avail.

My suspicion is that this has to do with dhcp. My HughesNet modem gives out addresses but they would be on the wrong network because it's on the other side of my wireless router. It seems to me that it shouldn't even be receiving dhcp requests (because it's on the wan side of the router) but as a precaution I tried to block port 68 coming back from the wan side, to stop any DHCP responses. Unfortunately I can't just turn off dhcp on this thing! So while I can turn off DHCP and disconnect the internet to boot it up, I obviously can't net connect without the internet.

Unfortunately, a change was necessary.

In the initial config, my lan was 192.168.0.0/24 with the lan side of the wireless router being 192.168.0.1, which was the default and I saw no reason for it to be any other way at the time. The wan side of the router was 192.168.168.0/24.

Along comes HughesNet and it HAS to be 192.168.0.1. There is no way to change it. "Simple!" you think. Just plug the Hughesnet modem into the LAN side of the network, change the wireless router from 192.168.0.1 to 192.168.0.2, and you're off and flying!

And at first I was, until I realized the Hughesnet modem was serving dhcp; it couldn't be turned off or modified, and it served up 192.168.0.2 - 192.168.0.254. No reservations, no exclusions. Yikes.

So ultimately I want the HughesNet back on the WAN side of the router where it can't cause such problems. But for that to happen, the LAN side HAS to change.

I remember hearing about this dhcp issue years ago and worked around it. I can see in my router's log that it is indeed requesting an address when it boots (and probably does when I plug in the cable too) even though I use manual settings on the unit itself (I also have a fixed dhcp entry on the wireless router for it with the same settings, part of why not to let the hughesnet modem do the dhcp). It does sound related, and I can unplug the hughesnet modem and see if that at least stops the non-net-connect problems. Theoretically the dhcp requests should NOT be getting to the hughesnet modem though.

hdonzis, elorimer, adam1991, we are all in agreement :-)

My topology did not change from what was working previously. All I did was swap out the ISDN router for the Hughesnet router, and change the IP addresses as necessitated by the unchangeable Hughesnet router.

It seems like if I unplug the hughesnet router from the wan port of the wireless router, the replaytv is fine (other than of course not being able to access the internet), but I have not thoroughly tested that yet.

What is interesting is that within 30 minutes of plugging the Hughesnet back in, the replaytv had rebooted. Coincidence perhaps. I will need to leave it overnight to do a more complete test.

It's also possible that there is some other kind of traffic coming from the Hughesnet router that is crashing the replaytv. I have tried to block this stuff in the router -- for example, UDP ports 67-68 are not supposed to be allowed through in either direction, which should be blocking any kind of dhcp traffic -- but if it's some kind of broadcast, like upnp, it might still be making it through, and I don't know what kind of broadcast forwarding this wireless router is doing. Again, I can't configure the Hughesnet router AT ALL (still searching for any hacking info on it but it is pretty closed).

aaack... I just lost about 30 minutes of typing due to hitting some wrong combination of keys!

Today as an experiment I turned off the dhcp server on the wireless router, booted the replaytv while unplugged from the network, then plugged it in once it was active. A net connect seemed to complete (I was not watching it closely, but it passed the 'checking for new phone numbers' and I saw a combining information message) and then the unit rebooted. Then it stuck on the swirly splash screen for what seemed like at least 5 minutes before I gave up (but may have been less than 2) and rebooted with the network cable unplugged again. I remember reading that waiting for dhcp timeouts can take a long time when there is no dhcp server so maybe I just didn't wait long enough.

Basically at this point I am pretty sure no dhcp traffic is coming to the lan from the hughesnet router (wireshark on a dhcp-enabled pc while it tried to get an address with the wireless router dhcp server disabled).

But I am also pretty sure that the (unchangeable) hughesnet lease time is 1 hour, because I see my wireless router renewing its wan port address (this side IS served by the hughesnet router) every 30 minutes.

So how I screwed myself becomes clearer, maybe: When I first plugged in the hughesnet router I just plugged it on the lan side and changed my wireless router to 192.168.0.2. Tried a net connect on the replaytv, which probably merely failed due to an arp table mismatch (the mac address for the 192.168.0.1 default gateway/dns server would have changed, causing internet communication to fail), and I rebooted the replaytv.

At that point I would have had vxworks going out for a dhcp address and it could have gotten 192.168.0.2 from the hughesnet router with a short lease time. In that case I still would not have had internet access because of the address conflict with the wireless router. So I would have futzed around more, mostly not very helpfully because the hughesnet router could have answered dhcp requests during that time.

Now, if vxworks remembers these two pieces of information - previous address and previous lease time - that might explain what's going on. The short lease time explains why it is able to stay up only for a short while (possibly 30 minutes exactly) if I plug in the network cable after it boots, since the problem occurs on lease renewal. But my ACTIVE dhcp server, which is the only place it should be getting answers from, has a 1-week (the max) lease. So it's as if vxworks is remembering something from before, and that it does not get a chance to save new values. The address mapping IS locked in the current dhcp server, so it should get the same address every time and it seems to me it SHOULD be fine. But something is NOT fine :-)

My current plan is to network just my pc and replaytv on 192.168.0.x, install a dhcp server on my pc, and try locking the served address to 192.168.0.2, 192.168.0.3 (the most likely culprits that would have been given by hughesnet), or the previous fixed address, with a long lease time.

If one of those configs at least gets it stable, I'll have to figure out how to actually change the ip address without screwing it up, so that it can access the internet and the other unit. The other unit was not screwed up at all because I didn't reboot it until AFTER I changed the addresses on everything else and had a new fixed address configured in the dhcp server for it.

I do have a hub - somewhere - so I can sniff things more fully if necessary.

If it turns out that I am just not waiting long enough, and it DOES come up with manual IP config and no DHCP server on the network, at least I have a workaround: get a new dhcp server that lets me block requests from the replaytv. But I'll still have the really long replaytv boots. And why did it reboot after the net connect?

Only had a little time but I did basically #1.

Switched replaytv to dhcp while plugged into the 192.168.1.0 network. Plugged it directly into the HughesNet modem. Soft-booted the replaytv to pick up its new 192.168.0.0 address from the modem. It proceeded to do its endless reboot thing.

Unplugged the network cable so it would come up. Re-plugged cable, waited a minute, went in to view the settings. Saw that it had gotten got a 192.168.0.6 address with the correct netmask and gateway.

Did a net connect and it proceeded quite quickly up to the "checking for new phone numbers" part. There it sat for several minutes. I had gone into another room and was checking on it periodically - then I noticed it was combining data. It sat at 75% for a couple of minutes and then rebooted. Back to the endless reboots. Altogether it may have been exactly 30 minutes from the time of the first boot after plugging it in until it rebooted.

I have two more things to try. Something in me believes that if I can just get a successful, complete net connect then it will be stable (maybe just wishful thinking). The hughesnet modem employs a transparent proxy which helps hide some of the latency issues of the satellite link. This may be the one feature I can actually turn off, and I will try doing so. This may be what is hanging up my net connects. It was interesting to me that the 1Mbps satellite connection did not give appreciably faster net connects than the 64kbps isdn link!

I just realized I said two more things... I can't think of the other anymore.

Well, some partial progress....

The status for the last few weeks has basically been the same. It wouldn't boot with the network cable plugged in; it either rebooted rather quickly (when using DHCP) or after several minutes -- in both cases while displaying the final splash screen but before doing anything else visible. If I plugged the network cable in after it boots, I could do a mostly-complete net connect - it would sit for a long time on the 'getting new phone numbers' stage, and if I unplugged the network cable and cancelled it then, I at least had updated guide data, but if instead I left the network cable in it would eventually reboot (and then get stuck or endlessly reboot).

Furthermore, if I plugged the network cable in after boot and then tried to connect via DVArchive, or watch a show off the other replaytv, it would immediately crash.

So, I could at least watch tv, and just manually plug in and do a net connect every couple days, but I couldn't stream from my second unit and I couldn't archive any shows in case I needed to do something catastrophic.

I tried many things - clearing the guide twice, switching to modem and back (I was never actually able to do a net connect via modem, though I used to always have to connect that way), switching to modem and picking a new area code/exchange so it would choose a different dialup number, switching to modem and clearing the channel guide twice and then switching back, plugging directly into the satellite modem, disabling HughesNet's transparent proxy, replacing the network cable, replacing dhcp servers... everything I could think of short of the level of reset (or reimaging) that would lose all my shows.

So last night I thought about WiRNS. If there's anyone here not familiar with it, one of its functions is to get between your replaytv and replaytv's web servers (you can point your replaytv's dns server to it and it spoofs the addresses of Replaytv's servers and they connect to it instead, so it can do various fun things). And because the hangup was always on 'checking for new phone numbers', and I saw this text somewhere when I googled WiRNS: "Intercepts phone number updates during a net connect" (I can't find where I originally saw this now, but it is the description of one of the optional plugins) I thought it might help.

I installed WiRNS on my pc and pointed my ReplayTV to it and did a net connect (via the WiRNS interface)... which, lo and behold, completed completely normally without any hangs or rebooting. I left it plugged into the network and I was able to download shows via DVArchive. It did not reboot all night. Now that is some progress, at least. So THAT part of it may be related to HughesNet in some way - I don't understand why it would only affect the 5000 and not the 5500 though.

Unfortunately the boot-time issue remains, or at least it may remain. I only left it for about 5 minutes (after the disk activity seemed to stop) hung on that last splash screen. I will have to try it again and let it sit longer to know for sure, and also I will have to try with DHCP. I also plugged the network cable back in and we'll see if it is still up again at lunchtime.

I don't mind leaving the WiRNS setup if I need it to get complete net connects and the ability to stream/download, but I do also want to try going back to the direct method, and if that works I will keep it direct (just so I don't have to rely on my pc). Unfortunately, if the original boot problem does still remain, I still can't leave the network cable plugged in because of the automated reboots. So I'm still only part-way there, but it's more useful than it was!

Ok, at this point, I don't know what to think. It MAY be working. I am hopeful.

Since I have WiRNS now, I decided to go ahead and make a serial cable and enable the serial shell, so I could (maybe) see what was going on during boot. Unfortunately I didn't pay attention and brought the wrong cable adapter (for the pc end) from work and had to try one I had at home that I wasn't sure was wired right for the plug I made.

I added "IRMTS" and "ptvio on" to my shellcmds file and did a net connect. Then a soft reboot. And then... stuck on the first "please wait" screen. No output on the serial port. Rats, so the cable is probably wrong. But why is it not getting ANYWHERE now?

I disconnected the network cable, changed serial settings, rebooted again, still nothing. Not even pingable after plugging the network cable back in. In desperation I unplugged the serial cable and pulled the power cord to reboot. Figured that worst case, tomorrow I would get the cabling right and hopefully see SOMETHING.

And lo and behold, during that first screen, I heard the disk churning. So far, so good (I didn't get this at first). I let it go for a few minutes, left the room and came back to find the blue LED off. Whoa, I thought. Pushed the power button and it turned on. It had booted with the network cable plugged in, something I haven't seen since September. I can stream a show from the other replaytv. It's alive! Or so it seems.

For now I don't want to mess with it. My wife may be home sick tomorrow and I want her to be able to watch tv. But I am hopeful. Whatever I screwed up on 9/15, I hope I managed to reset. I wonder if that serial cable I was using had an internal connection from one of the pins to ground that it didn't like.

So it turns out that I probably could have saved myself a little time way back in the beginning of this.

Last week the 5040 that had all the trouble crashed while watching a show and would not boot. Pulled the drive and ran the SeaTools diagnostics and it had a few (maybe 7 - I don't remember) bad sectors. So I probably had some drive corruption in the first place, but I really wanted to avoid the whole drive replacement struggle -- wishful thinking I guess. I was able to extract all but 3 shows.

As it turns out the drive replacement was its own fiasco. Best Buy's website has the 500 gig WD non-AA version drive listed which seemed like it should work, so I ordered it for local pickup since it would be the quickest option. But my local store only had the 16MB "AA" version, which they substituted (priced $15 higher in the store so they probably figured I'd be happy) which doesn't boot in the ReplayTV (not in the 5500 either) even though the computer is happy with it.

My current drive is a Seagate that I THINK has a 5-year warranty and while I don't remember when I bought it, I think the date code means April '06 so I should be within warranty, but their website just tells me it can't tell whether it is in warranty or not. So, just for kicks I used SeaTools to fix the bad blocks and it subsequently passed many long tests with no further errors, so I reimaged it and put it back in and will be returning the clunker to BB.