Mesh11sd: Internet (not connection) drops in 4.0.1

Done! :slight_smile: I turned everything off, turned on green, waited for it to fully boot, then turned on red-2 (which is also fully booted up now). All other nodes are turned off still.

EDIT: also my computer roamed. It was connected to green first, then switched to red-2 once that became available.

Yes, it is unstable due to the fact the nodes are all very close together in a confined space with lots of microwave reflections.

It might be better to reflash with
uci set mesh11sd.setup.mesh_leechmode_enable='1'
added to the uci-defaults and then turn off leechmode just on green, after it boots up...

Happy to do that. Should I then also swap wpad-mesh-mbedtls for wpad-mbedtls?

Like so:
Installed Packages

base-files busybox ca-bundle dnsmasq dropbear firewall4 fstools kmod-gpio-button-hotplug kmod-leds-gpio kmod-mt7915-firmware kmod-nft-offload libc libgcc libustream-mbedtls logd luci mtd netifd nftables odhcp6c odhcpd-ipv6only opkg ppp ppp-mod-pppoe procd procd-seccomp procd-ujail uboot-envtools uci uclient-fetch urandom-seed urngd -wpad-basic-mbedtls wpad-mbedtls kmod-nft-bridge mesh11sd

Script to run on first boot (uci-defaults)

uci set mesh11sd.setup.auto_config='1'
uci set mesh11sd.setup.auto_mesh_id='redacted'
uci set mesh11sd.setup.mesh_gate_encryption='2'
uci set mesh11sd.setup.mesh_gate_key='redacted'
uci set mesh11sd.setup.ssid_suffix_enable='0'
uci set mesh11sd.setup.mesh_leechmode_enable='1'
uci commit mesh11sd
uci set network.lan.ipaddr='192.168.1.2'
uci commit network
uci set wireless.radio0.country='DE'
uci set wireless.radio0.channel='11'
uci set wireless.radio1.country='DE'
uci set wireless.default_radio0.ssid='CF-WiFi-HOME-2.4G'
uci set wireless.default_radio0.ieee80211r='1'
uci set wireless.default_radio0.mobility_domain='12ab'
uci set wireless.default_radio1.ssid='CF-WiFi-HOME'
uci set wireless.default_radio1.ieee80211r='1'
uci set wireless.default_radio1.mobility_domain='12ab'
uci commit wireless
rootpassword="redacted"
/bin/passwd root << EOF
$rootpassword
$rootpassword
EOF

Yes, even if it turns out it is not needed, it will not do any harm - it just takes up a bit more space.

Once done we will have to turn off leechmode on Green.

1 Like

Alright done, both are flashed with the new firmware. How do I turn off lech mode on green and what are the next steps? Should I restart the other four and flash them, too?

Actually, you should use a different subnet for this.
eg 192.168.9.1. It will most likely never be used, but just in case you ever connect up the wan port on any of them (case 1).

But I see you have already reflashed, so never mind.

ssh to green.
You will most likely see it has connected to node 2, but it will eventually time out because HWMP multicast is disables in leechmode.

Disable leechmode on green:

service mesh11sd stop
uci set mesh11sd.setup.mesh_leechmode_enable='0'
uci commit mesh11sd
service mesh11sd start; exit

On green, run:

mesh11sd debuglevel 3
logread -e mesh11sd -f

This will give you updating hop status.

No I want to do it right, so I reflashed. :slight_smile:

Done.

I can't SSH to green anymore, even when directly connected to it's WiFi. I'll try via ethernet cable.

EDIT: nevermind it worked via SSHing to red-2, then running mesh11sd connect 56-83-3a-7d-ac-48. I ran both mesh11sd debuglevel 3 and logread -e mesh11sd -f, here is the output of the later:

Mon Jun 10 09:59:27 2024 daemon.debug mesh11sd[10513]: interface m-11s-0 is up
Mon Jun 10 09:59:28 2024 daemon.debug mesh11sd[10513]: node [DEST,ADDR]
Mon Jun 10 09:59:28 2024 daemon.debug mesh11sd[10513]: node [56:83:3a:79:ac:78,56:83:3a:79:ac:78]
Mon Jun 10 09:59:28 2024 daemon.debug mesh11sd[10513]: Entering check portal.... lan
Mon Jun 10 09:59:28 2024 daemon.debug mesh11sd[10513]: In get_portal_state. firstloop=0...
Mon Jun 10 09:59:28 2024 daemon.debug mesh11sd[10513]: default_gw=default via 192.168.1.1 dev br-lan ....
Mon Jun 10 09:59:29 2024 daemon.debug mesh11sd[10513]: leaving get_portal_state - is_portal=.. gwstatus=.. gw_ip=192.168.1.1..
Mon Jun 10 09:59:29 2024 daemon.debug mesh11sd[10513]: checking for working channel....
Mon Jun 10 09:59:33 2024 daemon.debug mesh11sd[10513]: portal not detected
Mon Jun 10 09:59:33 2024 daemon.debug mesh11sd[10513]: Entering scan channel....
Mon Jun 10 09:59:39 2024 daemon.debug mesh11sd[10513]: portal not detected
Mon Jun 10 09:59:39 2024 daemon.debug mesh11sd[10513]: Entering scan channel....
Mon Jun 10 09:59:40 2024 daemon.debug mesh11sd[10513]: Leaving check portal....
Mon Jun 10 09:59:41 2024 daemon.info mesh11sd[10513]: Path to station [ 56:83:3a:79:ac:78 ] is stable
Mon Jun 10 09:59:41 2024 daemon.debug mesh11sd[10513]: checkinterval 10 seconds

This shows the path from green to red1 is a single hop and active.

This shows the path is stable.

So now reflash all the others and turn them on.

Hint: if you run ip addr on any node it will give you both the ipv4 address and the ipv6 link-local address (begins with "fe80::")

Alright, done! They're all online, but it's very hard to reach any of the nodes via SSH.

EDIT: OK my mistake. It's impossible to reach green because it has a different IP address from the fixed one assigned to it based on MAC address before. Oddly, the others still have the same MAC address (and were therefore assigned the same IP). Green has a different one (see above: has 56:83:3a:7d:ac:48 now, had 54:83:3a:79:ac:48 before).

Unfortunately logread -e mesh11sd -f from green times out now with all nodes online, but I can provide mesh11sd status:

{
  "setup":{
    "version":"4.0.1",
    "enabled":"1",
    "procd_status":"running",
    "portal_detect":"1",
    "portal_detect_threshold":"0",
    "portal_channel":"default",
    "channel_tracking_checkinterval":"30",
    "mesh_basename":"m-11s-",
    "auto_config":"1",
    "auto_mesh_network":"lan",
    "auto_mesh_band":"2g40",
    "auto_mesh_id":"1459903d4802e2ef06b29aef8abf21",
    "mesh_gate_enable":"1",
    "mesh_leechmode_enable":"0",
    "mesh_gate_encryption":"2",
    "txpower":"20",
    "mesh_path_cost":"10",
    "mesh_path_stabilisation":"1",
    "checkinterval":"10",
    "interface_timeout":"10",
    "ssid_suffix_enable":"0",
    "debuglevel":"1"
  },
  "interfaces":{
    "m-11s-0":{
      "mesh_retry_timeout":"100",
      "mesh_confirm_timeout":"100",
      "mesh_holding_timeout":"100",
      "mesh_max_peer_links":"16",
      "mesh_max_retries":"3",
      "mesh_ttl":"31",
      "mesh_element_ttl":"31",
      "mesh_auto_open_plinks":"0",
      "mesh_hwmp_max_preq_retries":"4",
      "mesh_path_refresh_time":"1000",
      "mesh_min_discovery_timeout":"100",
      "mesh_hwmp_active_path_timeout":"5000",
      "mesh_hwmp_preq_min_interval":"10",
      "mesh_hwmp_net_diameter_traversal_time":"50",
      "mesh_hwmp_rootmode":"2",
      "mesh_hwmp_rann_interval":"5000",
      "mesh_gate_announcements":"1",
      "mesh_fwding":"1",
      "mesh_sync_offset_max_neighor":"50",
      "mesh_rssi_threshold":"-65",
      "mesh_hwmp_active_path_to_root_timeout":"6000",
      "mesh_hwmp_root_interval":"5000",
      "mesh_hwmp_confirmation_interval":"2000",
      "mesh_power_mode":"active",
      "mesh_awake_window":"10",
      "mesh_plink_timeout":"0",
      "mesh_connected_to_gate":"1",
      "mesh_nolearn":"0",
      "mesh_connected_to_as":"0",
      "mesh_id":"1459903d4802e2ef06b29aef8abf21",
      "device":"radio0",
      "channel":"11",
      "tx_packets":"260566",
      "tx_bytes":"147956786",
      "rx_packets":"162920",
      "rx_bytes":"82421745",
      "this_node":"54:83:3a:79:ac:48",
      "active_peers":"5",
      "peers":{
        "d6:1a:d1:12:af:20":{
          "next_hop":"d6:1a:d1:12:af:20",
          "hop_count":"1",
          "path_change_count":"1",
          "metric":"77"
        },
        "d6:1a:d1:12:af:1c":{
          "next_hop":"d6:1a:d1:12:af:1c",
          "hop_count":"1",
          "path_change_count":"1",
          "metric":"23"
        },
        "56:83:3a:79:bd:58":{
          "next_hop":"56:83:3a:79:bd:58",
          "hop_count":"1",
          "path_change_count":"1",
          "metric":"64"
        },
        "56:83:3a:79:ac:3c":{
          "next_hop":"56:83:3a:79:ac:3c",
          "hop_count":"1",
          "path_change_count":"1",
          "metric":"23"
        },
        "56:83:3a:79:ac:78":{
          "next_hop":"56:83:3a:79:ac:78",
          "hop_count":"1",
          "path_change_count":"3",
          "metric":"22"
        }
      },
      "active_stations":"15",
      "stations":{
        "60:3e:5f:38:56:60":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "3c:2a:f4:41:21:4d":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "04:0e:3c:5e:1a:d0":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "78:28:ca:81:a3:7c":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "4c:b9:ea:07:27:ac":{
          "proxy_node":"d6:1a:d1:12:af:1c"
        },
        "7c:bb:8a:ae:00:c6":{
          "proxy_node":"56:83:3a:79:ac:3c"
        },
        "a4:e5:7c:c0:83:a4":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "ec:0d:51:00:3c:65":{
          "proxy_node":"56:83:3a:79:ac:3c"
        },
        "78:28:ca:81:a3:66":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "34:7e:5c:34:61:b6":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "f0:b3:ec:07:6a:cc":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "48:a6:b8:bd:57:aa":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "2c:cf:67:06:52:b2":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "60:f2:62:0e:d6:66":{
          "proxy_node":"56:83:3a:79:ac:78"
        },
        "34:7e:5c:34:5f:64":{
          "proxy_node":"56:83:3a:79:ac:78"
        }
      }
    }
  }
}

and mesh11sd stations:

===========================================================================
Stations connected to this node:
Station 56:83:3a:79:ac:78 (on m-11s-0)
	inactive time:	0 ms
	rx bytes:	9298264
	rx packets:	45775
	tx bytes:	16905410
	tx packets:	33163
	tx retries:	0
	tx failed:	0
	rx drop misc:	10
	signal:  	-54 [-54, -62] dBm
	signal avg:	-53 [-53, -59] dBm
	Toffset:	13460383131 us
	tx bitrate:	390.0 MBit/s 40MHz HE-MCS 8 HE-NSS 2 HE-GI 1 HE-DCM 0
	tx duration:	14978124 us
	rx bitrate:	413.0 MBit/s 40MHz HE-MCS 8 HE-NSS 2 HE-GI 0 HE-DCM 0
	rx duration:	2249048 us
	last ack signal:-51 dBm
	avg ack signal:	-51 dBm
	airtime weight: 256
	mesh llid:	0
	mesh plid:	0
	mesh plink:	ESTAB
	mesh airtime link metric: 22
	mesh connected to gate:	yes
	mesh connected to auth server:	no
	mesh local PS mode:	ACTIVE
	mesh peer PS mode:	ACTIVE
	mesh non-peer PS mode:	ACTIVE
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		yes
	TDLS peer:	no
	DTIM period:	2
	beacon interval:100
	connected time:	803 seconds
	associated at [boottime]:	64.712s
	associated at:	1718024508345 ms
	current time:	1718025311194 ms
Station d6:1a:d1:12:af:1c (on m-11s-0)
	inactive time:	90 ms
	rx bytes:	2151238
	rx packets:	20324
	tx bytes:	1198369
	tx packets:	7031
	tx retries:	0
	tx failed:	0
	rx drop misc:	2
	signal:  	-47 [-49, -51] dBm
	signal avg:	-47 [-48, -51] dBm
	Toffset:	1401440392 us
	tx bitrate:	433.3 MBit/s 40MHz HE-MCS 9 HE-NSS 2 HE-GI 1 HE-DCM 0
	tx duration:	4210274 us
	rx bitrate:	458.8 MBit/s 40MHz HE-MCS 9 HE-NSS 2 HE-GI 0 HE-DCM 0
	rx duration:	898233 us
	last ack signal:-48 dBm
	avg ack signal:	-48 dBm
	airtime weight: 256
	mesh llid:	0
	mesh plid:	0
	mesh plink:	ESTAB
	mesh airtime link metric: 19
	mesh connected to gate:	yes
	mesh connected to auth server:	no
	mesh local PS mode:	ACTIVE
	mesh peer PS mode:	ACTIVE
	mesh non-peer PS mode:	ACTIVE
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		yes
	TDLS peer:	no
	DTIM period:	2
	beacon interval:100
	connected time:	802 seconds
	associated at [boottime]:	66.404s
	associated at:	1718024510038 ms
	current time:	1718025311196 ms
Station 56:83:3a:79:ac:3c (on m-11s-0)
	inactive time:	0 ms
	rx bytes:	88215319
	rx packets:	142286
	tx bytes:	136614840
	tx packets:	189785
	tx retries:	0
	tx failed:	0
	rx drop misc:	10
	signal:  	-51 [-56, -52] dBm
	signal avg:	-53 [-57, -54] dBm
	Toffset:	1724886313 us
	tx bitrate:	325.0 MBit/s 40MHz HE-MCS 7 HE-NSS 2 HE-GI 1 HE-DCM 0
	tx duration:	285902156 us
	rx bitrate:	413.0 MBit/s 40MHz HE-MCS 8 HE-NSS 2 HE-GI 0 HE-DCM 0
	rx duration:	9713179 us
	last ack signal:-53 dBm
	avg ack signal:	-53 dBm
	airtime weight: 256
	mesh llid:	0
	mesh plid:	0
	mesh plink:	ESTAB
	mesh airtime link metric: 25
	mesh connected to gate:	yes
	mesh connected to auth server:	no
	mesh local PS mode:	ACTIVE
	mesh peer PS mode:	ACTIVE
	mesh non-peer PS mode:	ACTIVE
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		yes
	TDLS peer:	no
	DTIM period:	2
	beacon interval:100
	connected time:	801 seconds
	associated at [boottime]:	66.881s
	associated at:	1718024510515 ms
	current time:	1718025311198 ms
Station 56:83:3a:79:bd:58 (on m-11s-0)
	inactive time:	2460 ms
	rx bytes:	2443796
	rx packets:	22306
	tx bytes:	5068525
	tx packets:	42233
	tx retries:	0
	tx failed:	0
	rx drop misc:	0
	signal:  	-65 [-69, -67] dBm
	signal avg:	-65 [-69, -67] dBm
	Toffset:	1250171862 us
	tx bitrate:	292.5 MBit/s 40MHz HE-MCS 6 HE-NSS 2 HE-GI 1 HE-DCM 0
	tx duration:	19913694 us
	rx bitrate:	309.7 MBit/s 40MHz HE-MCS 6 HE-NSS 2 HE-GI 0 HE-DCM 0
	rx duration:	3648349 us
	last ack signal:-65 dBm
	avg ack signal:	-64 dBm
	airtime weight: 256
	mesh llid:	0
	mesh plid:	0
	mesh plink:	ESTAB
	mesh airtime link metric: 34
	mesh connected to gate:	yes
	mesh connected to auth server:	no
	mesh local PS mode:	ACTIVE
	mesh peer PS mode:	ACTIVE
	mesh non-peer PS mode:	ACTIVE
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		yes
	TDLS peer:	no
	DTIM period:	2
	beacon interval:100
	connected time:	799 seconds
	associated at [boottime]:	68.581s
	associated at:	1718024512215 ms
	current time:	1718025311200 ms
Station d6:1a:d1:12:af:20 (on m-11s-0)
	inactive time:	3830 ms
	rx bytes:	1764249
	rx packets:	15603
	tx bytes:	626790
	tx packets:	4282
	tx retries:	0
	tx failed:	0
	rx drop misc:	1
	signal:  	-68 [-69, -72] dBm
	signal avg:	-68 [-69, -72] dBm
	Toffset:	907860084 us
	tx bitrate:	130.0 MBit/s 40MHz HE-MCS 3 HE-NSS 2 HE-GI 1 HE-DCM 0
	tx duration:	4584272 us
	rx bitrate:	206.4 MBit/s 40MHz HE-MCS 4 HE-NSS 2 HE-GI 0 HE-DCM 0
	rx duration:	524880 us
	last ack signal:-70 dBm
	avg ack signal:	-69 dBm
	airtime weight: 256
	mesh llid:	0
	mesh plid:	0
	mesh plink:	ESTAB
	mesh airtime link metric: 84
	mesh connected to gate:	no
	mesh connected to auth server:	no
	mesh local PS mode:	ACTIVE
	mesh peer PS mode:	ACTIVE
	mesh non-peer PS mode:	ACTIVE
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		yes
	TDLS peer:	no
	DTIM period:	2
	beacon interval:100
	connected time:	641 seconds
	associated at [boottime]:	226.954s
	associated at:	1718024670588 ms
	current time:	1718025311202 ms
===========================================================================

Only impossible because you don't know what it is....

Can you ssh into any of the others?

No no I know which one it was, I checked the leases (and then reassigned it to the correct one using the new MAC address ;)). The result is in the edit of my last comment.

EDIT I can SSH into any of them now. :slight_smile:

Cool!
But does the mesh work? Do your various devices get Internet access?
We still need to check rssi and txpower settings.

logread should not time out. Problem here is you never know which access point you are connecting to.... and the mesh needs a few minutes to settle down, perhaps that was the problem.

The lowest signal average is -68dBm - a bit low so could drop out of the mesh.

Red3 has a good signal so perhaps turn off leech mode on it so it can contribute to the mesh.
Then we can adjust rssid/txpower if needed.

So I went to LuCi - Software - Update list for each node and it worked, so they have Internet access. :slight_smile:

logread did not time out with a message, just took forever and then only printed:

Mon Jun 10 13:58:27 2024 daemon.notice mesh11sd[1981]: Station [ d6:1a:d1:12:af:20 ] is an immediate neighbour, but has had [ 3 ] path_change(s) detected
Mon Jun 10 14:00:41 2024 daemon.notice mesh11sd[1981]: Station [ d6:1a:d1:12:af:1c ] is an immediate neighbour, but has had [ 3 ] path_change(s) detected
Mon Jun 10 14:38:34 2024 daemon.notice mesh11sd[1981]: Station [ d6:1a:d1:12:af:20 ] is an immediate neighbour, but has had [ 5 ] path_change(s) detected
Mon Jun 10 14:44:50 2024 daemon.notice mesh11sd[1981]: Station [ 56:83:3a:79:ac:78 ] is an immediate neighbour, but has had [ 5 ] path_change(s) detected
Mon Jun 10 15:02:27 2024 daemon.notice mesh11sd[1981]: Station [ 56:83:3a:79:ac:3c ] is an immediate neighbour, but has had [ 3 ] path_change(s) detected
Mon Jun 10 15:08:41 2024 daemon.notice mesh11sd[1981]: Station [ d6:1a:d1:12:af:20 ] is an immediate neighbour, but has had [ 6 ] path_change(s) detected
Mon Jun 10 15:08:42 2024 daemon.notice mesh11sd[1981]: Station [ 56:83:3a:79:ac:78 ] is an immediate neighbour, but has had [ 7 ] path_change(s) detected
Mon Jun 10 15:08:55 2024 daemon.notice mesh11sd[1981]: Station [ d6:1a:d1:12:af:20 ] is an immediate neighbour, but has had [ 7 ] path_change(s) detected

I turned off leech mode on red 3 as requested.

Do your user devices connect to the Internet?
We still might need to adjust rssi and tx... Or please your wife and remove all but green and red3 :scream::rofl:

So far, yes. I didn't need to re-connect my WiFi ever since we enabled leech-mode for all nodes but green (and later red 3) and roaming appears to be working as well.
However, the devices keep changing MAC addresses sometimes, so it's hard to monitor them on a dashboard or log into the web interfaces consistently (or connect via SSH).

So I wouldn't mind optimizing further, I'm learning a lot in the process, too.

Actually this is a bug in the implementation of DSA in OpenWrt in some devices where every virtual interface comes up with the same mac address. For HWMP and mesh bridge loop blocking to work correctly, all interfaces must have a different mac. Mesh11sd fixes this but on booting, sometimes the mesh establishes before the mac is updated and the network sees the duplicated mac first and it takes a few minutes to time out. Thereafter you should not see the incorrect one again until perhaps there is a reboot or mesh11sd restart.

FYI - The generated mac address is always recognisable (unlike randomised macs) as it is based on the DSA address but has the "locally administered" bit set plus possibly an index in the 4th octet. This usually means the second hex digit in the first octet is a 6.

By the way, Luci cannot be used to modify, or even reliably view the mesh configuration. This is because the mesh config is dynamic and kept in the uci volatile storage area and can change over time, whereas Luci configs are completely static.

mesh11sd connect should work just fine once the mesh has settled down. FYI it uses SSH on ipv6.

The trouble with ipv6 is that it that the addresses are not human friendly ie very hard to remember....

mesh11sd connect lists the mac addresses and ipv6 addresses in a table.....

You could take a note of these and make an ssh login script of some kind for your computer, but I find it unnecessary.

Once you get back into Green node, you could look at ip addr to get the ipv4 address.

When you get to a point of being able to ssh into a node we can look to see if any optimisation is required.

1 Like

I noted all the ipv6 addresses but I cannot log into them via SSH. I does work however via ipv4 and I also have all the addresses noted.

FYI: this morning I woke up with no Internet (but connected to WiFi). The connection worked fine last night and must have worked until at least about 5 am (where I received an email). I then had to manually reconnect. The bedroom is at red. Possibly related, red 3 was the only node to switch MAC address from yesterday to today.

This can only happen if mesh11sd is restarted, or the node reboots and if it does, then it will only be a short term transient.

What does uptime show for that node?
Also, are there any errors in the output of dmesg?

From your previous example:

Here, note that the first octet "54", changes to "56" ie the mac is changed to a "locally administered" address (indicated by the 6 replacing the 4).
Note also that the fourth octet has changed from "79" to "7d" as the mac is also indexed to make sure all virtual interfaces have unique mac addresses.

You mean you had to disconnect then reconnect to get Internet access?

Typically a user device eg smart phone, tablet etc. will put its wireless interface in sleep mode when inactive, periodically waking up and checking email Facebook or what ever. If during this sleep period the dhcp lease expires, the ip will not be renewed. Depending on the device's operating system (ios, android etc) it may not renew when waking up, instead typically complaining it does not have Internet access in the usual way (this is the captive portal detection (CPD) of the ios/android device coming into play).
A disconnect/reconnect sequence will force an immediate dhcp request. Without this disconnect/reconnect, you will eventually get a reconnection when the CPD refresh interval expires (varies with ios/android versions and can be a few hours in some cases).

1 Like