-
Notifications
You must be signed in to change notification settings - Fork 3k
Extend and rework WiFi interface #2627
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -24,14 +24,15 @@ extern "C" { | |
#endif | ||
|
||
|
||
/** Enum of standardized error codes | ||
/** Enum of standardized error codes | ||
* | ||
* Valid error codes have negative values and may | ||
* be returned by any network operation. | ||
* | ||
* @enum nsapi_error_t | ||
*/ | ||
typedef enum nsapi_error { | ||
NSAPI_ERROR_OK = 0, /*!< no error */ | ||
NSAPI_ERROR_WOULD_BLOCK = -3001, /*!< no data is not available but call is non-blocking */ | ||
NSAPI_ERROR_UNSUPPORTED = -3002, /*!< unsupported functionality */ | ||
NSAPI_ERROR_PARAMETER = -3003, /*!< invalid configuration */ | ||
|
@@ -41,10 +42,36 @@ typedef enum nsapi_error { | |
NSAPI_ERROR_NO_MEMORY = -3007, /*!< memory resource not available */ | ||
NSAPI_ERROR_DNS_FAILURE = -3008, /*!< DNS failed to complete successfully */ | ||
NSAPI_ERROR_DHCP_FAILURE = -3009, /*!< DHCP failed to complete successfully */ | ||
NSAPI_ERROR_AUTH_FAILURE = -3010, /*!< connection to access point faield */ | ||
NSAPI_ERROR_DEVICE_ERROR = -3011, /*!< failure interfacing with the network procesor */ | ||
NSAPI_ERROR_AUTH_FAILURE = -3010, /*!< connection to access point failed */ | ||
NSAPI_ERROR_DEVICE_ERROR = -3011, /*!< failure interfacing with the network processor */ | ||
NSAPI_ERROR_TIMEOUT = -3012, /*!< operation timed out */ | ||
NSAPI_ERROR_BAD_SSID = -3013, /*!< ssid not found */ | ||
} nsapi_error_t; | ||
|
||
/** Enum of encryption types | ||
* | ||
* The security type specifies a particular security to use when | ||
* connected to a WiFi network | ||
*/ | ||
typedef enum nsapi_security { | ||
NSAPI_SECURITY_NONE = 0x0, /*!< open access point */ | ||
NSAPI_SECURITY_WEP = 0x1, /*!< phrase conforms to WEP */ | ||
NSAPI_SECURITY_WPA = 0x2, /*!< phrase conforms to WPA */ | ||
NSAPI_SECURITY_WPA2 = 0x3, /*!< phrase conforms to WPA2 */ | ||
NSAPI_SECURITY_WPA_WPA2 = 0x4, /*!< phrase conforms to WPA/WPA2 */ | ||
NSAPI_SECURITY_UNSSUPPORTED = 0xFF, /*!< unknown/unsupported security in scan results */ | ||
} nsapi_security_t; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 for moving these guys here |
||
|
||
/** Enum of interface states | ||
* | ||
* List of all possible states a WiFi network interface can be in | ||
*/ | ||
typedef enum nsapi_if_state { | ||
NSAPI_IF_STATE_NOT_CONNECTED = 0x0, | ||
NSAPI_IF_STATE_CONNECTING = 0x01, | ||
NSAPI_IF_STATE_CONNECTED = 0x02, | ||
NSAPI_IF_STATE_ERROR = 0xFF | ||
} nsapi_if_state_t; | ||
|
||
/** Maximum size of IP address representation | ||
*/ | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small request: Can we hold off on adopting the
nsapi_error_t
in this pr?I agree it should be adopted for clarity, but the return types should be kept consistent untile then to avoid confusion.
IMO: We should make a separate pr to adopt these types across the entire network-socket API:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I agree keeping them in sync would be good, but on the same note we sort of promised API for 5.2 for some partners to implement. If they do it once just so we can change the return type month later, they would have to go back to it and change it and also error handling code implemented for that 'new' API. Also I don't think there's much consistency required between interfaces on a technical level, as in it wouldn't cause anyone problems to have it different till we have time for the new PR. I would argue it will cause more confusion and work for apps to change the error checking code when we keep changing what the functions return.
I guess it's a call how much we don't want partners to go back and change things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree we should avoid changing code underneath our partner's feet as much as possible. However this change should be easy enough to accomplish without requiring user code changes.
I haven't verified this yet (some of the motivation for another pr) but these types would work:
Adopting the types would be opt in and suggested, but the only change a user would notice would possibly be (correct) warnings related to unexhausted switch case statements: