I recently went through Chime Hell when I attempted to add two chimes to my network earlier this week. In my case, I could get the units to boot, connect to them to get them set up, and then once I did that they would go through this painful cycle of flashing blue, solid green, solid blue, and then flashing red, and then apparently reboot to the flashing blue over and over and over again.
I went on my router and checked my DHCP logs and I could see the Chimes were both leasing IP addresses, so they were in fact connecting to my wireless network just fine.
I’m a network engineer with 35 year experience in IT. I placed a call to Ring’s 800 support to see if they had any ideas but frankly talking to the people there was useless. They all have the standard script and cannot deviate from the “let’s try to reset your chime” and “let’s try to move it closer to the router” – all of which, although I pointed this out to the support people – was completely useless since my chimes were, in fact, connecting to my wifi network and were leasing IP addresses.
I disabled my IPTables firewall and used ngrep to monitor network traffic from one of the Chimes. Then I saw this:
T(6) 192.168.10.129:54878 -> 34.228.137.201:9998 [AP] #16
16 03 03 00 77 01 00 00 73 03 03 49 b7 3f e5 a1 …w…s…I.?..
56 2f a1 1c fe 33 81 90 96 64 78 93 dc 32 95 39 V/…3…dx…2.9
30 85 5c c0 f8 0d 05 ce cb 97 1b 00 00 14 c0 14 0…
c0 11 00 39 00 35 00 05 00 04 00 3c 00 3d c0 27 …9.5…<.=.’
c0 23 01 00 00 36 00 0d 00 0c 00 0a 02 01 02 02 .#…6…
02 03 04 01 04 03 00 00 00 10 00 0e 00 00 0b 63 …c
68 2e 72 69 6e 67 2e 63 6f 6d 00 0a 00 0e 00 0c h.ring.com…
00 10 00 13 00 15 00 17 00 18 00 19 …
Voila, my problem was “solved”. The chimes communicate outbound on a specific IP port (9998) which I use both inbound and outbound for something else, so packets sent by the Chime were getting dropped into a black hole by my firewall since they didn’t originate from an IP address I had specifically coded to allow to communicate over port 9998. So I had to “move” my other device off 9998 (somewhat of a PITA) and change my firewall rules to allow outbound 9998 access and now both Chimes are up and running.
So, moral of the story is this: When you have a problem connecting a Chime to your network, grab the MAC address off the back of your Chime (it’s a 12-character number that looks like this: aa:bb:cc:dd:ee:ff) and then if at all possible visit your DHCP server and inspect the DHCP log to see if your Chime is in fact leasing an IP address. If it is leasing an address, your problem is not with the Chime connecting to your wireless network, but is “somewhere else” in the communication link back to the ring.com servers.
The ring servers they appear to communicate with are “ch.ring.com” (port 9998), “es.ring.com” (port 443) and “fw-ring.com” (port 443). From another computer, you can perform some basic network diagnostics, such as:
nslookup es.ring.com
(this will ensure your system is properly resolving the hostnames necessary to get the IP address of the remote servers)
ping fw-ch.ring.com
(this will tell you if the remote host is alive or not, assuming your ISP doesn’t filter out the ICMP traffic)
traceroute (or tracert) es.ring.com
(this will show the “route” on the internet the packets take to get to their servers, again, assuming your ISP doesn’ filter out this traffic)
and finally:
telnet hostname portnumber
e.g.
telnet ch.ring.com 9998
will attempt to establish a telnet connection to the server on the specified port number. If successful, telnet will connect and you’ll just get a blank screen. if you type anything, the connection will probably just close. If the connection doesn’t work, you’ll get a timeout error message.
Hope this helps some folks. Why Ring has to have their Chimes communicate outbound over a non-standard IP port (9998) rather than a standard port such as 443 like everyone else in the known universe is beyond me. Many, many ISPs these days filter outbound traffic on their networks which are communicating over non-standard ports to help prevent the proliferation of botnets.