I searched the forum, but didn't find a close enough match to this issue based on what I read.
C-4 / C-5 Hubs crash on 'Loss of Internet'
C-4 running 126.96.36.199 configured w/ DHCP MAC reservation
C-5 running 188.8.131.52 configured w/ DHCP MAC reservation
*Both hubs are wired to the same switch
I use a Fing box (hardware / cloud service) to monitor my home's Internet health while away from home. Fing box records indicate there were five Internet outages over the last 30 days. (Thank you Metronet) Upon waking up or returning home from work, after all five of these occasions, I have found one or both of my hubs hung and not responsive to port 80 calls. Both hubs would accept port 8081 connections, which allowed me to safely reboot them.
In an effort to try and collect more data pertaining to the source of this problem, I have
begun the process of moving all Ethernet connected devices and services (local & Internet based) over to the C-5 and configure the C-4 for local Z-wave & Zigbee devices only. I am 95% done with this migration. I am hoping this migration may provide some additional details about the source of this problem.
For anyone familiar with the OSI model:
Is it possible I have a problem with upper OSI layer apps (native and or user) locking up if the Internet were to be lost during a communication cycle? I suspect that if I were to physically disconnect the Ethernet cable from the back of the Hub (layer 1 disruption), wait a few minutes and plug it back in that I wouldn't encounter a problem. Idk. I will try that tonight.
Anyone else observed this problem?
I do run the following apps:
- Amazon Echo Skill
- Several Cobra Apps
- Hue Bridge
- MyQ Lite ( Garage door opener)
- Sonos Integration
- Total Comfort API (Honey Wifi Thermostat)
- Sleep IQ Manager (Sleep IQ Bed sensors)
Basic OSI information outlined below
By definition on a layered model as OSI or TCP/IP each layer works independent and not-aware of the lower layers.
When you remove the cable, it's a physical disruption ( layer 1 ), so almost inmediately ethernet ( layer 2 ) detects a loss of signal (if you're on Windows you will see the very dreaded pop-up informing network disconnected )
IP ( layer 3 ) and TCP ( layer 4 ) won't notice it, so they will try to keep on working.
TCP won't break a established TCP connection during a period of time because when TCP sends data, it expects an ACK in reply and if it doesn't arrive within a period of time, it re-transmits the data.
TCP will re-transmit the data, passing it to IP, who will pass it to Ethernet, who is unable to send it and simply discard it.
TCP will be waiting again and repeating this process until a timeout happens that let it declares that the connection is over. TCP resets the segment sequence number, discard the information that was trying to send and let free the buffer and memory resources that were allocated for that connection.
Plug the cable in before it happens and everything will keep going. This is what makes TCP reliable and at the same time vulnerable to DDos attacks.
If the OS has more than one interface (for example, ethernet and wi-fi), it is possible that when the ethernet goes down, it will try through wifi. It depends how the routing is configured, but in general terms " TCP won't be aware of that ".