6500 comes up in Link Local

  • 1
  • Problem
  • Updated 4 years ago
  • (Edited)

It appears this problem is fixed after using the reset switch on the router. I just wanted to document it if others see it or it comes back in my case.

Received the 6500 about 6 months ago. It has always booted up with a valid 192.168.1.x LAN address as assigned by the Verizon FIOS Westell Model A90 - 9100EM15 cable modem-WiFi-router. Two weeks ago (before the 6500 s/w update), boot up started showing a link local address in the radio setup window.

I have tried several different configurations in hoping to find the problem, including
- a different gigabit switch between router, 6500 and pc
- a direct Ethernet cable from 6500 to the router.
- Moved router close to PC and 6500.
- unplugged power and cable connection from router and restarted

Sometimes the 6500 boots up with a valid DHCP assigned LAN address 192.168.1.103, perhaps 1 out of 10 times.
There seems to be a better change of getting a valid DHCP address if I do a factory reset and then on the second boot-up attempt after that I usually get a valid DHCP address.
All other devices on the LAN are working properly.

and
- finally reset router with reset sw on back. The 6500 has been booting up with a valid LAN address since then.


Photo of Ed - NZ1Q

Ed - NZ1Q

  • 76 Posts
  • 6 Reply Likes

Posted 4 years ago

  • 1
Photo of Ed - NZ1Q

Ed - NZ1Q

  • 76 Posts
  • 6 Reply Likes
The "coming up in Link local" problem is back. I've tried to eliminate as much as I could. Better computers, different lan arrangements (through switch and direct to modem/router). No other device on the network has an issue with obtaining an ip address from the router. Any other thoughts suggestions?
Photo of Mike KD2CJJ

Mike KD2CJJ

  • 122 Posts
  • 33 Reply Likes
I am a prospective customer thus I can only contrast this issue to common networking issues that produce a similar symptoms.  My background is enterprise and solution architecture for a very large consumer products company...... Since I havent seen any feedback I figured I could pass along some knowledge:

Typically the issue your experiencing is DHCP delay in the device to acquire the proper IP address affecting dependent services/daemons.  Generally if there is a failure in how the ARP table cache is refreshed on the device and their is a delay in DHCP.  You can experience a scenario where the dependent services/daemons of the device are unaware of a change in routes (IP address change due to another device that has already taking the Flex's IP address) and use an irrelevant IP address while a new DHCP is in process of being issued by the DHCP server (your router).  Applications that rely on UDP are more susceptible due to the nature (ie reliability) of their packets... We have resolved this issue in the past by creating dependencies in how services/daemons start or changing how the application handles delays in issuance of new IP addresses (actually putting in exception handling when packets are not delivered).  In short putting in delays in any dependent services/daemons, etc. solves the issue... there are many different ways to fix the issue though.. Some times the issues lies in the underlying network stack of the OS

Since you cant fix the device... The best thing you can do is in the router in the DHCP configuration put in an entry that maps back to the host name of the device.  Host names are static and broadcast to the router as part of a DHCP request.  In the DHCP router config,  you can tell it to always use a certain IP address bound to a specific Host Name.  This will solve your issue based on the sympthom you have described.  I have a FIOS router and have servers at my house and use this technique for my servers.  It ultimately guarantees the IP address for that device without the need for statically defining an ip address on the device.  I do not believe this will fix others issues where they have lost connection...

Of course everything above is speculation as I do not have a device but hopefully it could solve your issue...

Photo of Ed - NZ1Q

Ed - NZ1Q

  • 76 Posts
  • 6 Reply Likes

Hi Mike,

Many thanks for your input. Very valuable info. I have worked enough with LANs to be dangerous, as I've worked at Lucent, EMC and a couple smaller high tech companies.

Here are a few additional data points. The FLEX worked fine on the network for 4 months. The way the FLEX comes up now is that every 3-4 times I reboot it will come up with a valid DHCP assigned IP address. Actually it is always the same address 192.168.1.103

No other device comes on line while I reboot the FLEX so there should be no change in routes or next assigned IP addresses. I'm also using a FIOS router, mentioned above.

Other unusual events.

a) If I reboot the FLEX and it comes up with a valid address or with a Link Local address and I had left the SmartSDR window open on the PC form a previous boot, the SSDR screen locks up on any subsequent reboots of the FLEX 6500. This is not right IMO. I know you may not have had experience with the FLEX and SSDR - just noting it here for the FLEX guys.

b) Likewise, If I had left the SSDR Cat screen open (CAT running) on the desktop after a re-boot, SSRD Cat also is locked in a non responding state.

c) It seems that all the PCs on the entire LAN (wired or wireless) experience some delay when loading the first webpage in going to a new site. That is, often a "page not found" msg is displayed until I reload the page in the browser and then it immediately loads.

d) In my original msg (second post) I noted I rebooted the router with the reset button to a factory reset condition. I now find I had not done that correctly and the FIOS router was not reset. I may try a true factory reset later today.

I will also plan on using your suggestion of changing the DHCP router configuration. thanks for that info. Any other thoughts would also be appreciated.

Thanks, Ed

Photo of Mike KD2CJJ

Mike KD2CJJ

  • 122 Posts
  • 33 Reply Likes
Ed...you have given me some good info... Again I don't have a flex radio but I found a smoking gun based on your input....

To first comment on your a and b... This is a typical issue when dealing with a stateful application that doesn't manage state well in an unreliable network environment. This is compounded if they are using UDP...which mostly they are....(I would based on the nature of the application). Leaving any clients open when restarting the server depending on the state of the application and the state of session would result in a "hang"... They would need to put in better handling of this in both the client and server software....

C is normal...this is what I described... DHCP delay...the only way to resolve this is to provide static ip addresses on end points...even statically defining host to ip mapping in the router won't help...this just reserves the ip when a dhcp request is made...dhcp is still occurring though. When you statically define an ip on the end points the dhcp server will note this as a reserved ip (not all routers do this but the fios one does..nice feature) which avoids ip conflicts when some of the end points use dhcp and some use a static ip.

Now to your issue....
The IP address 192.168.1.103 is a "reserved" IP address for my "stb"s...set top boxes. On my network this would cause the same issue as your having. In your fios router go to advanced then IP address distribution...click on the action icon opening up the properties. Go to the bottom that says IP address distribution according to dhcp option 60... You should see the ip-stb.... My config shows these are reserved from 101 to 104... The number of boxes I have.

The ips are still being distributed via dhcp.... Why or how are they are reserving those ip addresses I am not sure... I have deleted them from the DNS server but they always come back to those ip addresses and reregister the host name with the DNS server on the router. (DNS server config is located under advanced then DNS server). If they were static on the stbs the DNS server would mark them as a static ip In the source column; they are listed as dhcp. You could try the suggestion I gave ... If a stb has that IP address of the flex, delete the entry and define (add) a DNS entry with the host name of the flex... This should reserve the ip... And hopefully the stb takes a different ip....
Of course if you can statically define the ip your issues will go away...all servers ideally should be static...dhcp is finicky in a server client environment.
Hopefully this long winded response helps...
Photo of Ed - NZ1Q

Ed - NZ1Q

  • 76 Posts
  • 6 Reply Likes

Mike, your info is very, very helpful.

Yes, I thought DHCP add .103 was strange for the flex to be using when all my other devices under 20. I have 2 stb's and they are .100 and .101, so there was no direct contention. However, there seemed to be an underlying issue with how the FLEX was receiving an assigned address. In working through the router settings as you mentioned I found:.

IP Add distribution has .100 to .150 reserved for stb

The connection list showed the FLEX MAC address with a link local address - strange.

The FLEX had a name of "New Host" at this point (with the FLEX MAC address).

In the Connection List, I edited the name to FLEX-6500.

Something seemed to change at that point and now in IP Distribution, FLEX is shown with add 192.168.1.8

I edited the FLEX further by clicking the  "Static Lease Type" box and now the FLEX shows "Static" in the IP DIst list along with the .8 address. From what you mentioned, This static reference may not mean much since I can't set the IP add in the FLEX to static.

At this point I've rebooted several times and the FLEX seems to now always be connecting on add .8

Will let you know if this has solved the problem.


Many thanks for all your help. Have a Great Memorial Weekend

Ed - NZ1Q

 PS - Let me know if you have any questions about the FLEX


Photo of Jon - KF2E

Jon - KF2E

  • 588 Posts
  • 171 Reply Likes
I believe by default DHCP clients always try to renew their current address. That said, since the Flex now has the .8 address and you have a server reservation for it, things *should* stay configured.

Jon