• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 40 subscribers
  • Views 174 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.

CC3235S: Repeated eventwlan:disconnect when WPA-ENT connect fails

Lynn Linse
Prodigy 100 points
Part Number: CC3235S

How do I disable the repeated-forever disconnect events?

I am piloting some special WPA-ENT station behavior, using the 'at_command' example & a python host. It is not connecting, but that's not the problem.

[WiFi: DEBUG] sent: [AT+WLanConnect=Eng-Test-Ent,,WPA_ENT,"pass","user","",PEAP0_MSCHAPv2]

[WiFi: DEBUG] recv: [OK]

[WiFi: DEBUG] recv: [+eventwlan:disconnect,Eng-Test-Ent,0x6e:0x3a:0x1e:0x83:0x8f:0x73,208]

[WiFi: DEBUG] recv: [+eventwlan:disconnect,Eng-Test-Ent,0x6e:0x3a:0x1e:0x83:0x8f:0x73,208]

[WiFi: DEBUG] recv: [+eventwlan:disconnect,Eng-Test-Ent,0x6e:0x3a:0x1e:0x83:0x8f:0x73,208]

(these events repeat once a second forever!)

Ideally I get a single "+eventwlan:disconnect" event, or a few. I see there is a set-policy to enable 'auto' reconnection, but I'm not seeing the ability to turn this off - to be full manual. I did try setting policy to 'fast' (so NOT auto), but that does not stop the repeated disconnect events. At the moment, the only way to disable these events seems to be try to connect to a FAKE non-existent ACCESS-POINT with WPA2 (not ENT) and let that fail. The 208 'reason code' means "disconnect while connecting"

  • 0
    TI__Mastermind 38980 points

    Hi Lynn,

    The connect command calls sl_WlanConnect(), which does not add a WLAN profile used by the auto-connect policy. It sounds like something else may be going wrong in the application.

    What SDK version and servicepack version are you using? This should print at the beginning of the demo.

    Best regards,

    Sarah

  • 0
    Prodigy 100 points

    Sorry, should have mentioned that - I have the 4.40.0.7 SDK, so SP would be 4.9.0.2_3.7.0.1_3.1.0.26 (so latest?)

    To add confusion to this issue, I discovered today that this only is true on 1 of 2 AP I have tested. The other AP gives a single reason code '2', then stops. I have checked and the data bytes for the repeated events are coming from the XDS110 usb-serial link. So something keeps generating the bytes.

    Anyway, this is NOT a show-stopper. The extra data is just undesirable, since it needs to be detected & discarded to show desired data.

  • 0 in reply to Lynn Linse
    TI__Mastermind 38980 points

    Hi Lynn,

    That is odd. Are you able to gather sniffer captures and NWP logs when testing with the bad AP?

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Prodigy 100 points

    I'll see what I can do - problem is my Windows work notebook also uses WiFi for lan connection, so WiFi is very busy.

    Now I am thinking the issue might be that the 'trouble AP' is not set up correctly. Neither of them are 'live' WPA-ENT systems. Both were set up as tests nodes (the trouble one by an engineer & other by IT). The people who set up claim their phones connect, but then any apple/android/windows OS app has lots of magic-sauce to work-around minor issues. If we leave this topic open, I'll update if/when I discover what the AP problem is. It would certainly be a good-to-know even if a red-herring.