RIPv2 Use Cases – Specific Use Cases in Modern Network Engineering

Unifi are wireless Access Points (only)

Mesh is an inaccurate term for how they work, by the way(unless you put non-factory firmware on them). They CAN be configured in a "single-leaf" wireless uplink mode, but should not be (it cuts throughput by at least half .vs. wiring them all.) You seem to be saying they are all wired into a switch, so there is no "mesh" going on, simply provision of the SSID over multiple devices.

A common problem (not clear from the level of detail in your question) is people deploying them with WAY too much power and overloading the input stages of the client devices (especially if they get the UAP-LR because it's advertised to have "more range") - in MANY cases, performance is improved by turning power down. The link does not work unless the radio can also hear the client device, and UAP-LRs have a VERY small field of appropriate application.

That's one fork of possible issues/resolutions. The other is:

A "home type router/switch" is a wireless access point, a switch, and a router, typically including a DHCP server, DNS Server, etc.

So, if it works better with a "home-type router/switch" you might need a device to play the role of "router" though in fact your issue may be more DHCP/DNS than "actual routing." I'd suggest pfSense for the role, but there are many possible options.

What you need to understand about the IPv4 TTL or IPv6 Hop Limit value is that a router (supposed to be the end-host, too, for IPv4, but most OSes don't do this) will decrement the IPv4 TTL or IPv6 Hop Limit when it receives a packet, and it will discard the packet if it decrements to 0.

That means that a packet with a IPv4 TTL or IPv6 Hop Limit of 1 entering a router will result in the router discarding the packet because it will be decremented to 0.

For IPv4, see RFC 791, Internet Protocol:

The Time to Live is an indication of an upper bound on the lifetime of an internet datagram. It is set by the sender of the datagram and reduced at the points along the route where it is processed. If the time to live reaches zero before the internet datagram reaches its destination, the internet datagram is destroyed. The time to live can be thought of as a self destruct time limit.

-and-

Time to Live: 8 bits

This field indicates the maximum time the datagram is allowed to remain in the internet system. If this field contains the value zero, then the datagram must be destroyed. This field is modified in internet header processing. The time is measured in units of seconds, but since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.

-and-

Time to Live

The time to live is set by the sender to the maximum time the datagram is allowed to be in the internet system. If the datagram is in the internet system longer than the time to live, then the datagram must be destroyed.

This field must be decreased at each point that the internet header is processed to reflect the time spent processing the datagram. Even if no local information is available on the time actually spent, the field must be decremented by 1. The time is measured in units of seconds (i.e. the value 1 means one second). Thus, the maximum time to live is 255 seconds or 4.25 minutes. Since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.

Some higher level reliable connection protocols are based on assumptions that old duplicate datagrams will not arrive after a certain time elapses. The TTL is a way for such protocols to have an assurance that their assumption is met.

For IPv6 see RFC 2460, Internet Protocol, Version 6 (IPv6) Specification:

Hop Limit

8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero.

-and-

        if the IPv6 Hop Limit is less than or equal to 1 {
           send an ICMP Time Exceeded -- Hop Limit Exceeded in
           Transit message to the Source Address and discard the
           packet
        }
        else {
           decrement the Hop Limit by 1

           resubmit the packet to the IPv6 module for transmission
           to the new destination
        }

Notice that it says, "if the IPv6 Hop Limit is less than or equal to 1," the packet is discarded.

-and-

8.2 Maximum Packet Lifetime

Unlike IPv4, IPv6 nodes are not required to enforce maximum packet lifetime. That is the reason the IPv4 "Time to Live" field was renamed "Hop Limit" in IPv6. In practice, very few, if any, IPv4 implementations conform to the requirement that they limit packet lifetime, so this is not a change in practice. Any upper-layer protocol that relies on the internet layer (whether IPv4 or IPv6) to limit packet lifetime ought to be upgraded to provide its own mechanisms for detecting and discarding obsolete packets.

Edit:

Here is an example where I pinged the next-hop router VLAN interface, and then I pinged the router Loopback0 interface, with a TTL of 1. I received ICMP replies for every ping attempt, but the pings to the loopback expired in transit:

D:\>ping 198.18.1.1

Pinging 198.18.1.1 with 32 bytes of data:
Reply from 198.18.1.1: bytes=32 time<1ms TTL=128
Reply from 198.18.1.1: bytes=32 time<1ms TTL=128
Reply from 198.18.1.1: bytes=32 time<1ms TTL=128
Reply from 198.18.1.1: bytes=32 time<1ms TTL=128

Ping statistics for 198.18.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

D:\>ping -i 1 198.0.0.8

Pinging 198.0.0.8 with 32 bytes of data:
Reply from 198.18.1.1: TTL expired in transit.
Reply from 198.18.1.1: TTL expired in transit.
Reply from 198.18.1.1: TTL expired in transit.
Reply from 198.18.1.1: TTL expired in transit.

Ping statistics for 198.0.0.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),