NameError: name 'kTLVError_Unavailable' is not defined #16

Activity

1. jlusiardi commented on Apr 29, 2018

   

   jlusiardi

   on Apr 29, 2018

   Owner

   More actions

   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
2. jlusiardi

   added a commit that references this issue on Apr 29, 2018

   fix for issue #16

   bef34f2
3. nickpl456 commented on Apr 30, 2018

   

   nickpl456

   on Apr 30, 2018

   Last edited by nickpl456

   Author

   More actions

   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.
4. jlusiardi commented on Apr 30, 2018

   

   jlusiardi

   on Apr 30, 2018

   Owner

   More actions

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

   closed this as completedon Apr 30, 2018
6. jlusiardi

   added a commit that references this issue on May 1, 2018

   fixes the 2 packets issue (#12 and #16)

   61bf4e9
7. jlusiardi

   added

   bug

   on Jan 8, 2019