Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#2 rudel-join-error

closed-fixed
Jan Moringen
None
5
2009-09-26
2009-09-23
Micah Anderson
No

I am using the code from SVN (r229), and was able to load everything fine, after I got the latest CEDET installed. When I try and join a running gobby session, it fails to join with the error: rudel-join-error. The following is in my *Messages* buffer:

Discovering Sessions ... [2 times]
Using backend `obby'
Making completion list...
Use encryption? (y or n)
Received Obby welcome message (version 8)
tls-wait-init: switching back to old filter
tls-start-tls: switching to tls handshake filter
tls-wait-handshake: switching to established filter
Use encryption? (y or n) y
byte-code: Could not join session: rudel-join-error
Quit [2 times]
call-interactively: End of buffer
Mark set
Desktop saved in ~/.emacs.d/desktop/
Mark set
Quit

I'd be happy to provide any other information that would be useful for debugging this!

Thanks!

Discussion

1 2 > >> (Page 1 of 2)
  • Jan Moringen
    Jan Moringen
    2009-09-23

    Looks like an unspecified error produced by rudel-obby/net6_login_failed in obby/rudel-obby-client.el. Can you try to obtain the value of `reason' in that function when the error occurs?

    One possibility to do this would be tracing the function using M-x trace-function rudel-obby/net6_login_failed RET and looking at the contents of the trace buffer after trying to connect.

    Could you also describe your setup. It would helpful to know which combination of Rudel/Gobby clients/servers you used and maybe whether the processes ran on the same machine or not.

     
  • Jan Moringen
    Jan Moringen
    2009-09-23

    • assigned_to: nobody --> scymtym
     
  • Jan Moringen
    Jan Moringen
    2009-09-23

    Oh, I forgot to thank you for the bug report. Please consider your bug report appreciated ;)

     
  • Jan Moringen
    Jan Moringen
    2009-09-23

    I just noticed this in your messages buffer:

    Use encryption? (y or n)
    Received Obby welcome message (version 8)
    tls-wait-init: switching back to old filter
    tls-start-tls: switching to tls handshake filter
    tls-wait-handshake: switching to established filter
    Use encryption? (y or n) y

    Does it connect before you answer the encryption question?

     
  • Micah Anderson
    Micah Anderson
    2009-09-23

    Hi,

    > Looks like an unspecified error produced by rudel-obby/net6_login_failed in
    > obby/rudel-obby-client.el. Can you try to obtain the value of `reason' in
    > that function when the error occurs?

    Sure!

    > One possibility to do this would be tracing the function using M-x
    > trace-function rudel-obby/net6_login_failed RET and looking at the contents
    > of the trace buffer after trying to connect.

    Ok, this is what I get when I use M-x trace-function:

    Date: 2009-09-23 12:33
    Sender: scymtymProject Admin

    Looks like an unspecified error produced by rudel-obby/net6_login_failed in
    obby/rudel-obby-client.el. Can you try to obtain the value of `reason' in
    that function when the error occurs?

    One possibility to do this would be tracing the function using M-x
    trace-function rudel-obby/net6_login_failed RET and looking at the contents
    of the trace buffer after trying to connect.

    Could you also describe your setup. It would helpful to know which
    combination of Rudel/Gobby clients/servers you used and maybe whether the
    processes ran on the same machine or not.

    ======================================================================
    1 -> rudel-obby/net6_login_failed: local-args=(#1=[object rudel-obby-client-state-joining "joining" #2=[object rudel-obby-connection #3="gobby.myserver.net" #<process *tls-gobby.myserver.net*<5>> nil #4=[object rudel-client-session #5="asked" #6=[object rudel-obby-backend "obby" (0 2) (join host change-color track-subscriptions)] nil nil nil nil nil nil unbound unbound] ((new . [object rudel-obby-client-state-new "new" #2#]) (encryption-negotiate . [object rudel-obby-client-state-encryption-negotiate "encryption-negotiate" #2#]) (encryption-start . [object rudel-obby-client-state-encryption-start "encryption-start" #2#]) (joining . #1#) (join-failed . [object rudel-obby-client-state-join-failed "join-failed" #2# unbound unbound]) (idle . [object rudel-obby-client-state-idle "idle" #2#]) (session-synching . [object rudel-obby-client-state-session-synching "session-synching" #2# unbound unbound unbound]) (subscribing . [object rudel-obby-client-state-subscribing "subscribing" #2# unbound]) (document-synching . [object rudel-obby-client-state-document-synching "document-synching" #2# unbound unbound unbound])) #1# (:host #3# :port 6522 :username #7="micah" :color #8="#0000FFFFFFFF" :encryption t :name #5# :backend (obby . #6#) :host #3# :port 6522 :username #7# :color #8# :encryption t :session #4#) #<hash-table 'equal nil 0/65 0xb39dbe8>]] "101")
    1 <- rudel-obby/net6_login_failed: (join-failed (rudel-join-error))

    > Could you also describe your setup. It would helpful to know which
    > combination of Rudel/Gobby clients/servers you used and maybe whether the
    > processes ran on the same machine or not.

    Sure, I am connecting to a remote sobby server, on a Debian Etch machine, package version: 0.4.1-1+b2, its on another machine entirely. Its a sobby server that I typically connect via gobby regularly with other folks.

    I tried setting up a local sobby server with a newer version of sobby to see if that was related. I installed sobby 0.4.5-1+b1 locally and then ran a local sobby instance by starting it up thus: sobby --name=micah --password=hi

    When I then tried to connect to that instance, I get the same problem.

    > I just noticed this in your messages buffer:
    >
    > Use encryption? (y or n)
    > Received Obby welcome message (version 8)
    > tls-wait-init: switching back to old filter
    > tls-start-tls: switching to tls handshake filter
    > tls-wait-handshake: switching to established filter
    > Use encryption? (y or n) y
    >
    > Does it connect before you answer the encryption question?

    I'm not sure I totally am sure I understand what you mean by 'does it connect before', it *does* ask me the question, "Use encryption? (y or n)" and I respond with 'y' (i've also tried 'n', but that doesn't work).

    > Oh, I forgot to thank you for the bug report. Please consider your bug
    > report appreciated ;)

    Hey, thanks for writing this, I've been wanting this for a long time, and I really appreciate the quick responses!

     
  • Jan Moringen
    Jan Moringen
    2009-09-23

    • status: open --> open-accepted
     
  • Jan Moringen
    Jan Moringen
    2009-09-23

    Thanks for the feedback. I just happened to stumble upon the interesting lines in the obby code. What I saw there perfectly matches your trace output: I did not implement the user password (or session password for that matter) features of the obby protocol. The "unspecified" error is the server complaining about a password mismatch, which is understandable considering the fact that there is no code for transmitting passwords in the Rudel client.

    This should be easy to fix. I will post another comment when I'm done.

     
  • Jan Moringen
    Jan Moringen
    2009-09-23

    I committed a change that asks for global and user passwords when joining an obby session. Could you try whether this solves the issue for you.

     
  • Hey! That seems to work!

    I'm a little puzzled what the two different passwords are for (Global and User?) I'm only used to seeing one when connecting to a obby with gobby.

    Now I have to find a color scheme that works with my black background and white text.

     
  • Jan Moringen
    Jan Moringen
    2009-09-24

    The global and user password are my interpretation of the Gobby source. I think it works like this:
    The global password is controlled by the person who hosts the session to restrict access to the session.
    The user password prevents persons with access to session from taking over other users' accounts when they temporarily disconnect from the session.

    Concerning the color scheme, there is a nice solution in the 0.5 series of Gobby: if I remember correctly, they only transmit hue values of all colors and let clients choose saturation and value as they like.

    The bug seems fixed to me. Do you agree?

     
1 2 > >> (Page 1 of 2)