This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3220S: SNTP Client Traffic Stopped following EAP Traffic

Part Number: CC3220S
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

  • Hi David,

    What is the AP that you are connected to?

    Br,

    Kobi

  • Hello:

    An internal product, the Access Point is structured as follows -

    (Hardware)  ieee80211 phy0: Atheros AR9271

    (Driver) ath9k_htc (Linux Kernel 3.2.17)

    (Software)

    hostapd v2.6

    freeradius v3.0.17

    Note: A windows client connected to the same Access Point performing the same continuity test remains "operational".

    Thanks,

    /David

  • The log file you've provided is corrupted.

    Can you provide another one?

  • Hello Kobi:

    Please see the logs attached below - hopefully these are correct (using Tera Term, saving as Binary, …) - otherwise going to have to review "procedure". 

    In the first log it would be around timestamp 18:57.

    In the second log it would be around timestamp 20:12.
       (Good trace showing why this was linked to the DHCP issue - the CC3220 is "connected" to the AP but not sending anything)

    First Trace:

    /cfs-file/__key/communityserver-discussions-components-files/968/ti_5F00_sntp_5F00_lost_5F00_11_5F00_11_5F00_2019.log

    EAP Messages -

    ...
    18:57:08.139324 EAP packet (0) v1, len 26, Response (2), id 81, len 26
       Type Identity (1), Identity: WirelessSensor-1878b9
    0x0000:  0100 001a 0251 001a 0157 6972 656c 6573  .....Q...Wireles
    0x0010:  7353 656e 736f 722d 3138 3738 6239       sSensor-1878b9
    18:57:08.242460 EAP packet (0) v1, len 62, Response (2), id 82, len 62
       Type TLS (13) flags [none] 0x00,
    0x0000:  0100 003e 0252 003e 0d00 1603 0100 3301  ...>.R.>......3.
    0x0010:  0000 2f03 0100 0004 b4f3 bd8d 7cc9 51ed  ../.........|.Q.
    0x0020:  9dde 6ad2 0de4 c562 41a5 3512 36fa beb7  ..j....bA.5.6...
    0x0030:  52d8 6bcc 2800 0008 002f 000a 0005 0004  R.k.(..../......
    0x0040:  0100                                     ..
    18:57:08.345226 EAP packet (0) v1, len 6, Response (2), id 83, len 6
        Type TLS (13) flags [none] 0x00,
    0x0000:  0100 0006 0253 0006 0d00                 .....S....
    19:02:12.362791 f0:c7:7f:18:78:b9 (oui Unknown) > Broadcast Null Unnumbered, xid, Flags [Response], length 6: 01 00
    0x0000:  0001 af81 0100                           ......
    19:02:12.374196 EAP packet (0) v1, len 26, Response (2), id 255, len 26
        Type Identity (1), Identity: WirelessSensor-1878b9
    0x0000:  0100 001a 02ff 001a 0157 6972 656c 6573  .........Wireles
    0x0010:  7353 656e 736f 722d 3138 3738 6239       sSensor-1878b9

    Device Trace showing SNTP Requests:

    ...
    last event: 1 queue ret: -1 depth: 0
    retval: 0 Current time: Mon Nov 11 18:56:50 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 18:57:30 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 18:58:10 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 18:58:50 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 18:59:30 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 19:00:10 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 19:00:50 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 19:01:30 2019

    [Disconnects from AP]

    Second Trace


    /cfs-file/__key/communityserver-discussions-components-files/968/ti_5F00_sntp_5F00_lost_5F00_11_5F00_11_5F00_2019_5F00_b.log

    EAP Messages -

    ...
    20:01:59.478197 EAPOL key (3) v1, len 95
    20:11:59.535506 EAPOL key (3) v1, len 95
    20:12:08.335295 EAP packet (0) v1, len 26
    20:12:08.437178 EAP packet (0) v1, len 62
    20:12:08.541065 EAP packet (0) v1, len 6
    20:12:08.754868 EAP packet (0) v1, len 1408
    20:12:08.848721 EAP packet (0) v1, len 117
    20:12:08.954751 EAP packet (0) v1, len 6
    20:12:09.074136 EAPOL key (3) v1, len 117
    20:12:09.075020 EAPOL key (3) v1, len 117
    20:12:09.079278 EAPOL key (3) v1, len 95

    Device Trace showing SNTP Requests -

    last event: 1 queue ret: -1 depth: 0
    retval: 0 Current time: Mon Nov 11 20:08:18 2019

    last event: 1 queue ret: -1 depth: 0
    retval: 0 Current time: Mon Nov 11 20:08:48 2019

    last event: 1 queue ret: -1 depth: 0
    retval: 0 Current time: Mon Nov 11 20:09:18 2019

    last event: 1 queue ret: -1 depth: 0
    retval: 0 Current time: Mon Nov 11 20:09:48 2019

    last event: 1 queue ret: -1 depth: 0
    retval: 0 Current time: Mon Nov 11 20:10:18 2019

    last event: 1 queue ret: -1 depth: 0
    retval: 0 Current time: Mon Nov 11 20:10:48 2019

    last event: 1 queue ret: -1 depth: 0
    retval: 0 Current time: Mon Nov 11 20:11:18 2019

    last event: 1 queue ret: -1 depth: 0
    retval: 0 Current time: Mon Nov 11 20:11:48 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:12:28 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:13:08 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:13:48 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:14:28 2019

    =========> [NETAPP EVENT] Current time: Mon Nov 11 20:14:49 2019
     IPv4 Lost: IP=0.0.0.0 ,
    [NETAPP EVENT] DHCP timeout
    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:15:08 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:15:48 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:16:28 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:17:08 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:17:48 2019

    last event: 1 queue ret: -1 depth: 0
    retval: -107 Current time: Mon Nov 11 20:18:28 2019

    TCP Dump on AP -

    20:10:48.599074 IP 192.168.100.1.ntp > 192.168.100.10.65318: NTPv4, Server, length 48
    20:10:53.613712 ARP, Request who-has 192.168.100.10 tell 192.168.100.1, length 28
    20:10:53.789369 ARP, Reply 192.168.100.10 is-at f0:c7:7f:18:78:b9 (oui Unknown), length 28
    20:11:18.686774 IP 192.168.100.10.49785 > 192.168.100.1.ntp: NTPv4, Client, length 48
    20:11:18.687037 IP 192.168.100.1.ntp > 192.168.100.10.49785: NTPv4, Server, length 48
    20:11:23.693698 ARP, Request who-has 192.168.100.10 tell 192.168.100.1, length 28
    20:11:23.894345 ARP, Reply 192.168.100.10 is-at f0:c7:7f:18:78:b9 (oui Unknown), length 28
    20:11:28.237687 IP 0.0.0.0 > 224.0.0.1: igmp query v2
    20:11:28.237717 IP6 fe80::ec3e:1cff:feb3:d507 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24
    20:11:48.791285 IP 192.168.100.10.60948 > 192.168.100.1.ntp: NTPv4, Client, length 48
    20:11:48.791547 IP 192.168.100.1.ntp > 192.168.100.10.60948: NTPv4, Server, length 48
    20:11:53.805701 ARP, Request who-has 192.168.100.10 tell 192.168.100.1, length 28
    20:11:54.000225 ARP, Reply 192.168.100.10 is-at f0:c7:7f:18:78:b9 (oui Unknown), length 28
    20:13:33.677687 IP 0.0.0.0 > 224.0.0.1: igmp query v2
    20:13:33.677716 IP6 fe80::ec3e:1cff:feb3:d507 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24
    20:15:39.117690 IP 0.0.0.0 > 224.0.0.1: igmp query v2
    20:15:39.117770 IP6 fe80::ec3e:1cff:feb3:d507 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24
    20:17:44.557702 IP 0.0.0.0 > 224.0.0.1: igmp query v2
    20:17:44.557786 IP6 fe80::ec3e:1cff:feb3:d507 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24

  • Hi David,

    The 2nd log doesn't seems to work as well.

    It is very hard to understand the problem with this information.

    Have you made any progress?

    Is this an AP that you are planning to use in the field or it is just serving for your testing?

    Br,

    Kobi 

  • Hello Kobi:

     

    The Access Point, providing Enterprise Security [EAP-TLS], is currently in the field.

      

    We know that when this occurs we need to drop the connection and re-establish to get everything reworking.

     

    If we leave the CC3220S connected to the Access Point and wait for another EAP Re-Authentication Interval everything may begin work too.

     

    Of course if we disable EAP Re-Authentication the issue is not observed. Other equipment (Windows Tablets, iPads, Raspberry Pi ) connected to the Access Point does not exhibit this behavior.

     

     

    Thanks,

    /David

     

  • Hi David,

    Please try to follow the exact instructions for producing the FW log. We must have it in order to have more  details.

    It will also be very helpful to get an air sniffer (802.11) log.

    It seems like the AP disconnects the station. Can you read the AP logs and understand the reason?

    What is the Re-Auth interval that is configured?

    Br,

    Kobi

  • Hello:

    >>  It seems like the AP disconnects the station. Can you read the AP logs and understand the reason?

    Tried to show above, the CC3220S is connected to the Access Point but nothing is being received from the CC3220S (per Wireshark on the Access Point and debug indication on the CC3220S) following the re-authentication.  After the DHCP lease times out on the CC3220S we, our application, "drives" the CC3220S to disconnect and reconnect to the Access Point.

    >> What is the Re-Auth interval that is configured?

    When we first ran into this issue it was 3600 seconds, we have lowered it to 300 seconds to speed up the occurrence.

    >> Please try to follow the exact instructions for producing the FW log. We must have it in order to have more  details.

    To date none of the binary logs provided have been valid?

    Thanks,
    /David

  • The -107 means that the AP disconnected the Station. Can you read the logs of the FreeRadius?

    I've got to binary logs files from you - both weren't valid.

    Br,

    Kobi 

  • Hello:

    >> The -107 means that the AP disconnected the Station. Can you read the logs of the FreeRadius?

    Yes will review the hostapd logs and FreeRadius again but based on what we seen, the device is still "connected" - based on "iw station list".  On the Access Point, see the rx activity continuing to grow and tx being reset - every time we attempt to ping or arp the device.

    Also one would expect the CC3220S (the device) to publish the event -

    SL_WLAN_EVENT_DISCONNECT

    to the application correct?  This was not received from the call back.

    Thanks,
    /David

  • Yes, the event is expected.

    We will need an NWP (valid) log to better understand this.

    Br,

    Kobi

  • Hello Kobi:

     

    We have not had an opportunity to connect/utilize an 802.11 air sniffer but would like to forward the below log file to see if it is “readable”.

     

    /cfs-file/__key/communityserver-discussions-components-files/968/no_5F00_traffic_5F00_following_5F00_eap_5F00_re_2D00_auth.log

     

    Can confirm that Radius is returning Access-Accept following the “re-auth”, example:

     

    Thu Dec 5 12:48:09 2019

           Packet-Type = Access-Accept

           User-Name = "WirelessSensor-1878b9"

           Tunnel-Type = VLAN

           Tunnel-Medium-Type = IEEE-802

           Tunnel-Private-Group-Id = "100"

     

    Thu Dec 5 12:53:09 2019                               <== 300 seconds later (5 minutes) – “re-auth”

           Packet-Type = Access-Accept

           User-Name = "WirelessSensor-1878b9"

           Tunnel-Type = VLAN

           Tunnel-Medium-Type = IEEE-802

           Tunnel-Private-Group-Id = "100"

     

    Also can confirm that hostapd “believes” the mobile station is still attached during this time:

     

    root:~# date; iw dev wlan0.100 station dump

    Thu Dec 5 12:54:37 UTC 2019

    Station f0:c7:7f:18:78:b9 (on wlan0.100)

           inactive time: 584 ms

           rx bytes:       8439

           rx packets:     92

           tx bytes:       5747

           tx packets:     42

           tx retries:     0

           tx failed:     0

           signal:         -50 dBm

           signal avg:     -51 dBm

           tx bitrate:     65.0 MBit/s MCS 7

           rx bitrate:     2.0 MBit/s

           authorized:     yes

           authenticated: yes

           preamble:       short

           WMM/WME:      yes

           MFP:           no

    root:~# date; iw dev wlan0.100 station dump

    Thu Dec 5 12:54:40 UTC 2019

    Station f0:c7:7f:18:78:b9 (on wlan0.100)

           inactive time: 508 ms

           rx bytes:       8487

           rx packets:     94

           tx bytes:       5747

           tx packets:     42

           tx retries:     0

           tx failed:     0

           signal:         -51 dBm

           signal avg:     -51 dBm

           tx bitrate:     65.0 MBit/s MCS 7

           rx bitrate:     2.0 MBit/s

           authorized:     yes

           authenticated: yes

           preamble:       short

           WMM/WME:       yes

           MFP:           no

     

    No “ip traffic” is observed, according to tcpdump at the Access Point on the vlan wlan device, following the “re-auth”:

     

    12:52:16.646484 IP 192.168.100.10.52867 > 192.168.100.1.ntp: NTPv4, Client, length 48

    12:52:16.646749 IP 192.168.100.1.ntp > 192.168.100.10.52867: NTPv4, Server, length 48

    12:52:21.653094 ARP, Request who-has 192.168.100.10 tell 192.168.100.1, length 28

    12:52:21.861815 ARP, Reply 192.168.100.10 is-at f0:c7:7f:18:78:b9 (oui Unknown), length 28

    12:52:46.750727 IP 192.168.100.10.50930 > 192.168.100.1.ntp: NTPv4, Client, length 48

    12:52:46.750986 IP 192.168.100.1.ntp > 192.168.100.10.50930: NTPv4, Server, length 48

    12:52:51.413075 IP 0.0.0.0 > 224.0.0.1: igmp query v2

    12:52:51.413105 IP6 fe80::7879:a0ff:fe35:9180 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24

    12:52:51.765096 ARP, Request who-has 192.168.100.10 tell 192.168.100.1, length 28

    12:52:51.967579 ARP, Reply 192.168.100.10 is-at f0:c7:7f:18:78:b9 (oui Unknown), length 28 <== No more traffic from Mobile Station (CC3220S)

     

    12:54:56.853087 IP 0.0.0.0 > 224.0.0.1: igmp query v2

    12:54:56.853118 IP6 fe80::7879:a0ff:fe35:9180 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24

  • Hi David,

    You log is still not valid.

    Are you using Teraterm or putty? can you try the other tool? are you capturing Binary data?

    Br,

    Kobi

  • Hello:

    We are using Tera Term (v. 4.77), with the "Binary" option selected along with the following code addition:

    (i.e. setup according to: https://processors.wiki.ti.com/index.php/CC3120_&_CC3220_Capture_NWP_Logs

    // Mux Pin62 to mode 1 for outputting NWP logs

    PinModeSet(PIN_62, PIN_MODE_1);
    Display_printf_alt("Pin Mode Get, PIN_62: %d ", PinModeGet(PIN_62));


    No clock setup as this is done in syscfg

    Will record with Putty and post.

    Thanks,
    /David

  • Hello:

    Removed all references to any UART use in the code base and again generated the logs, using putty and again with TeraTerm.

    After the putty log preamble the generated logs in hex are the same at the start... both good or both again screwed up....

    0000:0000 3d7e 3d7e 3d7e 3d7e-3d7e 3d7e 3d7e 3d7e =~=~=~=~=~=~=~=~
    0000:0010 3d7e 3d7e 3d7e 3d20-5075 5454 5920 6c6f =~=~=~= PuTTY lo
    0000:0020 6720 3230 3230 2e30-312e 3032 2031 313a g 2020.01.02 11:
    0000:0030 3534 3a35 3620 3d7e-3d7e 3d7e 3d7e 3d7e 54:56 =~=~=~=~=~
    0000:0040 3d7e 3d7e 3d7e 3d7e-3d7e 3d7e 3d0d 0a00 =~=~=~=~=~=~=...
    0000:0050 bbb7 bfbb db00 bdf9-cbff fdfd 0069 90ef »·¿»Û.½ùË.ýý.i.ï
    0000:0060 a59d fdc5 09df 7bd3-af00 7b8a 97ff 7b8a ¥.ýÅ.ß{Ó¯.{...{.

    0000:0000 00bb b7bf bbdb 00bd-f9cb fffd fd00 6990 .»·¿»Û.½ùË.ýý.i.
    0000:0010 efa5 9dfd c509 df7b-d3af 007b 8a97 ff7b ï¥.ýÅ.ß{Ó¯.{...{


    The eap_reauth_period was set to 300 seconds (i.e. 5 minutes).  Hence we see:

    17:54:47.973247 EAP packet (0) v1, len 26                       <== Initial authentication
    17:54:47.990793 EAP packet (0) v1, len 62
    17:54:47.999184 EAP packet (0) v1, len 6
    17:54:48.119578 EAP packet (0) v1, len 1408
    17:54:48.127845 EAP packet (0) v1, len 117
    17:54:48.167759 EAP packet (0) v1, len 6
    17:54:48.228960 EAPOL key (3) v1, len 117
    17:54:48.233355 EAPOL key (3) v1, len 95
    17:55:54.633834 EAPOL key (3) v1, len 95

    17:59:48.097774 EAP packet (0) v1, len 26                     <== 5 minutes later re-authentication 
    17:59:48.197919 EAP packet (0) v1, len 62                                 (when communication from device [cc3220] "stops")
    17:59:48.300793 EAP packet (0) v1, len 6
    17:59:48.515477 EAP packet (0) v1, len 1408
    17:59:48.611094 EAP packet (0) v1, len 117
    17:59:48.717220 EAP packet (0) v1, len 6
    17:59:48.816345 EAPOL key (3) v1, len 117

    As seen by local ping:

    ...

    64 bytes from 192.168.100.10: icmp_seq=297 ttl=128 time=102 ms
    64 bytes from 192.168.100.10: icmp_seq=298 ttl=128 time=142 ms
    From 192.168.100.1 icmp_seq=346 Destination Host Unreachable
    From 192.168.100.1 icmp_seq=347 Destination Host Unreachable

    ...

    and local TCP dump:

    17:59:47.365009 IP 192.168.100.1 > 192.168.100.10: ICMP echo request, id 27669, seq 298, length 64
    17:59:47.484849 IP 192.168.100.10 > 192.168.100.1: ICMP echo reply, id 27669, seq 298, length 64
    17:59:48.365997 IP 192.168.100.1 > 192.168.100.10: ICMP echo request, id 27669, seq 299, length 64
    17:59:48.515494 IP 192.168.100.10 > 192.168.100.1: ICMP echo reply, id 27669, seq 299, length 64
    17:59:49.367685 IP 192.168.100.1 > 192.168.100.10: ICMP echo request, id 27669, seq 300, length 64
    17:59:50.376903 IP 192.168.100.1 > 192.168.100.10: ICMP echo request, id 27669, seq 301, length 64
    17:59:51.378457 IP 192.168.100.1 > 192.168.100.10: ICMP echo request, id 27669, seq 302, length 64
    17:59:52.378417 IP 192.168.100.1 > 192.168.100.10: ICMP echo request, id 27669, seq 303, length 64

    The logs:

    (Putty, generated)

    /cfs-file/__key/communityserver-discussions-components-files/968/ti_5F00_putty_2D00_20200102.log

    (TeraTerm, generated)

    /cfs-file/__key/communityserver-discussions-components-files/968/ti_5F00_teraTerm_2D00_20200102.log

    Thanks,
    /David

  • Hello Kobi:

    Have you, Texas Instruments, been able to reproduce the observation following the expiration of the EAP authentication period (hostapd.conf – “eap_reauth_period”)?

     

     

    Thanks,

    /David

  • Hi David,

    Unfortunately, even the last 2 logs that you provided are not readable. The format doesn't look like a binary one.

    I really don't understand the problem. We have many customers that are able to produce the NWP log (as instructed in https://processors.wiki.ti.com/index.php/CC3120_&_CC3220_Capture_NWP_Logs). Maybe you can try collecting the logs on another computer or verify the terminal settings (baudrate, etc,).

    Can you get an 802.11 air sniffer capture of this failure?

    We need more info as we are not familiar with this issue (we are passing the wifi certification that tests the EAP re-auth). I guess it is an interoperability issue but we must have more info.

    The device seems to get disconnected from the AP (thus the SNTP/PING transaction fail) and i don't know why you don't get the disconnection event (I need the NWP logs to shed more light on this).

    If i understand correctly, you are able to re-connect to the AP (without calling sl_Stop/sl_Start) and continue working - is that true? 

    Br,

    Kobi

  • Hi Again,

    I've just found out that recently we have introduced a fix (in SP) for a similar issue on the older CC3200 device.

    I'll try to get more details on this and see if the issue is relevant for the CC3220.

    If it is, I'll let you know when the fix would be available.

    Br,

    Kobi

  • Hi David,

    Apparently a recent fix to protect from a man-in-the-middle went too far and blocked the EAP re-key. 

    A fix was already implemented and verified on CC3200.

    Similar fix will be added to CC3220 in the next release (end of 1Q20). 

    I might be able to provide you with a temporary SP for testing the fix in couple of days.

    Br,

    Kobi 

  • Hello Kobi:

    Obviously very good news that the issue is understand and addressed.

    Regarding -

    >> I might be able to provide you with a temporary SP for testing the fix in couple of days.

    If this is possible to get will take you up on the offer; It will provide us closure that this has been addressed in an upcoming build and provide TI another testing reference point.

    Thanks again Kobi,
    /David

  • Hi David,

    I'm closing this as you have verified the fix that will be integrated to the next (1Q20) SDK.

    Br,

    Kobi