Miniserver thinks it's offline when it's not

[Rob_in]

Hi all,

So... I tweaked our LAN today which involved having to change the IP address of the default gateway, and as that number is set in the static network config on the Miniserver, that too. Well... what a royal PITA that is, but eventually it appears I got the values to stick. Side issue: what's this about not being able to change the network settings after the miniserver has been up over an hour? And why are there two different places to update this? And why did I have to tell it to save 3-4 times before it actually seemed to stick?

So during this time the Miniserver decided there was no internet connectivity. OK, fair enough. BUT... now the gateway is set to the correct IP and the Miniserver absolutely does have connectivity, the app says it does not. Moreover, I have some ping checks to various well know internet IPs and they are failing.

I absolutely guarantee our Internet connection is good, all the other boxes and devices on the LAN work perfectly. The Miniserver is accepting incoming connections from the Internet (port forwarded from our router of course) because when I disconnect my phone from the LAN and go with 4G data the app connects to the loxonecloud address just fine. Given our public IP address has recently changed this indicates the Miniserver has connected to Loxone servers OK and updated the loxonecloud stuff at the very least. Naturally, when I look at our internet router can see this inbound connection. Moreover, I can see the Miniserver making DNS requests out to the Internet!

This is very, very strange. Does anyone know precisely what the Miniserver does to figure out if it's on/offline? Are the ping requests I have setup disabled because it thinks it's offline (although I have to say that seems unlikely because I have ping checks on two hosts on the LAN and they are shown as 'alive' just fine). How can I force it to think it's online?

Cheers,

Robin

[breizhnos]

Hi Robin,

i've never seen such notice / alert on the miniserver ?!

can you show with screenshot how it provide this alert ?

[Rob_in]

It's in the System Status both on web and in the app:

Other notices disappear when acknowledged/cleared but this is sticking around.

I notice the Dark Sky weather forecast is being updated so that's something else that's working. Pings tests outside the LAN still aren't working though. Very odd.

There's a thing in Loxone Config that lets you disable this test apparently but don't want to do that. I suppose there's a tiny chance our firewall is blocking pings from the MS but I don't see how that could be happening as they work from everywhere else on the LAN.

Robin

[Rob_in]

So, I fired up TCP dump on our external internet router and set every packet from the external interface to my laptop for analysis in Wireshark. Filtering on ping requests one gets (click to enlarge):

*src is our public IP so masked due to paranoia ;)

First thing to notice is that Loxone are a bit lazy. No sequence numbers or data in the ping request. This implies they aren't checking these are correct on the response. Not that a response is coming back as can be seen.

At the same time I pinged 1.1.1.1 & 8.8.8.8 from another internal device and notice that is a longer request with a sequence and data part but also that a reply came back.

Stranger and stranger.

At least we now know what hosts the Miniserver is programmed to ping in order to determine an internet connection (1.1.1.1, 8.8.8.8, 9.9.9.9 & 8.8.4.4 are mine, the rest must be hardcoded in the Miniserver).

The length 42 requests to 8.8.8.8, 9.9.9.9 & 8.8.4.4 are originating in the Miniserver from a ping block I created to check connectivity myself (was unaware of the connectivity system variable when I did that).

The length 118 requests (the ones with replies) are coming from another device on our LAN as a secondary test.

Any ideas what on earth is going on here?

Robin

[David Wallis]

can you upload the pcap file? (I'm away until next week though as its our first wedding anniversary)

[David Wallis]

just thinking, wonder if an ARP cache needs clearing somewhere - can you see any ARP requests in the capture?

On Thursday, May 2, 2019 at 1:50:44 PM UTC+1, Rob_in wrote:

[Rob_in]

Hi,

Nope - nothing to do with ARP.

Experimenting a bit I have discovered that a ping from my laptop will not get a reply unless a data length of at least 12 bytes is specified. Eg:

$ ping -4 -c 4 -s 11 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 11(39) bytes of data.

^C

--- 8.8.8.8 ping statistics ---

4 packets transmitted, 0 received, 100% packet loss, time 109ms

$ ping -4 -c 4 -s 12 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 12(40) bytes of data.

20 bytes from 8.8.8.8: icmp_seq=1 ttl=123

20 bytes from 8.8.8.8: icmp_seq=2 ttl=123

20 bytes from 8.8.8.8: icmp_seq=3 ttl=123

20 bytes from 8.8.8.8: icmp_seq=4 ttl=123

--- 8.8.8.8 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 5ms

As the Miniserver sends zero data byte requests clearly that is the problem.

It is not my router though, because Wireshark on the external interface shows those short packets leaving (as shown in the previous screenshot). Perhaps something in the ISP side is doing this and will investigate that further as when I changed the default gateway on our LAN did modify the ISP box to act as a bridge instead of a router (to avoid double NAT).

To me this does count as a bug in the Miniserver though because it really should not be sending pings with no sequence or data packets - naturally I think 12 bytes or more is the go ;) - and not verifying the response comes back unchanged. How can I raise that with Loxone?

Cheers,

Robin