Other Parts Discussed in Thread: CC3200
Setup -
The CC3220-LaunchPad connecting to an Access Point using Enterprise Security (EAP-TLS) .
SDK: simplelink_cc32xx_sdk_3_20_00_06
We are sending SNTP requests every 30 seconds in an attempt to try and catch when the CC3220 (NWP) stops sending NTP Server Requests or DHCP Client Request/Renew messages, observe the following.
Watching the management messages (EAP/Re-keying) traffic on wlan0, we see the following EAP Traffic:
...
21:29:01.868898 EAPOL key (3) v1, len 95
21:39:01.921708 EAPOL key (3) v1, len 95 <== EAP Traffic at this point (wlan0)
21:39:07.657219 EAP packet (0) v1, len 26
21:39:07.858234 EAP packet (0) v1, len 62
21:39:08.062133 EAP packet (0) v1, len 6
21:39:08.386689 EAP packet (0) v1, len 1408
21:39:08.470785 EAP packet (0) v1, len 117
21:39:08.678694 EAP packet (0) v1, len 6
21:39:08.883197 EAPOL key (3) v1, len 117
21:39:08.883334 EAPOL key (3) v1, len 117
21:39:08.886734 EAPOL key (3) v1, len 95
On the CC3220-LaunchPad, debug printing indicates the SNTP return code -107 (Failed to receive the new time from the NTP server) from the call to SNTP_getTimeByAddr - the request though was never sent out (see below).
Note: SNTP and DHCP Request/Renew stop working/originating after the time of the EAP Traffic:
...
last event: 1 queue ret: -1 depth: 0
retval: 0 Current time: Wed Nov 6 21:38:24 2019
last event: 1 queue ret: -1 depth: 0
retval: 0 Current time: Wed Nov 6 21:38:54 2019
last event: 1 queue ret: -1 depth: 0
retval: -107 Current time: Wed Nov 6 21:39:34 2019 <== SNTP Stopped working (Sending) – see trace above and below
last event: 1 queue ret: -1 depth: 0
retval: -107 Current time: Wed Nov 6 21:40:14 2019
last event: 1 queue ret: -1 depth: 0
retval: -107 Current time: Wed Nov 6 21:40:54 2019
A tcpdump of traffic received from the cc3220 on the access point indicates nothing being received at/after this time:
...
21:37:54.452547 IP 192.168.100.74.57266 > 192.168.100.1.123: NTPv4, Client, length 48
21:37:54.452797 IP 192.168.100.1.123 > 192.168.100.74.57266: NTPv4, Server, length 48
21:38:24.574229 IP 192.168.100.74.50306 > 192.168.100.1.123: NTPv4, Client, length 48
21:38:24.574490 IP 192.168.100.1.123 > 192.168.100.74.50306: NTPv4, Server, length 48
21:38:29.581690 ARP, Request who-has 192.168.100.74 tell 192.168.100.1, length 28
21:38:29.763989 ARP, Reply 192.168.100.74 is-at f0:c7:7f:18:78:b9, length 28
21:38:53.165684 IP 0.0.0.0 > 224.0.0.1: igmp query v2
21:38:53.165696 IP6 fe80::a8f4:7dff:fe2d:810f > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24
21:38:54.017705 IP6 fe80::a8f4:7dff:fe2d:810f > ff02::1:ff2d:810f: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff2d:810f,length 24
21:38:54.668069 IP 192.168.100.74.57311 > 192.168.100.1.123: NTPv4, Client, length 48
21:38:54.668310 IP 192.168.100.1.123 > 192.168.100.74.57311: NTPv4, Server, length 48 <== Last request we seen arrive on the Access Point
21:40:58.605682 IP 0.0.0.0 > 224.0.0.1: igmp query v2
21:40:58.605693 IP6 fe80::a8f4:7dff:fe2d:810f > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24
21:40:59.025705 IP6 fe80::a8f4:7dff:fe2d:810f > ff02::1:ff2d:810f: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff2d:810f,length 24
Attached CC3220S TI/NWP trace which may help indicate what the cause was of this event.
/cfs-file/__key/communityserver-discussions-components-files/968/ti_5F00_sntp_5F00_lost.log