tserong / lifx-hacks

LIFX Hacks
GNU Affero General Public License v3.0
46 stars 13 forks source link

Help getting started #5

Open GitCatTails opened 2 years ago

GitCatTails commented 2 years ago

Hi,

I am relatively new to Linux, so please forgive my ignorance about any questions.
But I was able to clone into your repo, run makepkg -si, and cd into /lifx-onboard-git/pkg//lifx-onboard-git/usr/bin. Then I tried to run ./onboard <ssid> <password> with my network credentials in place of "ssid" & "password".

Nothing happened for a few seconds, then the output was:

Traceback (most recent call last):
  File "/home/<username>/lifx-onboard-git/pkg/lifx-onboard-git/usr/bin/./onboard", line 57, in <module>
    sock.connect(('172.16.0.1', 56700))
  File "/usr/lib/python3.9/ssl.py", line 1342, in connect
    self._real_connect(addr, False)
  File "/usr/lib/python3.9/ssl.py", line 1329, in _real_connect
    super().connect(addr)
TimeoutError: [Errno 110] Connection timed out

I do know how to edit files with Nano. And was a little confused when saw 'lines 1342/1329' because I was like, <<hold on, there aren't even that many lines in this script? ;'D >>

Basically, I'm not sure what I should be doing, or in what order to go about doing it ^-^' I have used Lifx bulbs in the past by connecting them to a 2GHz network via the iOS app. But have since become more concerned about privacy issues, especially in the mobile apps department. So for that reason, I haven't tried it with the Android app.
However, I did find your short play to be very entertaining & quite reflective of my own frustrations about these things (minus all the upper-level technical expertise, that I do not have! ;'D )

Is there a series of basic steps you could give on how to get the bulbs connected to a network? And am I even in the right place trying the script for that purpose?
Appreciate in advance any help or insight you might have :-)

VanGomeo commented 1 year ago

Bump, I'm in the same boat as you. I have the b22 original kickstarted lifx bulbs. Initially they were coming up as a secured SSID, which I connected to using the default "lifx1234" password. However they failed to get connected to the wifi network in the lifx app and now won't show up at all as a network in wifi list; no matter how many times I reset them (but flipped the switch which is on these first generation bulbs).

So yes, any help and guidance for a dumb idiot like me would be immensely grateful. When the bulbs turn onn (after a rest); they flash red/green/blue and then apart from the slight dimming (which I think indicates they are in recovery mode), it would be nice to know how to get these rediscoverable as an SSID in the network list. Then a step by step guide on how to implement your python script would be fantastic. I'm using macOS.

tserong commented 1 year ago

Unfortunately I'm not going to be able to help if the factory reset of the bulbs doesn't work. You need to get them back to a state where their own wifi AP is active, so you can onboard them. If factory reset isn't working, I'd suggest contacting LIFX directly, or maybe try their developer forum (https://community.lifx.com/).

As for using this script, it shouldn't be necessary to clone the whole repo or make a package or anything. You should only need the onboard.py script itself. If you go to https://github.com/tserong/lifx-hacks/blob/master/onboard.py, over on the right, just above the script itself, are a few little buttons, one labelled "raw", then two to the right of that there's a download button. That should download the script.

Once you've got the script on your laptop/desktop/whatever computer, you need to:

  1. Connect your computer to the LIFX bulb's WiFI access point
  2. Open a terminal window
  3. Change to the directory the script is in, and run the script.

I don't have Mac OS, but let's pretend your downloaded files end up in a directory called Downloads. You'll want to do something like this:

cd Downloads
chmod u+x onboard.py
./onboard.py SSID PASSWORD

But replace SSID and PASSWORD with your actual wifi SSID and password. If these contain spaces you'll need to put them in quotes, e.g. 'ssid with spaces'.

As an alternative to making the script executable (chmod u+x onboard.py) it should also work if you run it as python3 onboard.py SSID PASSWORD.

VanGomeo commented 1 year ago

Thanks Tim! I managed to reset the bulbs and get them to broadcast their Wifi AP. I followed the steps you provided, and in the terminal window I get the return command: zsh: no matches found: PASSWORD

Where PASSWORD is my actual password. Also thanks for the response, I wasn't expecting you would still be active on here. What a pleasant surprise.

I should add that my password contains a special character (an asterisk). Would that be part of the reason why it's returning that command line error?

tserong commented 1 year ago

I should add that my password contains a special character (an asterisk). Would that be part of the reason why it's returning that command line error?

Yeah, the '*' is probably making zsh try to treat the password as a filename to be expanded. Try sticking the password in quotes e.g. 'PASSWORD' or "PASSWORD" (this can get fiddly if your password also contains quote characters too)

VanGomeo commented 1 year ago

Ok, that seemed to do something. This is what I got back:

Traceback (most recent call last):
  File "/Users/Gomeo/Downloads/./onboard.py", line 64, in <module>
    sock.connect(('172.16.0.1', 56700))
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/ssl.py", line 1342, in connect
    self._real_connect(addr, False)
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/ssl.py", line 1333, in _real_connect
    self.do_handshake()
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/ssl.py", line 1309, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:1129)

Did it work? It's still broadcasting as a protected wifi AP:

image

Am I suppose to run through the normal process of connecting it via the lifx app afterwards or should this step be covered by the onboard.py file and automatically appear in the lifx app under the network?

tserong commented 1 year ago

No, alas, the fact that you got that error means the script failed to connect to the bulb, due to some problem making a secure connection. That the bulb's AP is still visible means it's not onboarded. I've done some further testing here and as best as I can tell newer versions of python don't allow certain older SSL ciphers / key sizes, which the Lifx bulb is presumably using. I need to experiment a bit more to see if I can "fix" (i.e. workaround) this.

VanGomeo commented 1 year ago

Let me know how I can help, if at all possible. Given your hypothesis around new python version being the limitation, would it be worth me trying to download and install a legacy version of Python on my Mac to see if I can get around this issue? If so, what version would you suggest?

For reference, my lifx bulbs are around 10 years old I believe (from the original kickstarter).

tserong commented 1 year ago

Let's not worry about trying to get an older python installed just yet :-) I happen to have an original bulb here, and I think I've found a way to solve this. Please try downloading this different version of the script, and use it in place of the one you downloaded before:

https://github.com/tserong/lifx-hacks/blob/wip-support-ancient-bulbs/onboard.py

Note lines 63-65 mention TLSv1, @SECLEVEL=0 and OP_LEGACY_SERVER_CONNECT. That's the magic that should make it talk to the original bulbs.

If it works, you should see no errors, and the text "LIFX bulb probably onboarded. Best of luck ;-)". Once that's done, if you open the LIFX app, it should find the bulb and give you the option to finish setting it up.

VanGomeo commented 1 year ago

I love that you named it "support-ancient-bulbs" lol.

Here is what I get back; note it comes back instantly as soon as I hit 'y' to continue:

Traceback (most recent call last):
  File "/Users/Gomeo/Downloads/./onboard.py", line 64, in <module>
    ctx.set_ciphers('@SECLEVEL=0:ALL')
ssl.SSLError: ('No cipher can be selected.',)
tserong commented 1 year ago

Thanks :-)

I assume it doesn't like "ALL" (that worked fine for me, but then I'm testing on Linux, not Mac OS X, so there'll be some differences).

If you don't mind indulging me, please try re-downloading https://github.com/tserong/lifx-hacks/blob/wip-support-ancient-bulbs/onboard.py and give it another shot. I've updated the set_ciphers line to include the specific set of default ciphers from from an older python/openssl version.

If that works, great!

If it doesn't work, please run the following commands in the terminal, and copy-and-paste their output in here, so I know exactly what openssl version and ciphers are available:

openssl version

openssl ciphers

Also, if it didn't work with the long list of ciphers, you might try commenting out line 65 of the script (put a '#' at the start), and un-commenting line 66 (remove the '#' at the start), so it only tries to use AES256-SHA, which appears to be the cipher used by my original Lifx bulb.

VanGomeo commented 1 year ago

Happy to indulge! When running the re-downloaded script as is:

Traceback (most recent call last):
  File "/Users/Gomeo/Downloads/./onboard.py", line 65, in <module>
    ctx.set_ciphers('@SECLEVEL=0:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:DH+CHACHA20:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:RSA+AESGCM:RSA+AES:RSA+HIGH:!aNULL:!eNULL:!MD5:!3DES')
ssl.SSLError: ('No cipher can be selected.',)

Altering the script (in Xcode, unsure if that matters) according to your instructions:

image

Resulting returned error:

Traceback (most recent call last):
  File "/Users/Gomeo/Downloads/./onboard.py", line 66, in <module>
    ctx.set_ciphers('@SECLEVEL=0:AES256-SHA')
ssl.SSLError: ('No cipher can be selected.',)

Openssl Version: LibreSSL 3.3.6

Openssl Ciphers: AEAD-CHACHA20-POLY1305-SHA256:AEAD-AES256-GCM-SHA384:AEAD-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:GOST2012256-GOST89-GOST89:DHE-RSA-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA256-SHA:GOST2001-GOST89-GOST89:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA256:CAMELLIA128-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA

Also thanks for such rapid responses, especially on a weekend 😌 Is there anyway I can check what cipher is being used on my Lifx bulbs or is it trial and error?

tserong commented 1 year ago

Also thanks for such rapid responses, especially on a weekend 😌

Hey, I'm delighted you're happy to try stuff! I'm intrigued as to why this isn't working, and I'm sure you won't be the only person to need this fixed, so here we are :-)

Is there anyway I can check what cipher is being used on my Lifx bulbs or is it trial and error?

You can try running this from a terminal:

openssl s_client -connect 172.16.0.1:56700

That will just try to open a connection to the bulb, but will otherwise do nothing. Assuming it works it'll print out a whole bunch of stuff including the server certificate and ciphers being used, then you can hit CTRL-C to kill it. Can you please paste the output of that in here too?

I've also done a little more digging and it looks like libressl 3.3.6 might not understand SECLEVEL. It may be interesting to see if just dropping that bit works, e.g., try each of these variants on ctx.set_ciphers() (editing in XCode is fine, BTW):

ctx.set_ciphers('ALL')

ctx.set_ciphers('TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:DH+CHACHA20:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:RSA+AESGCM:RSA+AES:RSA+HIGH:!aNULL:!eNULL:!MD5:!3DES')

ctx.set_ciphers('AES256-SHA')
VanGomeo commented 1 year ago

I connected to the Wifi AP of each bulb; ran openssl s_client -connect 172.16.0.1:56700 and got this:

CONNECTED(00000003)
read:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 287 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Start Time: 1690630215
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

With ctx.set_ciphers('ALL')

image

Result (note this is the longest I've seen it 'thinking' before returning a result):

Traceback (most recent call last):
  File "/Users/Gomeo/Downloads/./onboard.py", line 69, in <module>
    sock.connect(('172.16.0.1', 56700))
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/ssl.py", line 1342, in connect
    self._real_connect(addr, False)
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/ssl.py", line 1333, in _real_connect
    self.do_handshake()
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/ssl.py", line 1309, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:1129)

This was the exactly the same result for the other two variants you provided as well.

Seeing (NONE) appear so many times both shocked me and made me laugh. Not sure what i was expecting. I didn't have to kill it with CTRL-C because what it printed was so brief.

tserong commented 1 year ago

That output is almost the same as what I get with OpenSSL 3.1.1:

> openssl version
OpenSSL 3.1.1 30 May 2023 (Library: OpenSSL 3.1.1 30 May 2023)

> openssl s_client -connect 172.16.0.1:56700
CONNECTED(00000003)
405781D5EC7F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:ssl/statem/statem_lib.c:1947:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 79 bytes and written 308 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

The difference is, with OpenSSL I can make it play nice like this:

> openssl s_client -cipher @SECLEVEL=0:ALL -legacy_renegotiation -connect 172.16.0.1:56700
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 C = AU, ST = VIC, L = Cremorne, O = LIFX, OU = LIFX, CN = lifx.co
verify error:num=18:self-signed certificate
verify return:1
depth=0 C = AU, ST = VIC, L = Cremorne, O = LIFX, OU = LIFX, CN = lifx.co
verify error:num=10:certificate has expired
notAfter=Mar 26 09:56:18 2015 GMT
verify return:1
depth=0 C = AU, ST = VIC, L = Cremorne, O = LIFX, OU = LIFX, CN = lifx.co
notAfter=Mar 26 09:56:18 2015 GMT
verify return:1
---
Certificate chain
 0 s:C = AU, ST = VIC, L = Cremorne, O = LIFX, OU = LIFX, CN = lifx.co
   i:C = AU, ST = VIC, L = Cremorne, O = LIFX, OU = LIFX, CN = lifx.co
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
   v:NotBefore: Mar 26 09:56:18 2014 GMT; NotAfter: Mar 26 09:56:18 2015 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDODCCAiACCQCwvVra2fKqWTANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJB
VTEMMAoGA1UECAwDVklDMREwDwYDVQQHDAhDcmVtb3JuZTENMAsGA1UECgwETElG
WDENMAsGA1UECwwETElGWDEQMA4GA1UEAwwHbGlmeC5jbzAeFw0xNDAzMjYwOTU2
MThaFw0xNTAzMjYwOTU2MThaMF4xCzAJBgNVBAYTAkFVMQwwCgYDVQQIDANWSUMx
ETAPBgNVBAcMCENyZW1vcm5lMQ0wCwYDVQQKDARMSUZYMQ0wCwYDVQQLDARMSUZY
MRAwDgYDVQQDDAdsaWZ4LmNvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAu04Mpr05EfsqyoEXYJE7RXp96rrDFqWH9QKruRxP0UXVGL1djAbZMblYRFho
shwrqD+rVwEpxoctMuN2JEKEBBr6CKPYRHAAfliwXHRLmRpc0FvB8Ce9+n3D5EP6
oJME9ThRo41sNfh6lqkvpxLyixKFWkxRR/5aOHnVPDLmLRv0nOIlTNE3U+/xk+BE
K5VRc28INL0Dg9puOoLy9cJJ6acxECHF2yJoSsEZet3L35msdj8jS6avpjuwFfq7
Yaml+oqb6I83mIzD7JP9vpRSOWdd0L68DV4Fj8whXlAJiwKdbXIebgX46a9txrn7
93B6QVnc6x6AX75JdHMsfhOMhwIDAQABMA0GCSqGSIb3DQEBBQUAA4IBAQAI2u9A
HL3jxvNw7xMQEJnNQ+8jfKA9u1/M7+OYQvLFSvY7XFGeRu5Z0/RBvLuymnIH7uMZ
SQLFeaPCF2mfIWTdnA1FUiKM0Zwt+3IfS3Iy30bQgx5ikI8cyFpm3malvwsWAq22
TmNOlE4Q2PK8t1epwpNEr73ZopgbBe7O24m4rxCMkEylwSFLHBVgwHnHpY28AUWs
kRhJN0+oMuu3FByEUnxjGdD+s/Zyj88bREVaRBB0XiqLbC+h5FwJOlQiZD4nVxq1
KQ7ihDXcC4Awo/gTZ8jmAde7PBM0LUgYm6daKKsmHhT114nMhyJ6ycSplJerAj/g
d2xeWi3uhboHyeoZ
-----END CERTIFICATE-----
subject=C = AU, ST = VIC, L = Cremorne, O = LIFX, OU = LIFX, CN = lifx.co
issuer=C = AU, ST = VIC, L = Cremorne, O = LIFX, OU = LIFX, CN = lifx.co
---
No client certificate CA names sent
---
SSL handshake has read 990 bytes and written 741 bytes
Verification error: certificate has expired
---
New, SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 8D5224C6AB9F14DAA80221D843373F25C35BB63706ADC6D6D045E7DC91ED29C3
    Session-ID-ctx: 
    Master-Key: 9BE373B2739B85D2251ED572C4BCAA4153F23B16FCFC34322508CD887E623287C433811AA34C2293151112838B49836D
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1690669584
    Timeout   : 7200 (sec)
    Verify return code: 10 (certificate has expired)
    Extended master secret: no
---

I've now built a local copy of LibreSSL 3.3.6 and I'm getting the same thing with that as you are:

> openssl version
LibreSSL 3.3.6

> openssl s_client -connect 172.16.0.1:56700
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 287 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Start Time: 1690688371
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

I still need to figure out what I need to do differently with LibreSSL to get it to work, given that version doesn't support @SECLEVEL

VanGomeo commented 1 year ago

I'm not technically minded so again forgive the dumb question.

Is this a macOS issue or a Lifx Bulb issue?

If macOS issue, would it be solved by updating LibreSSL?

tserong commented 1 year ago

I'm not technically minded so again forgive the dumb question.

It's not a dumb question :-)

Is this a macOS issue or a Lifx Bulb issue?

I'd argue it's a bit of both. The underlying problem is that the original Lifx bulbs apparently only support TLSv1 (that's a version of the protocol used for doing secure web connections, e.g. HTTPS). That protocol version was apparently officially deprecated in 2021, i.e. shouldn't be used anymore, because v1 uses older, crappier ciphers and hash algorithms than are available in the newer TLSv1.2 and v1.3.

Presumably because of that deprecation, newer versions of openssl/libressl have TLSv1 turned off by default, which is what I'm trying to turn back on by messing with SECLEVEL and other options.

If macOS issue, would it be solved by updating LibreSSL?

Maybe. I've done a quick test with libressl 3.8.0, which looks promising (at least I seem to see a connection and a certificate now). Do you know what newer versions of LibreSSL you have available to install?

Alternately, if you have access to an older system (laptop, desktop, whatever) from a few years back, that might work too, as older versions would presumably still support the older TLSv1 out of the box.

VanGomeo commented 1 year ago

Maybe. I've done a quick test with libressl 3.8.0, which looks promising (at least I seem to see a connection and a certificate now). Do you know what newer versions of LibreSSL you have available to install

It looks like I can install LibreSSL 3.8.0 through macports. Would you suggest I do so?

Alternately, if you have access to an older system (laptop, desktop, whatever) from a few years back, that might work too, as older versions would presumably still support the older TLSv1 out of the box.

I tried on a macbook pro 2014 model, running LibreSSL 2.8.3. For reference I used the latest 'onboard.py' in this issue's thread; with line 66 changed to ctx.set_ciphers('ALL'). I've been sitting here for 30 minutes and it's still thinking about it... How long does it normally take in your experience? I should probably just kill it right... ?

tserong commented 1 year ago

It should complete almost instantly (think: seconds, not minutes), so you should kill it if you didn't already :-)

What happens if you try openssl s_client -connect 172.16.0.1:56700 on the 2014 macbook?

I don't know if installing LibreSSL 3.8.0 will actually help or not, but if you're up for it, may as well give it a shot. Worst case I assume you can just uninstall it again if it doesn't help?

oddpxl commented 9 months ago

hey

Amazing to find this script !!!

Trying to get it to work... ( it would be SO amazing to finally own the onboarding :)

I didn't get the cipher to work so I added the write to disk hack..but now I'm getting this error...

openssl s_client -connect 172.16.0.1:56700 < onboard.packet Connecting to 172.16.0.1 CONNECTED(00000003) 401C4DDA01000000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:646: no peer certificate available No client certificate CA names sent SSL handshake has read 0 bytes and written 306 bytes Verification: OK New, (NONE), Cipher is (NONE) This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)

Any ideas ? :)

..from what I understand of the above it seems the bulb is listening...but it just sits there and don't seem to attempt using the new credentials ?

oddpxl commented 9 months ago

Also tried this...

openssl s_client -cipher @SECLEVEL=0:ALL -legacy_renegotiation -connect 172.16.0.1:56700

Connecting to 172.16.0.1 CONNECTED(00000003) 401C4DDA01000000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:646: no peer certificate available No client certificate CA names sent SSL handshake has read 0 bytes and written 428 bytes Verification: OK New, (NONE), Cipher is (NONE) This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok)