CC3100MOD: CC3100 can't get DHCP IP address in big network

Hi Leon,

When you say that the CC3100 is not roaming between APs, do you mean that it is not automatically switching between networks depending on the RSSI, or do you mean that it is not reconnecting to an AP after the device is disconnected?

As for the DHCP issue, could you please collect the NWP logs from the device during the connection to the AP and the DHCP failure? That will allow me to examine the state of the device during the DHCP process. Instructions on how to do so can be found here: https://processors.wiki.ti.com/index.php/CC3100_%26_CC3200_Capture_NWP_Logs

Do note that the instructions refer to pin62 for capture - this is CC3100 package pin 62, on the CC3100 module package pin62 is routed to module pin 52 (TEST_62).

Regards,

Michael

Hi Michael,

1. According to roaming between AP: The chip not always connected to AP with higher RSSI and stay connected to AP with lower RSSI, although the scanning represents the AP closer to chip with higher RSSI. In my case AP with higher RSSI: -61~-63 dbm and AP with lower RSSI: -65 ~ -69 dbm.

Kind Regards,

Leon.

Hi Michael,

I tried read the  logs via TEST_62 pin, but it outputs unreadable data: �"

I tried all baudrates from 9600 up to 921600 bps.

Kind Regards,

Leon.

Hi Michael,

According to link: https://processors.wiki.ti.com/index.php/CC3100_%26_CC3200_Capture_NWP_Logs

The baudrate should be:921600 bps and log have to record i binary mode.

I uploaded the CC3100MOD NWP log.

Kind Regards,

Leon.

CC3100_MOD_LOG_hex.txt

Hi Leon,

Please capture log as binary text not a HEX characters.

Jan

Hi Jan,

Attached new log file.

Kind Regards,

Leon.CC3100_MOD_LOG.txt

Hi Leon,

It seems that format of NWP log is correct now. Please wait for a answer from TI side.

Jan

Hi Leon,

Thank you for providing your logs. I have been able to decode them and analyze them on my end.

From what I'm seeing, the cause of DHCP not completing is due to the CC3100 not getting a response to the DHCP discover messages that it broadcasts. Whether this is due to the CC3100 not sending/receiving the DHCP handshaking messages or whether this is due to some DHCP configuration issue in your network is not clear. Air sniffer logs would be useful to see if the DHCP server(s) in your network respond to the CC3100.

As a sanity check, are other non-CC3100 devices able to connect to the APs and get IP addresses through DHCP? Maybe the DHCP discover broadcasts are not being provided to the DHCP servers.

Also, is it possible to test with a newer CC3xxx device connected to the same network? It would be interesting to see if the CC3120 or CC3135 run into the same issues.

Regards,

Michael

Hi Michael,

Thank you for your help.

According to your question:

"As a sanity check, are other non-CC3100 devices able to connect to the APs and get IP addresses through DHCP? Maybe the DHCP discover broadcasts are not being provided to the DHCP servers." - All devices like: laptops, cellular phones connected to this network and obtain addresses.

What type a tools can we use to sniff air messages between CC3100MOD and AP ?

Kind Regards,

Leon.

Hi Leon,

You will need a 802.11 adapter that supports being put into promiscuous mode/air sniffer mode, as well software and drivers that allow for capture of raw 802.11 data.

I personally use a Omnipeek setup with a Cisco Wi-Fi adapter, but there are many other options out there. I suggest you take a look at the info here that Wireshark provides for some background: https://wiki.wireshark.org/CaptureSetup/WLAN

Without seeing the raw traffic between the CC3100 and the AP/rest of your network, it would be hard to determine where the failure occurs. All the log data indicates is that the CC3100 does not see any DHCP responses. It would be greatly appreciated if you could collect those air sniffer logs.

Regards,

Michael

Hi Michael,

We have another product with this module, and there we do not have this problem. 

In that product, we use the version from your production, while in the module with the problem we use the latest version you have released.

Which version is released with M/N CC3100MODR11MAMOB, and what is the difference between that version and version NWP: 2.12.2.8 / MAC: 1.5.0.10 / PHY:  1.0.3.37?

Regards,

Limor

Hi Limor,

It's strange that you run into the DHCP issue when you run with the newer firmware, but not with the older firmware. I unfortunately do not know the precise firmware that the CC3100mod devices ship with pre-flashed on the serial flash, and even if I did know, pulling the full list of changes would not be feasible given the amount of change that has occurred between the release of the CC3100mod and the latest release.

In any case, we recommend all users upgrade to the latest servicepack if possible, so debugging and fixing issues in the latest firmware is preferable to using an older firmware that may have bugs and fewer features.

Did you modify any of the other serial flash files when you updated the NWP servicepack? In the other older product, did you ever flash any files onto the serial flash, or did you use the CC3100mod as-is?

Regards,

Michael

Hi Michael,

As I mentioned before, we are experiencing problems connecting to Risco network ( ap connected, cannot obtain ip address).

We prepared two boards:

Board#1 based on Ver: 2.12.2.8.31.1.5.0.10.1.0.3.37, simplelink driver: 1.0.1.14

Board#2 based on old version:2.6.0.5.31.1.4.0.1.1.0.3.34 , simplelink driver: 1.0.1.6

Those two identical boards running same application and connected to same control panel.

Course of the experiment:

Control panel located between two Risco AP ( Cisco AP  AIR-AP1832I-I-K9). Range between control panel to each of AP is about 10 meter.

1. Connect to control panel board#1, start run. Success connect to one of AP, but cannot obtain ip address.

2. Disconnect board#1 ,connect board#2, start run. Success connect to one of AP, success obtain ip address.

We repeat the experiment several times. In all cases board#2 success obtain ip address and board#1 cannot.

RSSI level from each of those AP is around: -63 ~- 68 dbm.

What the major differences between 2.12.2.8.31.1.5.0.10.1.0.3.37 and 2.6.0.5.31.1.4.0.1.1.0.3.34. ?

BTW: If WIFI chip running the newer FW, we can't downgrade to old version, it cause to WIFI stuck!! It's mean If update version (in our case downgrade to older version) happens on the customer's site, this will disable the system.

Kind Regards,

Leon.

Hi Leon,

One of the main differences between the 2.12.2.8 version and the 2.6.0.5 version of the servicepack is the addition of a series of WPA2 fixes for the KRACK exploit. It may be possible that caused a change in connect behavior that results in DHCP being less robust.

One way of testing whether those fixes are the cause is to temporarily allow the CC3200 to connect in OPEN mode, without WPA2 security. If the CC3200 is able to get an IP address through DHCP with the new servicepack only on OPEN security, then that would indicate the cause would be related to those fixes. Is this a test that you can perform?

Regards,

Michael