Anyone out there seeing issues with Belkin routers connecting?
I have also noticed that Belkins website has 80 percent packet loss and their support number is busy.
Luke Parrish | Network Operations Engineer I | Suddenlink Communications | 866.232.5455
Seeing reports bounce around on the WISPA lists. Looks to be widespread.
Reports on their twitter as well.
I've had one customer with an issue related thus far.
Nick Olsen
Network Operations (855) FLSPEED x106
https://twitter.com/search?q=%23belkin
Sounds like a bad firmware update most likely.
Presumably the Belkin routers perform caching DNS for the LAN clients for if the LAN clients use alternate DNS servers (OpenDNS, Google, your ISPs, etc) there are no longer any issues for those devices, as reported by several random people on the Internet.
Over on outages, someone mentioned that heartbeat.belkin.com was unreachable from some areas, and that was causing their routers to shut down.
Cheers,
Steve
Geesh. It was a tough day - lots of our customers with Belkin devices. Agree it has been fixable with customer changes but would have been better not to have to respond to this today (obviously).
Regards,
Jason
Jason Livingood
Comcast - Internet Services
Looks like belkin¹s fix was to add different records.
DNS response this morning.
heartbeat.belkin.com. 4h14m31s IN A 67.20.176.130
DNS response this evening.
dig heartbeat.belkin.com +short
54.163.115.57
23.20.47.97
54.227.172.225
54.161.217.33
54.163.87.225
54.87.220.73
54.163.74.132
54.83.179.150
54.196.247.165
54.163.72.1
54.87.180.46
54.242.182.61
174.129.92.187
Sounds like it might have been a DNS issue of some sort. The end result was
that the customer routers couldn't reach their heartbeat server, which made
them think they weren't on the net. The routers would then be "helpful" and
redirect all customer port 80 traffic to the router's configuration page to
correct the "problem".
It was a big mess that hopefully doesn't happen again. They've been making
changes to their DNS this afternoon. Looks like they finally have it
straightened out.
John
And this, my friends, is why friends don't let friends buy Belkin...
Apparently, you still can't fix stupid, no matter how hard you try.
-Mike
While we weren't really impacted by this issue, my understanding is that
the Belkin devices ping 'heartbeat.belkin.com' periodically. If their
pings fail, they do DNS redirection to the device's configuration
interface and alert the user of the error.
It appears that this server went down or had some sort of network issue,
causing the redirect to kick in and users to be unable to access the
Internet.
Any solution that either a) avoids the router's DNS redirection or b)
cause its pings to succeed would restore service.
It looks like Belkin has now re-implemented this service on top of a
DNS-cluster of AWS instances, so I think users are probably back online
now, as the IPs in the initial reports were not AWS and are no longer in
the DNS.
Workarounds include:
a) Add the IP(s) of the heartbeat server as loopbacks on a server/router
within your (service provider) network that will respond to the echos
for your customers
b) Add the hostname 'heartbeat.belkin.com' to the router's host file as
127.0.0.1
c) Modify the DNS configuration of client machines or the Belkin DHCP server
K
Seems like a dubious idea to equate "can't reach heartbeat server"
with "not on the net at all". At the very least, I'd add a second
clause "I have no reachable default route, and I must scream".
And this, my friends, is why friends don't let friends buy Belkin...
Amen.
Side question? What happens is somebody is unwise to use Belkin routers on an internal, not-connected-to-the-Interatubes network (Like, for example, the network I tried to get ex-employer to install to serve the un-patched Windows 98 heart monitors and stuff that were favored targets of the crackers.
I am having trouble understanding why a router would need a heartbeat from some foreign location. Or even what it would do with one.
One, not crazy, line of thinking is that: "Instead of being cryptic
and difficult to understand, help the customer to know that: "your dsl
is boarked" and that offloading that call set from the ISP for
something that might be simple to fix at the CPE might make the ISP
folk happy.
Of course that decision process came with the decision to run a
reliable and always-on service...oops.
I am having trouble understanding why a router would need a heartbeat
from
some foreign location. Or even what it would do with one.One, not crazy, line of thinking is that: "Instead of being cryptic
and difficult to understand, help the customer to know that: "your dsl
is boarked" and that offloading that call set from the ISP for
something that might be simple to fix at the CPE might make the ISP
folk happy.
That would be not-crazy if there were congruence with "DSL borked" and
"host unreachable."
Of course that decision process came with the decision to run a
reliable and always-on service...oops.
Clever!
Lee
I am having trouble understanding why a router would need a heartbeat
from
some foreign location. Or even what it would do with one.One, not crazy, line of thinking is that: "Instead of being cryptic
and difficult to understand, help the customer to know that: "your dsl
is boarked" and that offloading that call set from the ISP for
something that might be simple to fix at the CPE might make the ISP
folk happy.That would be not-crazy if there were congruence with "DSL borked" and
"host unreachable."
but see point 2 ... they were supposed to run a reliable always-on
service.. oh, wait ,that's what you meant 
(this plan didn't get to
step3 - profit!)