Core: HomeKit: Stale TCP Sessions in CLOSE_WAIT

Created on 18 Sep 2018 · 14Comments · Source: home-assistant/core

Home Assistant release with the issue:

Last working Home Assistant release (if known):
0.77.3

Operating environment (Hass.io/Docker/Windows/etc.):

Hassbian

Component/platform:

Homekit

Description of problem:
Homekit component doesn't close gracefully end stale TCP Connections. Sessions remain in CLOSE_WAIT state endlessly. The session list builds over time until the RaspberryPi or Home Assistant is restarted.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

homekit:
# HomeKit Setup Code: 695-86-708 (as of 9/14/2018)
  auto_start: False
  filter:
    include_entities:
        - switch.lamp_switch
        - light.fireplace_lights_level
        - light.garage_lights_level
        - light.island_lights_level
        - light.movie_lights_level
        - light.office_lamp_level
        - light.office_switch_level
        - light.outside_lights_level
        - light.playroom_lights_level
        - light.overhead_lights_level
        - light.sink_light_level
        - light.table_lights_level
        - switch.basement_tv
        - switch.living_room_tv
        - scene.night_time_kitchen_lights
        - binary_sensor.garage_door_sensor
        - binary_sensor.garage_door_3rd_sensor
        - switch.ge_outdoor_2
        - cover.garage_door
        - cover.garage_door_3rd

Traceback (if applicable):

root@hassbian:/home/pi# netstat -al | grep -i close
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49888 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49766 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49875 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50067 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49589 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50519 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50762 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50184 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50565 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49173 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49897 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49669 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50731 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49826 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49686 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49418 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49617 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49392 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50470 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49943 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50205 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50459 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50679 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49599 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50378 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49721 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50349 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49447 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50586 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49930 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:49594 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50536 CLOSE_WAIT 
tcp        0      0 hassbian:51827          Tim-S-iPhone-X.lo:50076 CLOSE_WAIT

Additional information:

homekit stale waiting-for-reply

Source

timgiwo

Most helpful comment

This will probably be fixed with the next version of HAP-python. Unfortunately the releasedate is not yet determined.

cdce8p on 23 Oct 2018

👍2

All 14 comments

This will probably be fixed with the next version of HAP-python. Unfortunately the releasedate is not yet determined.

cdce8p on 23 Oct 2018

👍2

I noticed this fixed in 0.80.1.

timgiwo on 23 Oct 2018

👎1

How did you notice that? The bug hasn’t been resolved according to this:

https://github.com/ikalchev/HAP-python/issues/145

dmonagle on 23 Oct 2018

@timgiwo It might be the case that you don't experience issues anymore. However there hasn't been a bug fix yet.

Since I can't test it, my best guess is that this commit will fix it: https://github.com/ikalchev/HAP-python/commit/855577cfcde1bf2f8562caf9fbefda3e4fa8b497
We'll have to wait until the next version is released to see it, though.

cdce8p on 23 Oct 2018

👍1

In reference to #15675 , After upgrading to .80.0, I am still seeing No response on IOS devices and seeing stale socket messages in the log.

jr3us on 27 Oct 2018

I mistyped the version above, I did upgrade to .81.0. The same comments still apply regarding stale socket messages.

jr3us on 28 Oct 2018

I ran across this perl script that will 'finish' close the sockets in close wait state:

https://github.com/rghose/kill-close-wait-connections

Before using this utility, I had almost 1000 sockets in close_wait. This perl script removes 50 sockets per issuance. There are now only 3 sockets in close wait state at this time.

I also ran across the following information regarding sockets in close_wait:

"CLOSE_WAIT means that the local end of the connection has received a FIN from the other end, but the OS is waiting for the program at the local end to actually close its connection.

The problem is your program running on the local machine is not closing the socket. It is not a TCP tuning issue. A connection can (and quite correctly) stay in CLOSE_WAIT forever while the program holds the connection open.

Once the local program closes the socket, the OS can send the FIN to the remote end which transitions you to LAST_ACK while you wait for the ACK of the FIN. Once that is received, the connection is finished and drops from the connection table (if your end is in CLOSE_WAIT you do not end up in the TIME_WAIT state)."

jr3us on 31 Oct 2018

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

balloobbot on 5 Feb 2019

This is still occuring

iCarl on 8 Feb 2019

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.