Strange Gateway DHCP Issue

[ADin]

I purchased and installed a 5002-C system this past Sunday and after significant fussing around (due to the below) I have been successful getting everything talking, though I only have what I consider a partial solution.  My issue is that whenever I plug my gateway into my Westell 7500 DSL/router, the gateway and all future wired/wireless router connections revert to static IP connections (no DHCP).  Unplugging the gateway and resetting the router allows all wired/wireless connections to properly DHCP as before.  Therefore IF I have all network devices already connected and operating properly (DHCP wise) and now that I have a static IP (192.168.1.18) set in the Gateway (it doesn’t matter whether the GW checkbox is set to static or DHCP), I can plug it in the DSL/router and access footprints fine.   However, if any of my home network devices need to reconnect back to the network, they will fail as the router assumes static IPs and I must disconnect the Gateway and reset the dsl/router to get back normal DHCP operation.  I have walked through all router network setting looking for anything amiss but all appears normal.  At the moment I have the Gateway off the network until I can figure this out.  Is this anything that has been seen or thoughts of other things to check?
 
BTW – I did call Frontier (DSL provider) and their knee jerk reaction is to replace the DSL modem which they are currently trying to schedule someone to come out Thursday for a modem swap, but I don’t really want to go through the hassle of taking off work and swapping out only to have the same problem result.

Thanks in advance

[RussellH]

You might check the version of the gateway.  The Release notes for 402 says "If a TCP socket is stuck in the SYN state for more than 5 seconds, that socket will now be killed (NWS flooding issue)."  That's the closest I can think of as to why the gateway might be affecting your router.

If you can, you might also see if there's newer firmware for the router.

[ADin]

Thanks, I don't remember the version number off the top of my head but it was the latest as of Sunday as I updated at the beginning of the install process.  Seems like the bug you mention may affect the GW but seems the DHCP for other devices should be ok unless it somehow causes the router to lose it's brain.

[RussellH]

I'm not a networking expert, but know my way around.  I can't think of why the DHCP would go off-line because of plugging in the gateway.

[lundwall_paul]

Router problems TED works as advertised I wrote this thought someone could find this useful

My TED was working great this morning until I had to re-install my wireless printer. After I got the printer up and running, Footprints read all zeros, TED installer never found the TED address, the TED display worked great. I went to my router web page and looked at the DHCP Client table the TED was not listed. I unplugged the router and plugged it back in everything is fine. My router has done this on more than one occasion. I should have realized the router burped before when the printer didn’t work.
I have also discovered with my router that recycling power to it is the only way to go. The router web page has links for release; renew the IP address and a reboot the router. From what I see these links will kick you off the web but do not affect my wireless devices.

[ADin]

Paul - I'm familiar with many router anomolies and I still give is a 50-50 chance this will end up being a router issue in the end.  Still waiting for Frontier to drop off a new router though I suspect it won't change the outcome.  As soon as I get a bit of time (probably this weekend), I will load up wireshark and start the first step in digging into who is the guilty party.  I borrowed an airport express today to assist in the debugging as the router's internal ethernet switch isolates and hides the level 2 stuff, memory serving.  I suspect just running the GW through the airport express may "fix" my problem, but I don't like band-aid solutions unless I understand root cause.

[lundwall_paul]

I agree with finding root cause to problems like this!! But you also must take into account the demographics of who reads the posts. Most are customers are just interested in a quick fix to get it back up and running. I listed below what I have seen perhaps there is a clue as to the root cause.
I know very little about networks other than devices all should have different addresses.
I have tried a new router and that was not a fix. The only clue that I have is when I cannot use my wireless printer most likely Footprints also does not work. Other wireless devices seem fine like IPODS and other computers on the network. I did see one warning that popped after I cycled power to the router and that was an address conflict. This is from the event log:
“The system detected an address conflict for IP address xxx.xxx.x.143 with the system having network hardware address 00-22-64-41-87-53. Network operations on this system may be disrupted as a result”.
143 happen to be the printer. All devices are up and running like they should be. What the conflict really was is not clear to me.

[ADin]

Understood - I didn't mean to imply anything relative to your issue or that our issues were in any way related.  Unfortunately, for me I don't yet have even a band-aid which will allow my network devices to cohabitate in any meaningful fashion. 

Despite my occasional sarcasm at times, this is a way-cool product for those of us with the perseverance, inclination (and for some luck) to get it set up.  Jumping through hoops to get things working really doesn't bother me for something like this as I knew going in some of the pitfalls I would likely encounter and there are just too many real-world variables to make this truly turn-key.  Where I have to shake my head is when the process is hindered by things which actually could be readily be solved with a simple/better organization of data.   I do think TED has actually done a good job overall given the nature of the installation; but I know it could be better in some areas.

[lundwall_paul]

Any luck figuring this out?

[ADin]

Paul, Not solved, but I do have a better temporary workaround.

I unfortunately did not have much time to dig into this issue over the weekend.  I did receive the replacement Westell modem/router with no change in outcome as expected.  I also quickly realized that the Westell 7500-44 modem/router does not support WDS so my debug plan with the borrowed airport express was shot down.  I currently have the gateway connected through a Netgear WN3000RP range extender to my wifi network and it seems to be operating as expected (past couple of hours).    

My working theory all along is that the gateway's signaling on my particular GW device is not clean (or marginal) and was creating havoc with the Westell, even though the Netgear seems to be able to deal with it.  I'm sure the result with the airport express would have been similar.  Although I'm sure the Westell is probably not of the highest quality for its own part, I've read here of at least several instances of Westell 7500s operating with no issue with the TED and since I've tried two different Westells here which seem to handle everything else I've ever plugged into them properly, I'm now more suspect of the GW at the moment.

I would really like to swap out the GW to see if it follows the GW as the Netgear intermediary device is not a good long-term solution for me.  I suspect my GW is either out of spec or marginal.  I will try a few more experiments for due deligence when I get a chance but, barring a major breakthrough, will likely contact TED for a swap-out.

Opinions or thoughts on further simple experiments are welcome, but after I've narrowed it down to what I consider "reasonable" doubt on this particular GW unit, I don't feel nearly as motivated in spending another 10-20 hours trying to get to "beyond a shadow of doubt" status.

[ADin]

On a side note, I just now opened my recently received X-10 Pro Wired-In Filter.  When I slowly tilt from side to side I hear a distant rattle inside.  Packaging and case is fine.  Sounds like either a loose screw or hunk of plastic rolling around in the case.  Looks like I may be killing two birds with one stone on a swap out now...

[ADin]

Current update, system is now usable. 

The DHCP issue remains and as yet still unexplainable (would still love any comments, theories, additional tests to run from TED on this).  However, I have been able to get the Gateway working reliably with the Westell Modem/router in static IP mode through tweaking of the DNS settings.  During one of the GW reset episodes, the DNS values were reset back to 8.8.8.8 and 8.8.4.4 and this appears to be a catastrophic combination with the Westell.  After seeing this IP traffic to Google in wireshark, I changed the settings and committed the updates to the Gateway.  Nothing changed and I then noticed IP traffic to Google was still occurring.  I went back again and noticed that modifications to the DNS values did not always 'stick'.  The update process proceeded to 100% almost immediately each time and resetting the Gateway didn't have effect.  I repeated the process several times.  I then modified several additional non-important parameters on several of the other screens and the update then went through its normal longer write cycle process and afterwards the DNS values were finally written.  Looks like there could be a bug in detecting a change in certain values in the settings update process.

Although I'm now functionality at the moment, I'm not currently sure what to think as to whether I somehow got a one-off goofy Gateway unit or whether the GW's network stack itself and/or footprint software lacking implementations.

Finally, I did isolate both MTUs and GW on their own circuit with an in-line filter from everything else and my PLC communication is now solid.  The rattle in the in in-line filter mentioned earlier was a large hunk of hardened hot melt which had broke loose at some point prior to reaching me.

[RussellH]

During one of the GW reset episodes, the DNS values were reset back to 8.8.8.8 and 8.8.4.4 and this appears to be a catastrophic combination with the Westell.

Interesting.  I wonder why?  Do you have anything else in the house using the Google DNS?  I happen to have a Linksys router behind a Westel modem and I have 8.8.8.8 as a "static" DNS on the Linksys, so I know it's being passed to my gateway.  And all is fine.

[ADin]

Just to clarify, when I said "reset episode" I was referring more to a likely hard reset with a paperclip, although I had done a number of both.  Nothing else in the house uses Google DNS.  Given the GW's DHCP issue and impact on the entire network, I think the issue is actually more of an interaction issue between the GW and the Westell's internal router versus the modem itself.  This would also explain why your setup is working correctly.  I would be interested to know if anyone here actually has a TED working with the Westell 7500-44 (not to be confused with the -45). 

I will also note the sub-net address also got zero'd out along with the DNS and did not immediately stick either.

I'm now curious if turning DHCP back on, now that static IP values are functional, would now allow DHCP to work.  I suspect it might as I believe the GW's values would be used unless the IP address is in conflict.. If I have 15-30 minutes to waste at some point I may try it.  Unfortunately, if it stays broken, its a bit of a pain to get back as I need to physically move the GW from the basement to direct connect to the computer to recover and everything usually needs to be booted once or twice.

[ADin]

I had assumed the GW had a default DNS of 8.8.8.8 and 8.8.4.4 and that a hard reset was likely what had put them back. 

Upon further reflection, I seem to remember the settings being 192.168.1.1 out of box originally (or maybe I'm just imagining them as I have typed in these numbers so many times now).  If the GW hard reset does put these settings back to 192.168.1.1, then I can only assume the google DNS values must have came from either the airport express or Netgear range extender I had experimented with at one point.  However, if this is the case and the source of my problem in static IP mode, then I'm at a loss as to why my initial tests day 1 with setting the GW to static IP mode never worked in the first place. 

I feel like I now need to walk back through the steps of setting the GW back to DHCP once last time and if necessary hard resetting and walking back through the steps to see what is happening to these settings at each step along the way.