bitlen must strictly be positive error ISUP

[user3472g]

PyCrate version 0.5.3 Python version 3.6

!/usr/bin/env python3

from pycrate_mobile import ISUP from binascii import unhexlify

q931_data = '080277f40504038090a528086d2e6a656d6563007e00850520a8060008914a0004014006006d002e006a0065 006d0065006322c00900003d1443616c6c67656e33323320706f67616373616d00000a302e39616c706861340000000a01061 206b800f8fdf93ecd9ed6119ab2000476222017005d0d8007000a01038f80231100c0fef93ecd9ed6119ab200047622201701 0001000100010002800100' q931 = ISUP.AccessTransport() q931.from_bytes(unhexlify(q931_data))

... ... File "/home/user/.local/lib/python3.6/site-packages/pycrate_core/utils_py3.py", line 1297, in bytes_to_uint raise(PycrateErr('bitlen must be strictly positive'))

[user3472g]

q931 = ISUP.Q931IE() q931.from_bytes(unhexlify(q931_data))

This, on the other hand, does not throw an error, but the q931 object is empty as though the data is not being parsed.

[p1-bmu]

Where does your q931_data come from ? What type of data is it ? Are you sure it is one of the Q.931 IE which can be transported over ISUP (as the AccessTransport) ?

[p1-bmu]

I can see this AccessTransport structure is certainly buggy here, however. I need to investigate a little bit. I you are able to give me some more context, this may ease to provide a fix.

[p1-bmu]

I made this fix: https://github.com/P1sec/pycrate/commit/356c5db3d8f34ecf8dcff8ad64ec7e029ee1fd86 This enables parsing without throwing dummy errors. On your data buffer, this corresponds however to nothing that really makes sense to me:

### AccessTransport ###
 ### Q931IE ###
  <S : 0 (variable length)>
  ### IE : 0 -> MIE ###
   <ID : 8 (Cause)>
   <Len : 2>
   <Val : 0x77f4>
 ### Q931IE ###
  <S : 0 (variable length)>
  ### IE : 0 -> MIE ###
   <ID : 5>
   <Len : 4>
   <Val : 0x038090a5>
 ### Q931IE ###
  <S : 0 (variable length)>
  ### IE : 0 -> MIE ###
   <ID : 40 (Display)>
   <Len : 8>
   <Val : 0x6d2e6a656d656300>
 ### Q931IE ###
  <S : 0 (variable length)>
  ### IE : 0 -> MIE ###
   <ID : 126 (User-user)>
   <Len : 0>
   <Val : 0x>
 ### Q931IE ###
  <S : 1 (single octet)>
  ### IE : 1 -> SIE ###
   <ID : 0 (Reserved)>
   ###  : 0 ###
    <Val : 5>
 ### Q931IE ###
  <S : 0 (variable length)>
  ### IE : 0 -> MIE ###
   <ID : 5>
   <Len : 32>
   <Val : 0xa8060008914a0004014006006d002e006a0065006d0065006322c00900003d14>
 ### Q931IE ###
  <S : 0 (variable length)>
  ### IE : 0 -> MIE ###
   <ID : 67 (Transit delay selection and indication)>
   <Len : 97>
   <Val : 0x6c6c67656e33323320706f67616373616d00000a302e39616c706861340000000a01061206b800f8fdf93ecd9ed6119ab2000476222017005d0d8007000a01038f80231100c0fef93ecd9ed6119ab2000476222017010001000100010002800100>

[user3472g]

thank you the buffer is example q.931 that might be associated with H.323 signaling whilst carrying H.225. It appeared at first that the Q931IE class in the ISUP module was a generic Q.931 parser.