Hey guys,
Unfortunately there is no update on this topic. I have no response from Pandion developers so it is hard to fix this issue. The workaround, as mentioned before, is to use the old SSL method for encryption instead of TLS on port 5222.
Regards,
– Gato
Thks for your reply.
The only think that i dont understand is why it was working before (in wildfire 3.11) the new version.
Hey DeraZ,
The entire networking layer was replaced with new code for Wildfire 3.2.2 for scalability reasons. Anyway, it is still not clear to me why Pandion is having trouble reading content from the server after TLS was negotiated. The server is using practically the same code for TLS (startTLS) than for the old SSL method. Moreover, in my tests Pandion was able to read content from the server after TLS was successfully negotiated but after a few more packets it stopped reading content again. I need to get in contact with Sebaastian from Pandion to analyze this problem from both ends.
Regards,
– Gato
Not to beat this to death, but Miranda has the same problem as well. It is not just Pandion.
It appears that the main developer for Pandion (cbas on the Pandion forums) has a lot going on and Pandion isn’'t his top priority right now: http://forums.pandion.be/viewtopic.php?p=8401&highlight=#8401
Honestly this ordeal is causing me to look at switching clients to Spark. The development cycle on Pandion is just too long, especially when you have a high-class server like Wildfire that is constantly being improved and expanded.
I’‘m going to second the Miranda issue, we’'re seeing TLS connectivity problems with Miranda also since upgrading to Wildfire 3.2.2…
Miranda and Pandion same problem?
Nope! I take it back; we upgraded to Wildfire 3.2.2 and the problems we were having seem to be fixed. So looks like just Pandion is having the issue now.
yes. I just tried Miranda IM 0.6.7 with and without TLS and it successfully connected to the server. It seems that the problem only happens with Pandion.
Regards,
– Gato
Any news?
We have good news!!!
Our good friend ReAXeR found the problem and contacted me today. As described in JM-997 it was a problem in the sequence of initial stream headers. The problem has now been fixed and you can find the bug fix in the next nightly build. FYI, Openfire 3.2.3 (formerly Wildfire) will be released during the next week including this bug fix.
Regards,
– Gato
Yes
Good Job,
Thanks Reaxer and wildfire’'s team.
You’'re very professional
When for the wildfire 3.23?
Just wondering if the JM issue numbers are limited to three digits or not, in any case the overflow of -1000 is just 3 issues away.
LG
thank you guys.
I guess the time has finally come to move from 3.1.1 to 3.2…
Thank you Gato and Reaxer for your cooperative work.
turbo
JIRA itself has over 12,000 issues so I think it will be ok when Openfire hits 1,000.
Cheers,
Ryan
Great! Pandion with Wildfire 3.2.3. it work well.
Thanks.
Great.
Take care,
– Gato
I ahve updated Wildfire 3.2.3. Most of our users are using PSI as client, but Pandion users are facing some problem. When they sent the message sometime it does not appear like this.
Also let me know the standard setting for Pandion, as we are using Wildfire 3.2.3 at back end in corporate.
SK
We have wildfire 3.2.3. at backend and PSI and Pandion on fronend, can Pandion chat with each other?
I am gaeeting one way communication from Pandion to PSI only.
Please help me out.
SK
Hey SK,
Please update to Wildfire 3.2.4. It may be possible that users are sending some content in their messages that are leaving the server in an incorrect state (JM-991 and JM-1003).
Regards,
– Gato