Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 2197 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.

CC3100: won't connect to Meraki MR45 AP

Peter Marinsek
Prodigy 160 points
Part Number: CC3100

I have a case with a customer which has exchanged a MR33 for a MR45 (both Merakis) and all devices are working when connecting to a MR33 but can't connect to MR45. This is only valid for WPA2 PSK and WPA2 EAP encryption. If the AP is setup without encryption then the device can connect. The CC3100 FW version during the tests was v2.10.0.0

Customers reply:

{{ It appears the device (CC3100) is failing during the 4 way handshake, whereby the AP is sending handshake 3, but an acknowledgement isn't being sent back:

received EAPOLKey frame
sending 3/4 message of 4-Way Handshake
Warning! EAPOLKey timeout
sending 3/4 message of 4-Way Handshake
Warning! EAPOLKey timeout
sending 3/4 message of 4-Way Handshake
Warning! EAPOLKey timeout
sending 3/4 message of 4-Way Handshake
Warning! EAPOLKey timeout

On a packet capture I took (which is one way) we only see a EAPOL second handshake, and not the fourth }}

All test were done with WPA 2 PSK.

Attaching also a packet capture from my TeamViewer session and a screenshot that was taken from Meraki support.

packet_capture.pcap.zip

  • 0
    TI__Mastermind 22935 points

    Hi Peter, 

    I don't see any of the handshake packets but the first one in the 4 way sequence (packet 130) in the wireshark capture. And for some reason, our device is sending probe response during the 4 way handshake which indicate it is in AP mode. Any idea as to why that is?

    Jesu

  • 0 in reply to Jesu
    Prodigy 160 points

    Hi Jesu,

    We put the CC3100 in the station mode early after power up. So it is a surprise to me, that it might be in the AP mode. Here is our init code after powerup:

    int32_t configureSimpleLinkToDefaultState(void)
{
        _WlanRxFilterOperationCommandBuff_t  RxFilterIdMask = {{0}};

        uint8_t         configOpt = 0;
        uint8_t         power = 0;

        int32_t         retVal = -1;
        int32_t         mode = -1;

        mode = sl_Start(0, 0, 0);
        ASSERT_ON_ERROR(mode);

        if (ROLE_STA != mode)
        {
                return retVal;
        }

        retVal = sl_WlanPolicySet(SL_POLICY_CONNECTION, SL_CONNECTION_POLICY(0, 0, 0, 0, 0), NULL, 0);
        ASSERT_ON_ERROR(retVal);

        retVal = sl_WlanProfileDel(0xFF);
        ASSERT_ON_ERROR(retVal);

        retVal = sl_WlanDisconnect();
        if(0 == retVal)
        {
                retVal = -1;
                return retVal;
        }

        configOpt = SL_SCAN_POLICY(0);
        retVal = sl_WlanPolicySet(SL_POLICY_SCAN, configOpt, NULL, 0);
        ASSERT_ON_ERROR(retVal);

        power = 0;
        retVal = sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, WLAN_GENERAL_PARAM_OPT_STA_TX_POWER, 1, (uint8_t *)&power);
        ASSERT_ON_ERROR(retVal);

        retVal = sl_WlanPolicySet(SL_POLICY_PM , SL_NORMAL_POLICY, NULL, 0);
        ASSERT_ON_ERROR(retVal);

        retVal = sl_NetAppMDNSUnRegisterService(0, 0);
        ASSERT_ON_ERROR(retVal);

        pal_Memset(RxFilterIdMask.FilterIdMask, 0xFF, 8);
        retVal = sl_WlanRxFilterSet(SL_REMOVE_RX_FILTER, (uint8_t *)&RxFilterIdMask,
                       sizeof(_WlanRxFilterOperationCommandBuff_t));
        ASSERT_ON_ERROR(retVal);

        return retVal;

    Do you see any issues with it?

    What additional data would you need to diagnose the handshake issue with the MR45?

  • 0 in reply to Peter Marinsek
    TI__Mastermind 22935 points

    Hi Peter,

    The only issue I see is you're not calling sl_Stop after all the configurations. The reason why our example do that is to apply the changes made then sl_Start is usually called after. Everything else looks similar to what we do in our examples.

    It would be very helpful if you can provide a sniffer capture of the device successfully connecting to the MR33 showing the probe request, authentication, association, handshake as well as other expected management packets. As well as provide a better capture for the MR45  that includes the packets just mentioned. It would be interesting to compare the differences in both to see what changes when switching APs.

    Jesu

  • 0 in reply to Jesu
    Prodigy 160 points

    Hi Jesu,

    please find attached requested capture files:

    Meraki_capture.zip

  • 0 in reply to Peter Marinsek
    TI__Mastermind 22935 points

    Hi Peter,

    Analysis of MR45 capture:

    I don't see the CC3100 sending probe response anymore which is good. The device is successfully associated to the AP so no problem there. The sniffer capture only shows the first step in the handshake process so there isn't much to comment on that. For some reason the capture is only showing packets that are destined for the CC3100. Regardless the main problem seems to be the AP disassociated our device during the handshake process. The AP disassociates it with reason code "previous authentication is no longer valid". I did some research in this status error and ironically forums related to cisco routers start to come up.

    The MR33 capture barely had any packets of which most were clear to send packets. On both captures it did not show what the CC3100 was transmitting and no beacons were present which leads me to believe the capturing device cannot fully capture 802.11 packets. Regardless, I recommend you investigate why the AP is disassociating the device.

    Jesu

  • 0 in reply to Jesu
    Prodigy 160 points

    Hi Jesu,

    please find attached a new capture from the Meraki Portal to include both destinations in source MAC of the CC3100 module

    CC3100_MR45_2.pcap.zip

    Please see if this new capture log can shed some light on the issue.

    Best regards, Peter

  • 0 in reply to Peter Marinsek
    TI__Mastermind 22935 points

    Hi Peter,

    The sniffer capture looks just like the old one. Please make sure the device you're using is able to capture sniffer logs. Also make sure you're not filtering any packets. If you don't have an adequate device for capturing packets then try capturing a network log instead. Steps here.

    Jesu

  • 0 in reply to Jesu
    Prodigy 160 points

    Hi Jesu,

    Thanks for looking into this. The last capture file seems complete. What information (packets) are you missing?

    Best, Peter

  • 0 in reply to Peter Marinsek
    TI__Mastermind 22935 points

    Peter,

    As I mentioned before, the captures you provide don't show any management packets (i.e. beacon, acknowledgement...). All I see is our device sending packet 2 of the 4 way handshake. There is no way for me to tell if the AP acknowledged it or if the AP is responding after that. If you cannot provide an adequate capture please provide an NWP log like I suggested before.

    Jesu

  • 0 in reply to Peter Marinsek
    TI__Mastermind 22935 points

    Below is a screenshot of what a capture for establishing a secure connection should look like. You cannot see beacon packets because of a filter I have. You can see packets 1/4 and 3/4 from AP and 2/4 and 4/4 from station. If you do send another capture, please make sure you see acknowledgements and at least packet 1/4 and 2/4 from handshake.

    Jesu