RFC: cc3200: Support WPA-Enterprise networks (802.1x auth) #1592
Conversation
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
- Define WLAN.WPA_ENT in addition to WLAN.WEP, WLAN.WPA and WLAN.WPA2
- Define a bunch of WLAN.EAP_* constants for 802.1x EAP authentication methods
- If wlan.connect() is called with WLAN.WPA_ENT as the first arg, the auth kwarg expects
a tuple with five items (instead of two items, as used with WEP/WPA/WPA2.) Example:
wlan = WLAN(mode=WLAN.STA)
wlan.connect(WLAN.WPA_ENT, auth=(
'enterprise-ssid-802.1x', # SSID
'username', # Identity
'password', # Password
'anonymous ID', # Anonymous identity (may be: None)
WLAN.EAP_PEAP0_MSCHAPv2 # EAP phase 1 and 2 methods (details: drivers/cc3100/inc/wlan.h)
))
|
@noahwilliamsson thanks! I'll take a look. Hopefully we can remove most of the added constants and only keep a few. |
9167980 to
1cc81ed
Compare
nickzoic
pushed a commit
to nickzoic/micropython
that referenced
this pull request
Mar 2, 2019
final pin names, tested with final release
kadamski
added a commit
to kadamski/micropython
that referenced
this pull request
Feb 18, 2021
Initial support for machine.RTC on rp2 port. It only supports datetime() method and nothing else. The method gets/returns a tuple of 8 items, just like esp32 port, for example, but the usec parameter is ignored as the RP2 RTC only works up to seconds precision. The Pico RTC isn't very useful as the time is lost during reset and there seems to be no way to easily power up just the RTC clock with a low current voltage, but still there seems to be use-cases for that, see issues micropython#6831, and a thonny issue micropython#1592. It was also requested for inclusion on v1.15 roadmap on micropython#6832. Signed-off-by: Krzysztof Adamski <k@japko.eu>
kadamski
added a commit
to kadamski/micropython
that referenced
this pull request
Feb 19, 2021
Initial support for machine.RTC on rp2 port. It only supports datetime() method and nothing else. The method gets/returns a tuple of 8 items, just like esp32 port, for example, but the usec parameter is ignored as the RP2 RTC only works up to seconds precision. The Pico RTC isn't very useful as the time is lost during reset and there seems to be no way to easily power up just the RTC clock with a low current voltage, but still there seems to be use-cases for that, see issues micropython#6831, and a thonny issue micropython#1592. It was also requested for inclusion on v1.15 roadmap on micropython#6832. Signed-off-by: Krzysztof Adamski <k@japko.eu>
kadamski
added a commit
to kadamski/micropython
that referenced
this pull request
May 23, 2021
Initial support for machine.RTC on rp2 port. It only supports datetime() method and nothing else. The method gets/returns a tuple of 8 items, just like esp32 port, for example, but the usec parameter is ignored as the RP2 RTC only works up to seconds precision. The Pico RTC isn't very useful as the time is lost during reset and there seems to be no way to easily power up just the RTC clock with a low current voltage, but still there seems to be use-cases for that, see issues micropython#6831, and a thonny issue micropython#1592. It was also requested for inclusion on v1.15 roadmap on micropython#6832. Signed-off-by: Krzysztof Adamski <k@japko.eu>
dpgeorge
pushed a commit
that referenced
this pull request
Jun 12, 2021
Initial support for machine.RTC on rp2 port. It only supports datetime() method and nothing else. The method gets/returns a tuple of 8 items, just like esp32 port, for example, but the usec parameter is ignored as the RP2 RTC only works up to seconds precision. The Pico RTC isn't very useful as the time is lost during reset and there seems to be no way to easily power up just the RTC clock with a low current voltage, but still there seems to be use-cases for that, see issues #6831, and a Thonny issue #1592. It was also requested for inclusion on v1.15 roadmap on #6832. Signed-off-by: Krzysztof Adamski <k@japko.eu>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The CC3200 used in the WiPy boards supports WPA-Enterprise with 802.1x authentication but this functionality is currently not exposed in the Python API. This PR takes a stab at fixing that by extending
WLAN.connect()and adding a bunch of new class constants.Size changes as reported by
arm-none-eabi-sizefor a release build of git master (af3e454) vs. this PR for WPA-Enterprise support (7690423d)I have some reservations about what the best way is to implement support for the additional 802.1x parameters, hence the RFC.
Using the current Python API for the WiPy board, connections to networks may be established like this (docs here):
With this patch I've simply extended the tuple in the
authkwarg to expect five items whenWLAN.WPA_ENTis used inwlan.connect(). Example:wlan.connect(WLAN.WPA_ENT, auth=( 'enterprise-ssid-802.1x', # SSID 'username', # Identity 'password', # Password 'anonymous ID', # Anonymous identity (may be: None) WLAN.EAP_PEAP0_MSCHAPv2 # EAP phase 1 and 2 methods (details: drivers/cc3100/inc/wlan.h) ))
I'm not entirely happy with a long list of unnamed arguments, where the second one is also not of the same kind (identity vs. key) as in the other security protocols supported. Feedback is welcome on how to make this API friendlier.
Additionally, I included QSTRs for all of the EAP authentication methods the CC3100/CC3200 support, which add to the code size. In practise, I guess the most popular mechanisms are EAP-TLS (client certs) and PEAPv0/EAP-MSCHAPv2 (common in the Windows world), so it would be possible to trade a few bytes for less flexibility.