No announcement yet.

Weird string compare function in synapse module

  • Filter
  • Time
  • Show
Clear All
new posts

  • Weird string compare function in synapse module

    I have a SM200/SM220 module running a firmware(2.5.3 with AES-128).
    When I tried the string compare function, I got some unexpected results as:

    def DebugStringCmp():
    StringA = '\x61\x14\x8c'
    StringB = '\x61\xc6\x2b'
    #StringB = '\x61\x14\x2b'

    if StringA > StringB:
    result = 'TRUE'
    result = 'FALSE'
    mcastRpc(1,5,'logEvent', StringA + StringB + result)

    From the sniffer: I got the "result" as "TRUE", which should be "False".

    Is there anyone know whether this is an issue in that version firmware or I missed something?


  • #2
    Bug confirmed on both 2.5.6 and 2.8.2. It looks like the comparison is wrong whenever two corresponding characters differ by 128 or more. I suspect this is the same basic problem as a former bug that caused integer comparison to fail when the two values differed by more than 32K.

    There may be some issues in actually fixing this. Synapse's SleepyMesh code relies on comparisons just like the one you show in order to determine who the leader is; the incorrect comparison chooses the "wrong" leader, but that's not actually a problem as long as everyone has the same bug. Chaos would result on a network with a mixture of fixed and unfixed nodes.


    • #3
      Thanks Jason.

      You explanation gives some indications, but I cannot tell how the string comparison works.
      When I tried following function, I got the right result even the difference between the two digital number is beyond 128.
      testA = '\x14'
      testB = '\xc6'

      if ord(testA) > ord(testB):
      result = 'cTRUE'
      result = 'cFALSE'
      mcastRpc(1,5,'logEvent', testA + testB + result)


      • #4
        You aren't comparing strings any more, you're comparing character codes.


        • #5
          So the string comparison function is not implemented as comparing the each char one by one. Is it correct?


          • #6
            It is, but apparently the difference between corresponding characters is held in an 8-bit variable - which introduces the possibility of overflow. When you write the code yourself in SNAPpy, you're using 16-bit integers - even if the integer comparison bug was still around, two characters cannot differ by enough to trigger it.


            • #7
              Thank you Joson, I get it!