Skip to content
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

NameError: name 'kTLVError_Unavailable' is not defined #16

Closed
nickpl456 opened this issue Apr 29, 2018 · 3 comments
Closed

NameError: name 'kTLVError_Unavailable' is not defined #16

nickpl456 opened this issue Apr 29, 2018 · 3 comments
Labels

Comments

@nickpl456
Copy link

Trying to pair a Leviton DH6HD switch, it give the error:

"Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/root/.local/lib/python3.5/site-packages/homekit/pair.py", line 47, in
pairing = perform_pair_setup(conn, args.pin, iOSPairingId)
File "/root/.local/lib/python3.5/site-packages/homekit/protocol.py", line 77, in perform_pair_setup
error_handler(response_tlv[TLV.kTLVType_Error], "step 3")
File "/root/.local/lib/python3.5/site-packages/homekit/protocol.py", line 39, in error_handler
elif error == kTLVError_Unavailable:
NameError: name 'kTLVError_Unavailable' is not defined"

It seems like it's having a hard time decoding the Salt from the TLV packet. Here's the packet it's receiving:

0000 06 01 02 03 ff 79 f6 3f 5d 8d b5 4a 92 7f 76 c7
0010 b7 a2 a0 a7 44 51 86 90 9c b1 fe 00 a5 8b af bf
0020 5b f3 41 6e 25 66 1b 57 42 ac 9a d8 78 23 32 14
0030 38 7f 6e 87 aa 5b c3 7b 40 5b 31 66 44 e4 2b a5
0040 2a 33 1d e5 40 6a 18 9d 41 e3 2a 04 72 89 49 2d
0050 82 46 fb 6f 3f 08 7a e2 9f 71 2f 47 04 58 3f 93
0060 e0 d8 e5 09 8f 87 6b 92 c7 ca 8a e6 70 c7 f0 55
0070 43 e3 86 82 ab 4c 84 d6 23 d6 8f 33 95 ed f5 e4
0080 eb 6f 3c 3a b3 de 74 eb 34 1d 2a 45 a6 8a d8 a1
0090 ad 4a 37 4f 04 5f e0 66 c6 e6 02 e6 0a 12 67 c5
00a0 7f 21 2d 6d c8 08 bc 90 9e b2 0b 72 62 39 e2 5a
00b0 32 4d cb 5b 86 50 d3 28 3d 36 3c 62 db fe d4 a8
00c0 ec c0 c0 82 d8 42 13 66 05 eb 14 e6 a0 74 28 d4
00d0 ee ed 33 38 d1 dd 5e 8e 54 5f 42 88 a9 8a ff 6a
00e0 72 bd 24 52 0d ee a5 c1 1d 1a de 83 5f 88 eb 4b
00f0 cf 23 04 89 36 23 ae 38 fd 12 24 cf d4 3c 19 6a
0100 6b e2 56 33 03 81 ac 56 60 e8 2e 39 0c 80 6e 1d
0110 e2 f8 42 50 a5 ee d0 3e 18 15 d5 75 37 4b 50 7a
0120 0d af 72 a3 2a f1 bb 0a 53 16 2d 02 b6 87 ce de
0130 ac 22 9f d3 95 bf 18 6b e0 77 91 78 67 a9 38 cb
0140 3b 25 b1 cc a1 11 73 97 08 9b f6 b6 0b 59 a6 ec
0150 bc 68 46 3a e9 fe 6c e9 da d9 60 00 c3 5c 3f e1
0160 21 15 eb 99 15 90 c7 0a b5 28 c1 47 45 58 c9 a3
0170 d1 d9 37 3d cb 01 21 90 46 14 48 b6 59 16 9a 3c
0180 b9 a7 38 b5 59 07 15 02 10 38 49 e5 89 c4 02 d4
0190 17 7b a7 3f 69 57 e6 f4 de

@jlusiardi
Copy link
Owner

Hi,

Can you try to apply this patch?

diff --git a/homekit/protocol.py b/homekit/protocol.py
index de59d1b..4c1ade5 100644
--- a/homekit/protocol.py
+++ b/homekit/protocol.py
@@ -36,9 +36,9 @@ def error_handler(error, stage):
         raise homekit.exception.MaxPeersError(stage)
     elif error == TLV.kTLVError_MaxTries:
         raise homekit.exception.MaxTriesError(stage)
-    elif error == kTLVError_Unavailable:
+    elif error == TLV.kTLVError_Unavailable:
         raise homekit.exception.UnavailableError(stage)
-    elif error == kTLVError_Busy:
+    elif error == TLV.kTLVError_Busy:
         raise homekit.exception.BusyError(stage)
     else:
         raise homekit.exception.InvalidError(stage)

should fix it.

Regards
Joachim

jlusiardi added a commit that referenced this issue Apr 29, 2018
@nickpl456
Copy link
Author

nickpl456 commented Apr 30, 2018

Thank you for the quick reply!

That did fix the error about the error message :) but not the underlying problem. Now I get:

Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/root/.local/lib/python3.5/site-packages/homekit/pair.py", line 47, in
pairing = perform_pair_setup(conn, args.pin, iOSPairingId)
File "/root/.local/lib/python3.5/site-packages/homekit/protocol.py", line 77, in perform_pair_setup
error_handler(response_tlv[TLV.kTLVType_Error], "step 3")
File "/root/.local/lib/python3.5/site-packages/homekit/protocol.py", line 44, in error_handler
raise homekit.exception.InvalidError(stage)
homekit.exception.InvalidError: step 3

I take back what I said in the beginning, there seems to be just a general issue in reading the TLV altogether. I know just enough about programing to be dangerous, so with that said I added this the line to end of the Step 1 in protocol.py:

   connection.request('POST', '/pair-setup', request_tlv, headers)
   resp = connection.getresponse()
+  print (resp.read())
   response_tlv = TLV.decode_bytes(resp.read())

and the program outputs this: "b'\x06\x01\x02\x07\x01\x01'" which is not at all what the packet capture (attached) shows the response being.... however looking more closely at the packet capture I see the crazy little Leviton switch is sending 2 HTTP headers, the first one has the error code in it your program is responding to and the second has the expected response.

this is about as far as my knowledge can take me. I wrote a simple little bash script that sends:

POST /pair-setup HTTP/1.1
Host: 192.168.42.70
Content-Length: 6
Content-Type: application/pairing+tlv8

\x00\x01\x01\x06\x01\x01

and the switch sends back just 1 HTTP header as expected (with the stage 2 data in it), so I would guess there's something about the way Python is sending data that is confusing the switch, but I'm not sure where to start looking at that. My only guess looking at the packet capture is that Python is fragmenting the HTTP request into 2 packets and the http server running on this light switch is doing a bad job of reassembly.

One other note, I'm running Python 3.5.3 on a Raspberry Pi. This is the newest version of python that I'm offered through apt. Not sure if their might be an HTTP fix I'm missing.

Thanks again!

pcap.zip

EDIT: I see looking at the other open issue (#12), this is in-fact a problem with the interaction between Python breaking up the header and body into 2 packets and the Leviton switch. I'm new to Git but it seems that this issue is better described in #12 so I'd say you can close this. Sorry for the confusion.

@jlusiardi
Copy link
Owner

no problem with the confusion. Seems I have to really look at it. Guessing what @mjg59 monkey patched there...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants