• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 40 subscribers
  • Views 449 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Unresponsive Wi-Fi Station DHCP client (dead) following collision with EAP (EAP-TLS) Re-Authentication

David Dykhuizen
Intellectual 320 points
Part Number: CC3220S

Operating as a Wi-Fi station using simplelink_cc32xx_sdk_3_20_00_06 we connect the device to an Access Point using EAP-TLS Authentication. The Access Point DHCP Server lease interval is configured for 10 minutes (T1: ~4 ½ minutes) along with a re-authentication interval of 3000 seconds (50 minutes).

 When the Wi-Fi station DHCP renew collides with the EAP renew process it appears as if the DHCP Client on the Network Processor (NWP) fails [dies] and does not recover until the connection to the Access Point is disconnected / reconnected or new re-authentication interval occurs.

 Via TCP dump on the Access Point we see no attempt from the station to perform DHCP renew, though the Wi-Fi connection to the station is still established. After the DHCP lease expires we receive event notification from the NWP, example:

[NETAPP EVENT] IPv4 Lost: IP=0.0.0.0 ,
[NETAPP EVENT] DHCP timeout

Example of what is observed on the Access Point from tcpdump, note: we are using SNTP from the station every 30 seconds to verify/monitor the connection:

DHCP Lease : 10 minutes
Re-authentication interval: 50 minutes

04:19:56.588537 IP 192.168.1.92.bootpc > 192.168.1.1.bootps: BOOTP/DHCP, Request from f0:c7:7f:xx:xx:xx (oui Unknown), length 300
04:19:56.591328 IP 192.168.1.1.bootps > 192.168.1.92.bootpc: BOOTP/DHCP, Reply, length 300
04:20:11.081798 IP 192.168.1.92.52471 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:20:11.082024 IP 192.168.1.1.ntp > 192.168.1.92.52471: NTPv4, Server, length 48
04:20:41.187068 IP 192.168.1.92.51109 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:20:41.187291 IP 192.168.1.1.ntp > 192.168.1.92.51109: NTPv4, Server, length 48
04:20:46.201314 ARP, Request who-has 192.168.1.92 tell 192.168.1.1, length 28
04:20:46.394892 ARP, Reply 192.168.1.92 is-at f0:c7:7f:xx:xx:xx (oui Unknown), length 28
04:21:11.292576 IP 192.168.1.92.60175 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:21:11.292801 IP 192.168.1.1.ntp > 192.168.1.92.60175: NTPv4, Server, length 48
04:21:41.397962 IP 192.168.1.92.57487 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:21:41.398200 IP 192.168.1.1.ntp > 192.168.1.92.57487: NTPv4, Server, length 48
04:21:46.409316 ARP, Request who-has 192.168.1.92 tell 192.168.1.1, length 28
04:21:46.605903 ARP, Reply 192.168.1.92 is-at f0:c7:7f:xx:xx:xx (oui Unknown), length 28
04:22:11.502238 IP 192.168.1.92.57178 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:22:11.502477 IP 192.168.1.1.ntp > 192.168.1.92.57178: NTPv4, Server, length 48
04:22:41.607462 IP 192.168.1.92.58398 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:22:41.607737 IP 192.168.1.1.ntp > 192.168.1.92.58398: NTPv4, Server, length 48
04:22:46.617313 ARP, Request who-has 192.168.1.92 tell 192.168.1.1, length 28
04:22:46.815036 ARP, Reply 192.168.1.92 is-at f0:c7:7f:xx:xx:xx (oui Unknown), length 28
04:23:11.711848 IP 192.168.1.92.61000 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:23:11.712090 IP 192.168.1.1.ntp > 192.168.1.92.61000: NTPv4, Server, length 48
04:23:41.817262 IP 192.168.1.92.65495 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:23:41.817635 IP 192.168.1.1.ntp > 192.168.1.92.65495: NTPv4, Server, length 48
04:23:46.825315 ARP, Request who-has 192.168.1.92 tell 192.168.1.1, length 28
04:23:47.030448 ARP, Reply 192.168.1.92 is-at f0:c7:7f:xx:xx:xx (oui Unknown), length 28
04:24:11.922500 IP 192.168.1.92.58609 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:24:11.922731 IP 192.168.1.1.ntp > 192.168.1.92.58609: NTPv4, Server, length 48
04:24:19.705329 IP 192.168.1.92.bootpc > 192.168.1.1.bootps: BOOTP/DHCP, Request from f0:c7:7f:xx:xx:xx (oui Unknown), length 300
04:24:19.707560 IP 192.168.1.1.bootps > 192.168.1.92.bootpc: BOOTP/DHCP, Reply, length 300
04:24:42.027891 IP 192.168.1.92.59979 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:24:42.028126 IP 192.168.1.1.ntp > 192.168.1.92.59979: NTPv4, Server, length 48
04:24:47.033315 ARP, Request who-has 192.168.1.92 tell 192.168.1.1, length 28
04:24:47.235709 ARP, Reply 192.168.1.92 is-at f0:c7:7f:xx:xx:xx (oui Unknown), length 28
04:25:12.133281 IP 192.168.1.92.52044 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:25:12.133521 IP 192.168.1.1.ntp > 192.168.1.92.52044: NTPv4, Server, length 48
04:25:42.237536 IP 192.168.1.92.52870 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:25:42.237787 IP 192.168.1.1.ntp > 192.168.1.92.52870: NTPv4, Server, length 48
04:25:47.241309 ARP, Request who-has 192.168.1.92 tell 192.168.1.1, length 28
04:25:47.445335 ARP, Reply 192.168.1.92 is-at f0:c7:7f:xx:xx:xx (oui Unknown), length 28
04:26:12.342910 IP 192.168.1.92.49940 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:26:12.343145 IP 192.168.1.1.ntp > 192.168.1.92.49940: NTPv4, Server, length 48
04:26:42.447288 IP 192.168.1.92.52503 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:26:42.447527 IP 192.168.1.1.ntp > 192.168.1.92.52503: NTPv4, Server, length 48
04:26:47.449317 ARP, Request who-has 192.168.1.92 tell 192.168.1.1, length 28
04:26:47.655346 ARP, Reply 192.168.1.92 is-at f0:c7:7f:xx:xx:xx (oui Unknown), length 28
04:27:12.552540 IP 192.168.1.92.64037 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:27:12.552765 IP 192.168.1.1.ntp > 192.168.1.92.64037: NTPv4, Server, length 48
04:27:42.659930 IP 192.168.1.92.63903 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:27:42.660163 IP 192.168.1.1.ntp > 192.168.1.92.63903: NTPv4, Server, length 48
04:27:47.673320 ARP, Request who-has 192.168.1.92 tell 192.168.1.1, length 28
04:27:47.865748 ARP, Reply 192.168.1.92 is-at f0:c7:7f:xx:xx:xx (oui Unknown), length 28
04:28:12.766171 IP 192.168.1.92.60655 > 192.168.1.1.ntp: NTPv4, Client, length 48
04:28:12.766381 IP 192.168.1.1.ntp > 192.168.1.92.60655: NTPv4, Server, length 48
04:28:25.139027 EAP packet (0) v1, len 26
04:28:25.344070 EAP packet (0) v1, len 62
04:28:25.550334 EAP packet (0) v1, len 6
04:28:25.866772 EAP packet (0) v1, len 1408
04:28:25.958236 EAP packet (0) v1, len 117
04:28:26.166771 EAP packet (0) v1, len 6
04:28:26.370639 EAPOL key (3) v1, len 117
04:28:26.371556 EAPOL key (3) v1, len 117
04:28:26.374278 EAPOL key (3) v1, len 95
05:19:48.278223 f0:c7:7f:xx:xx:xx (oui Unknown) > Broadcast Null Unnumbered, xid, Flags [Response], length 6: 01 00
05:19:48.286639 EAP packet (0) v1, len 26
05:19:48.301515 EAP packet (0) v1, len 62
05:19:48.306900 EAP packet (0) v1, len 6
05:19:48.427706 EAP packet (0) v1, len 1408
05:19:48.431681 EAP packet (0) v1, len 117
05:19:48.466608 EAP packet (0) v1, len 6
05:19:48.476376 EAPOL key (3) v1, len 117
05:19:48.479889 EAPOL key (3) v1, len 95
05:19:48.490658 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from f0:c7:7f:xx:xx:xx (oui Unknown), length 300
05:19:48.491203 ARP, Request who-has 192.168.1.92 tell 192.168.1.1, length 28

  

When this issue is detected is there a graceful way that we can "restart" the Client DHCP process on the NWP rather than having to reestablish (toggle) the Wi-Fi connection to the Access Point?

  • 0
    TI__Guru 61556 points

    Hi David,

    I'm not aware of such issue.

    Does the DHCP renewal works with that AP when there is no simultaneous re-key?

    Chapter 5 of the NWP programmer guide () discusses the different DHCP client modes. You can try to switch the mode. You can also try to enable the DHCP using the sl_NetCfg command.

    Br,

    Kobil

  • 0 in reply to Kobi Leibovitch
    Intellectual 320 points

     

    >> Does the DHCP renewal works with that AP when there is no simultaneous re-key?

     

    Yes (steady state running over the weekend, i.e. ~2 1/2 days)

     

    >> You can try to switch the mode. You can also try to enable the DHCP using the sl_NetCfg command.

     

    We have tried switching between : DHCP_NO_FAST_RENEW, DHCP_FAST_RENEW_NO_ACK, DHCP_FAST_RENEW_WAIT_ACK to “stimulate” (restart) the client but this appears to have no affect.

     

    We also did try to disable/enable DHCP:

     

       sl_NetAppStop(SL_NETAPP_DHCP_SERVER_ID);

       sleep (1);

       sl_NetAppStart(SL_NETAPP_DHCP_SERVER_ID);

     

    Though remember we are operating as a DHCP client, so starting and stopping the DHCP Server was a long shot.

     

     

    Thanks,

    /David

  • 0 in reply to David Dykhuizen
    TI__Guru 61556 points

    Hi David,

    The SL_NETAPP_DHCP_SERVER_ID is not relevant for your case. I meant that you'll use the sl_NetCfg to re-enable DHCP by configuring the system to use DHCP (you may want to set the address method as static temporary and then back to use DHCP).

    If this wan't work, you'll need to reconnect and we will try to debug this. Having NWP logs of the failure (http://processors.wiki.ti.com/index.php/CC3120_%26_CC3220_Capture_NWP_Logs) would be very helpful.

    Br,

    Kobi