• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 40 subscribers
  • Views 1906 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3200: Connection Errors, Disconnection Reasons, and Their Differences (109, 110, -102,-109,-110)

Jason Hiner
Prodigy 170 points
Part Number: CC3200

Hi All,

We're doing some range testing with our application using the CC3200 in P2P mode. The CC3200 is acting as the group client, and an android tablet is the group owner. Once we connect, I'm using a modified version of the UDP client demo to transfer data to the tablet. I've been getting the errors below quite often while testing. I want to understand their differences and ask if there are any ways to recover from them.

If we fail to connect, we typically see these events:

SL_GENERAL_ERROR_CON_MGMT_STATUS_UNSPECIFIED  (-102)

SL_GENERAL_ERROR_CON_MGMT_STATUS_DISCONNECT_DURING_CONNECT (-109)
SL_GENERAL_ERROR_CON_MGMT_STATUS_SG_RESELECT (-110)

And if we connect, but then disconnect shortly after, we typically see these reasons:

SL_WLAN_DISCONNECT_ROAMING_TRIGGER_BSS_LOSS (109)
SL_WLAN_DISCONNECT_ROAMING_TRIGGER_BSS_LOSS_DUE_TO_MAX_TX_RETRY (110)

The reason codes, I understand. Since we're at range, we may have missed a beacon, and that triggers either of those disconnect reasons (though I don't know what the difference is between them).

I've also seen elsewhere in this forum that the error code -109 has to do with authentication failure during connection, so the parties disconnect from each other. I don't understand why that error would be thrown, and not the specific authentication failure code -103 (Auth reject). I have no idea what an SG Reselect is, and I can't find any information about it online. Error -102 doesn't provide much insight as to what's going on either.

Why are these different errors being thrown seemingly interchangeably? Am I missing some key info about each of them? Are there any parameters I can set to keep them from popping up so often? I ask this because we will get these errors, then move even further away, and connect/transfer data just fine on the subsequent test. I want to make sure our failures are actually failures, and not conditions that I could fix in code. The answers here will benefit me while I'm adding in some logic to switch channels if connections aren't working. 

I'm running Service Pack 1.0.1.11-2.10.0.0, and this happens on both the LaunchXL and our custom designs.

Thanks for your time and assistance.

-Jason

  • 0
    TI__Expert 8255 points

    Hi Jason,

    Code -102, -109, 109, and 110 are directly related to the range.

    I do not expect 109 -110 to be returned--please provide more information on how to reproduce this particular disconnect reason.

  • 0 in reply to Austin Tanner
    Prodigy 170 points

    Hi Austin,

    I was hoping to get a deeper understanding of why these codes get thrown, when it really looks like they're used interchangeably. 

    We don't really do anything special to get the disconnection reason 109. I connect to the CC3200 with the android tablet, walk to the other side of our office, and I see the disconnect happen at the tablet. When I get back to my desk, I see the device disconnected from peer device Reason 109. I have a print statement in the SimpleLinkWlanEventHandler which prints out the reason code for any disconnection. 

    We are testing out our solution with an amplifier. I don't think the amplifier is causing this issue, because I see this disconnect reason 109 on the LaunchXL with the chip antenna and no amplifier. We're not in any sort of anechoic chamber or anything, so there are lots of other Wi-Fi signals flying around. With the amp, we can sometimes get out to 200 ft (through the wall of the building), and sometimes we can only get to 100 ft before these failures happen. 

    Do you have any more info about each particular error/disconnect codes? 

  • 0 in reply to Jason Hiner
    TI__Expert 8255 points
    Hi Jason,

    Apologies--I meant to ask for more details on error -110. Is this also reproduced by walking out of range?
  • 0 in reply to Austin Tanner
    TI__Guru 63006 points
    Hi Jason,

    When you get out of the range of the access point you can get disconnection reason due to:
    1. missing of consecutive beacons - this will lead to reason 109 (this may take couple of seconds to get triggered, since we verify it after missing more than 10 consecutive beacons which are coming typically in 100ms intervals).
    2. In case you are transmitting, you may get the disconnection event even before due to missing acknowledgements - this leads to reason 100

    Regarding the connection errors:
    -103: refers to failure in the legacy 802.11 Authentication (I.e. 802.11 AUTH frame handshake) - it is not common, since most of the authentication issues are now discovered during the WPA/WPA2 4-way handshake (which will lead to error -109).
    -110 and -102: are unexpected events . If you do see those, we will need to get additional information from an air sniffer and/or the NWP logger (see instructions in processors.wiki.ti.com/.../CC3100_&_CC3200_Capture_NWP_Logs).

    Br,
    Kobi
  • 0 in reply to Austin Tanner
    Prodigy 170 points

    Austin,

    Ah okay. The -110 seems to happen during the connection phase about as often as the -109. I need to see if there's anything specific I can do to force it. I'd say probably not from what I've experienced so far. For those connection errors, we get them when we try to connect from far away rather than connecting close and moving away.

    -Jason

  • 0 in reply to Kobi Leibovitch
    Prodigy 170 points

    Kobi,

    Thank you for the added info. That is very helpful. So if a disconnect happens during transmit, we get the error code 110 (assuming that is what you meant, not 100). That clears that up. When you say you say you verify missing 10 beacons from an access point, is that the exact same in P2P mode? 

    We do see those -102 and -110 errors quite often. I don't have access to a wireless sniffer, so I'll see if I can get you some NWP logs. I was about to do this myself till I found out that they're useless to me since I can't read them. Should I send them to you privately?
    Thanks again.
    -Jason

  • 0 in reply to Jason Hiner
    TI__Expert 8255 points
    Hi Jason,

    Yes, reason code 110 was intended in Kobi's explanation above instead of 100.

    Also, please share the log captures on this thread.
  • 0 in reply to Austin Tanner
    Prodigy 170 points

    Austin/Kobi,

    Thanks for your help. We moved on past this testing into our application testing, and haven't seen that reason code in a while. I can reproduce the error by testing in our lab, but since it occurs at ranges so much further than what our application needs, we have let it go for now. If it pops up again, I'll make a new thread with some NWP logs and ask for further assistance there. 

    Thanks again for all your help. I'll mark Kobi's answer as the resolution since that was the information I was asking about.