Bitlbee fails to connect

[mverboom]

Hi,

I know bitlbee is not supported, but I ran into an issue with bitlbee connecting to singald with purple-signald. After some debugging, it seems to happen when requesting the list of contacts. The reply seems to be over 20KB of json on my account, and it looks like this is sent in chunks. At least, when looking at comms.c, the read returns 0. This exits the callback function. But every time the callback function is called, it resets the buffer: // reset buffer *sa->input_buffer = 0; All data is collected, but overwriting, resulting in incorrect json which can't be parsed. I've tested without this reset, everything seems to work fine.

Is the reset really required?

Regards,

Mark

[hoehermann]

Hi Mark

I want bitlbee to be supported, I just cannot spend time to actively test against it. You have now won the honorable title of "the guy who is using purple-signald with bitlbee I can ask questions to". :)

Indeed, it looks like writing the null byte is not necessary. Thank you for pointing it out. In fact, I noticed that the parser does not need null termination at all, but rather explizit length specification. I am experiencing some problems with the parser failing sometimes (see 5629edd for example). I might have improved the situation for both of us. Is 1de71ce working for you?

Kind Regards
Hermann

[mverboom]

Hi Hermann,

Thanks for the fast reply!

I want bitlbee to be supported, I just cannot spend time to actively test against it.

I completely understand. Was already very happy there was some kind of support for bitlbee :)

Indeed, it looks like writing the null byte is not necessary. Thank you for pointing it out. In fact, I noticed that the parser does not need null termination at all, but rather explizit length specification. I am experiencing some problems with the parser failing sometimes (see 5629edd for example). I might have improved the situation for both of us. Is 1de71ce working for you?

I will compile it and do a test, will let you know!

Regards,

Mark

[mverboom]

Hi Hermann,

Did a compile and test, but it doesn't work. I think the problem is in comms.c, signald_read_cb:

sa->input_buffer_position = sa->input_buffer;

At entry of the function I think the position is set to the start of the input_buffer. When I comment out those lines, another call to signald_read_cb continues filling the buffer, and I no longer get the parsing errors. Sorry about the lack of detail, was just a quick test..

Regards,

Mark

[hoehermann]

Oh, yeah. You are totally right. Initialization of the buffer write pointer should happen only once. In fact, that happens during initialization in login.c. It is totally out of place at the start of signald_read_cb. I changed it in 3b1e1d8. I did not see that while preparing the previous commit. Thank you for pointing that out. We need to reset the buffer write pointer at some time, but only after parsing.

[mverboom]

Did a quick rebuild and it seems to work fine now. Will keep running this one to see if it causes problems, but I don't think so. It normally happened at login due to the larger contact list message.

[hoehermann]

Nice to hear it looks fixed. In case the problem manifests again, feel free to re-open this issue.