Service shown in mesh status does not indicate when the service's host is offline

[AlyBadawy]

Currently, the list of advertised services are published and propagated to the OLSR based on being added to the services list on a given node.

Sometimes host for a service is no longer connected to a node and hence it shows false information to the network that a host is there but un-reachable.
I suggest that once a host is dropped from the DHCP leases' list, that such service "or host" is no longer published (or propagated) as a service to the network.

or if really has to be populated, maybe give an indicator (red/green dots) showing if the host has a current active lease.

73 de AL0Y

[ae6xe]

There are use cases where a LAN host is configured with a static IP address and does not receive a lease from the mesh node. This static IP device would never obtain a lease and would not be able to advertise a service if these symptoms were addressed by triggering off the dhcp lease.

I've updated the title to zero in on the problem or undesirable behavior. Maybe there are alternative options to implement without requiring all LAN devices use DHCP to obtain an address.

[AlyBadawy]

@ae6xe,
I think I totally forgot about the hosts that have static IPs. you are right, it won't be practical to look at the active DHCP leases then. Maybe the node can check periodically for whether the advertised services are reachable (pingable?) and if not, stops propagating them to OLSR.

Also, I am not sure I understand the second paragraph of your reply regarding the title.

[ae6xe]

My bad, I actually didn't get the title changed. Will change now... Idea being to focus on stating the failure. It's a common pit fall to state up front how to fix something, get focused on that fix, then overlook that there might be better ways to implement.

[ae6xe]

One option would be for the node that advertises a service, to 'ping' the host on its LAN and remove the service advertisement from OLSR accordingly. Check, say every 5 minutes. Alternatively, try to do a telnet (TCP) or nc (UDP/TCP) to the service port of this LAN host to see if it responds. A ping may be blocked by the host's firewall.

[r1de]

As Joe said in that last sentence... What about Windows Hosts? (RMS Relay)
You can't ping a windows machine anymore unless you open up the windows firewall to allow such.
(IIRC, even windows 7 did not allow ICMP ping by default)
And what if you "nc" or telnet into a service and it just waits for input... forever?

I think "peer pressure" (or Nagios and the like) is a better answer for this, there are just too many variables to contend with.

Also, to me this seems the same as issue aredn/aredn_ar71xx#106

[ae6xe]

The service on the localnode could be tested:

curl -s localhost:80 >/dev/null && echo Success. || echo Fail.
Success.

If fail, we know the service is down and can update service advertisement in OLSR, e.g. put - (dead) in the name. If success, we can ensure the advertisement is live again.