Guam error after update to 0.9.2



  • I have the same problem. Is there a working solution by now?
    Thanks and best



  • Many thanks to all, this thread save my day!
    Raynald


  • Kolabian

    I'm pretty sure this issue has been fixed in guam-0.9.2-2.1. But there are still some other issues.



  • Depending on the number of imap folders mails are no longer loaded or only header informations without content - therefore most of the used clients without active sync are useless. 0.8.3 it worked fine. Unfortunately I'm not able to roll back to 0.8.3. Is there a short description for a downgrade?
    Thanks and best, Angelo



  • Thank you "armageddon"! I changed the package and it is working again! Best, Angelo



  • Any update on this? Is Guam being worked on?



  • Same here: imap actions pretty slow. After downgrade to v0.8.3: everything all right again. Thanks armageddon !



  • Guam 0.9.2-3.2 still hopelessly broken :(

    What's going on with this? Can I provide some kind of debugging info to help diagnose this?



  • 0.9.2-5.2 is still broken with Thunderbird.

    I've done some more work attempting to diagnose the problem, and it appears Guam is not passing the "DONE" command on to the imap server when an IDLE period is complete, so Thunderbird gets stuck waiting for the OK it expects, that never comes.

    Eventually the connection times out, a new connection is created and the next command is issued, this works fine until the next IDLE period when it again gets stuck, and times out. Rinse...repeat.

    I will now proceed to attempt to modify code I've never seen in a language I've never used, to create a patch...

    If anyone's interested, here are the packet caps side by side: https://i.imgur.com/9I7XQQs.png
    Left hand side is Guam<->Cyrus on the loopback interface; Right is Thunderbird<->Guam



  • Hrmmm, I see there's a patch file in the source RPM (guam-0.9.2-T25795.patch) which claims to address this very issue, is it not being applied when the binary RPM is built?



  • OK, I've spent the day burrowing deeper and deeper into this code, and yes, the patch is being applied, but it's pointless even applying it since the code will NEVER send the data to the server if it's not prefixed with a tag.

    In kolab_guam_session.erl, in the function "apply_ruleset_clientside" this logic is the cause:

    { PostAction, SplitCommand, SplitResetTrigger } =
        case CurrentCommandSplit of
            undefined ->
                case eimap_utils:split_command_into_components(ClientData) of
                    { _Tag, <<>>, <<>> } ->
                        { buffer_data, undefined, reset_for_next_client_command };
                    { _Tag, Command, _Data } = Split ->
                        { perform_passthrough, Split, when_to_reset_split(Command) }
                end;
            _ ->  { perform_passthrough, CurrentCommandSplit, reset_for_next_client_command }
        end,
    

    So when the client sends just "DONE" at the end of an idle period, this has no tag so split_command_into_components fails to split it and the data is buffered instead of passed through.

    At this point the whole process is locked, and can never continue regardless of what data the client sends, because the buffer always begins with "DONE" which sends us through the buffer_data codepath again. So the buffer grows and grows and never gets passed on to the server. The connection eventually times out, a new connection is created and things finally proceed.

    I haven't figured out how to fix this yet, but frankly, I can't believe anyone ever actually tested this code against an IMAP client. It will be triggered every time the client goes IDLE. I mean, WTF?



  • OK, here's my quick and dirty patch which "fixes" the problem:

    --- a/apps/kolab_guam/src/kolab_guam_session.erl	2017-10-17 17:13:16.991063690 +1300
    +++ b/apps/kolab_guam/src/kolab_guam_session.erl	2017-10-17 17:13:32.276480973 +1300
    @@ -267,7 +267,7 @@
             case CurrentCommandSplit of
                 undefined ->
                     case eimap_utils:split_command_into_components(ClientData) of
    -                    { _Tag, <<>>, <<>> } -> { buffer_data, undefined, reset_for_next_client_command };
    +                    { _Tag, <<>>, <<>> } -> { perform_passthrough, undefined, reset_for_next_client_command };
                         { _Tag, Command, _Data } = Split -> { perform_passthrough, Split, when_to_reset_split(Command) }
                     end;
                 _ ->  { perform_passthrough, CurrentCommandSplit, reset_for_next_client_command }
    

    This almost certainly breaks the original authors intended "buffering" logic, but this seems to solve the problem nicely.



  • @pest
    Hi!

    I am not sure whether I am currently experiencing this problem.

    In Thunderbird I point to a specific calendar with a full URL of the following format:

    https://srv.xxx.yyy/iRony/calendars/aaa.bbb@xxx.yyy/9e..c3/26..40.ics

    ".." stands for more characters and I retrieve the URLs from https://srv.xxx.yyy/iRony , where the Apache config file for iRony has an added SetEnv DAVBROWSER 1 line.

    Thunderbird shows a warning sign and doesn't synchronize anything.



  • @Shamonya
    Whoops. I inadvertently selected the wrong format in Thunderbird....


Log in to reply