Really spooky: Openhabian occasionally not reachable for one single device until reboot

1

I have Openhabian (Debian) running on Raspberry Pi 3B+

Occasionally (last time lets say after 5 days running Openhabian) one of my Smartphones can’t reach Openhabian through the network IP anymore at all. Not PaperUI or any other Webserver or Port, not even a Ping. Nothing is reachable as if the Openhabian doesn’t exists. Here are my findings:

  • Restarting the Smartphone is not solving it.
  • Changing the local IP of the Smartphone is not solving it.
  • Smartphone can still reach any other local network address. (e.G. Router Webserver, Diskstation Filesharing, Ping to every other Client, etc)
  • Every other Client (other smartphones or Computers) can reach Openhabian unrestricted.
  • Restarting the Router is not solving it.
  • TCPDUMP on Openhabian is not showing any incoming connection by the Smartphone. Every other incoming connection is shown correctly.
  • After rebooting Openhabian, it is reachable by the Smartphone again.
  • There was nothing changed on Openhabian which could explain this. (Firewall or IPTables were never touched by my)

I know this is pretty sure not an Openhab, nor an Openhabian issue, but maybe some network experts can tell me what to try if it happens again.

2

Did you try to access openhab service by name and / or IP address from your phone ?

3

IP. So I am even pretty sure that there was no mistake, since on every test I have just changed the last octave to see if other server/clients are reachable.

Smartphone:
ping 192.168.0.100 => (openhabian) not reachable
ping 192.168.0.110 => (diskstation) working
ping 192.168.0.171 => (Laptop) working
Laptop:
ping 192.168.0.100 => (openhabian) working
ping 192.168.0.110 => (diskstation) working
ping 192.168.0.172 => (Smartphone) working

After rebooting Openhabian, smartphone can reach openhabian again. Really spooky.

4

As you wrote that TCPDUMP does not show any incomming connection from the phone:

  • firewall / AV software on the smartphone ? Although this might not explain why it works again after a reboot of the Pi
  • any chance to do a TCPDUMP on your WLAN router to check if these requests reaches the router ( of course other requests must reach it as the other connections work )
5

No Firewall, nor AV Software. But I share your opposition. Its almost impossible to be caused by the phone.

Would be possible as OpenWRT is running on it. But will there be a TCPDump? Traceroute from any device to openhabian just shows one direct hopp. The Router should be working as an Switch on the LAN side. TCPDump should only show NAT traffic, am I right? Still the same opposition as your first question. Why is it the router if it works after rebooting openhabian.

Still spooky.

6

Can you ping your smartphone from the PI ?

7

Ups. didn’t tried that. Shame on me. Lets pause this topic until next time it happens.

8

Ok, no its getting clearer but still spooky. This time the Laptop couldnt reach openhabian in any way. After I connected by ssh from another device to openhabian and tried to ping the laptop, it took maybe 3 seconds (obviously longer than ususally) and the first ping to the laptop was returned. In the same time the Laptop could reach openhabian again. Checked the smartphone (from the first post) afterwards and it could also not reach Openhabian. Same procedure: pinged it from Openhabian, took 3 seconds, Ping was replied, Openhaiban was reachable by the Smartphone again too.

Something on Openhabian (Debian) is preventing any network traffic from some specific devices until it tries to contact them. Any clue what to search for on Google?

9

Openhabian blocked my laptop again after 20 Minutes. Same procedure. Use another device, connect by ssh. send ping from openhabian to laptop: Openhabian is reachable again.

10

ehternet or WLAN/wifi ?
Although you stated that you never touched the firewall is there any ? What is the output of

sudo iptables -L
11

WiFi dropping into powersave ?

1 Like
12

WiFi:

[13:39:46] root@smarthome:/home/openhabian# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

These are IPTables while its working. But I can check them again when it occurs again. But what should change them? And return it to normal after a ping? And lasts for days until reboot? Don’t think its the rules, it assume something deeper.

13

But its still reachable for other devices. Just one or two Devices are blocked.

14

ARP TTL on those ?

Just giving possible reasons. Won’t debug that for you.

15

I assumed Network kernel issues of Layer2 or 3 on Debian side. But TCPDump shows Layer2+

ARP? Thanks for the hint.Maybe have a look at the ARP cache will get me closer.

I would never ask for… :sweat_smile:

16

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.