| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, bitlbee's ssl_handshake calls the callback with an error
status and calls ssl_disconnect().
In this plugin fb_mqtt_error(), calls fb_mqtt_close(), which called
ssl_disconnect() on priv->ssl.
This fix prevents that double ssl_disconnect() by setting priv->ssl to
null, so that fb_mqtt_close() cleans everything except that.
Fixes #82
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is namely for the RedHat guys maintaining RHEL 6.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Any call to fb_mqtt_write() can result in an error writing to the
socket, which means fb_mqtt_close() can be called and the mqtt object is
invalidated.
Trying to write priv->tev = 0 at that point is a small invalid write,
but not enough to make it crash. The real problem is fb_mqtt_timeout(),
which adds a 90 second delay after which it *does* crash, often when a
different account already finished logging.
The fix here takes advantage of the cleanup done by fb_mqtt_close() - by
adding the timeout before that call, it will find a nonzero priv->tev
and remove it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This was the only line that assigned anything to priv->wev, and it was
behind an (incorrect) condition that checked if it's nonzero.
That would have replaced priv->wev if the condition was ever true, but
since it wasn't, the only result is potentially delayed writes
(for example, filling the write buffer and only writing the rest a
minute later when pinging the server)
The new condition also checks the return value of fb_mqtt_cb_write(),
which is true if it should continue writing, or false otherwise.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was mqtt->rbuf->len previously, the length of the bytearray, which
doesn't make a lot of sense - it resulted in reading 2, 4, 8, 16, 32
bytes and when it reached a high enough number, ssl_read would either:
1. Stop because the socket buffer got empty (the main reason it kinda
worked most of the time), or
2. Continue reading into the next packet
And continuing to read means not just a desync but also that remz - rize
(remaining bytes - read bytes) is negative, or more precisely, a huge
number, since remz is unsigned.
So it gets stuck reading ~2**64 bytes into that buffer, thinking it's a
neverending packet, and that means not getting pongs. So it timeouts.
The fix is trivial - just make it read exactly the amount of bytes it
needs to read (remz), never more than that.
|
| | |
|
| |
|
|
|
| |
This enables various format string security checks by the compiler in
attempt to avoid run-time failures.
|
| |
|
|
|
|
| |
As of now, the connection error code is only a general error code. It
should be the actual error code retrieved from the MQTT service. This
was an oversight when implementing the original MQTT interface.
|
| |
|
|
|
| |
The connected state should be reset when the connection is closed. This
was an oversight when implementing the original MQTT interface.
|
| |
|
|
|
|
|
|
|
| |
As it stands, a connection is declared as being timed out if it has not
heard back from the server with a ping response in one keep-alive time
interval. However, the MQTT specification states that a connection is
only declared timed out after one and a half time intervals. While the
effects of this oversight may not be immediately present, over a period
uptime, the connection may fall victim to preemptive timeouts.
|
| |
|
