struct.error: bad char in struct format every once in a while

[SkyperTHC]

Hi,

during simple 'subscribe' (single thread) I randomly get the error below and the connection is terminated. Sometimes immediately after connect and sometimes it takes 20 minutes for the error to show. Wireshark shows that valid data is send (attached) but the lib falls over.

Using the ThingSpeaks MQTT broker as a peer. Looks like a valid 'Sub Ack' from the broker.

Connected log: Sending SUBSCRIBE (d0, m4) [(b'channels/1099999/subscribe/fields/field1/XXXXXX', 0)] log: Received SUBACK log: Received SUBACK Traceback (most recent call last): File "mqtt-ts-widget.py", line 61, in client.loop_forever() File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 1782, in loop_forever rc = self.loop(timeout, max_packets) File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 1177, in loop rc = self.loop_read(max_packets) File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 1568, in loop_read rc = self._packet_read() File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 2315, in _packet_read rc = self._packet_handle() File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 2960, in _packet_handle return self._handle_suback() File "/usr/local/lib/python3.7/dist-packages/paho/mqtt/client.py", line 3142, in _handle_suback (mid, packet) = struct.unpack(pack_format, self._in_packet['packet']) struct.error: bad char in struct format

-s

[ralight]

    def _handle_suback(self):
        self._easy_log(MQTT_LOG_DEBUG, "Received SUBACK")
        pack_format = "!H" + str(len(self._in_packet['packet']) - 2) + 's'
        (mid, packet) = struct.unpack(pack_format, self._in_packet['packet'])

struct.unpack would give struct.error: bad char in struct format if len(self._in_packet['packet']) is less than 2, and so pack_format ended up like "!H-1s". That suggests that the SUBACK packet is too short. The ones you show above look complete, are they the packets that correspond to the error?

[SkyperTHC]

    def _handle_suback(self):
        self._easy_log(MQTT_LOG_DEBUG, "Received SUBACK")
        pack_format = "!H" + str(len(self._in_packet['packet']) - 2) + 's'
        (mid, packet) = struct.unpack(pack_format, self._in_packet['packet'])

struct.unpack would give struct.error: bad char in struct format if len(self._in_packet['packet']) is less than 2, and so pack_format ended up like "!H-1s". That suggests that the SUBACK packet is too short. The ones you show above look complete, are they the packets that correspond to the error?

yes, I had the tcpdump running while the error occurred and the picture above is from that tcp dump.

[Adum888]

Hi So im running into a simmilar problem where i every now and then get the "bad char Error" during publishing Are there any known workarounds for this issue?

I'm using RobotFramework to send those msgs. They are sent wit qos=0 and retain=false Im on the latest version of the paho library

[rnwhitehead]

I was getting this but it turned out to be because I was calling loop_start() but then also trying to loop() in the main thread.

[whaou]

I'm in the same case: I use RobotFramework (qos=1) and randomly get the "bad char in struct format" error. Do you have any hint?

[kabannis]

It faced this issue with loop_forever, but not with loop_start/stop. To resolve it, I commented a "subscribe" line to a non existing topic and it worked. I think it happens when the subscription is "empty".

[kaijie0102]

client.connect(broker)
client.subscribe("test/topic")
client.loop_forever()

make sure you subscribe to a topic before you do loop_forever()

[MattBrittan]

Working through old issues tidying things up - if this is no longer an issue then please close it; otherwise I'll try to help resolve it.

@kaijie0102 - it's preferable to call subscribe in the on_connect callback (as shown in the examples) because, otherwise, the subscription may be lost if the connection is lost/re-established (a lot of users have issues with this).

@SkyperTHC - are you still having this issue? I'd be keen to add a bit of extra debug code to try and work out where things are going wrong (as per Rogers comments it looks like an issue with the packet length but that does not match up with the dump. As such the simplest way to track this down is to add extra logging (as it's not something I can replicate).