unable to join to IRC channel when channel redirects to some other channel

Bug #434196 reported by buzzdee on 2009-09-21
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Coccinella
Medium
buzzdee

Bug Description

trying to login to IRC server irc.freenode.net to join channel #openbsd the when the chat window gets created, then an exception happens. The channel has +r which means, only registered users are allowed to login, and they have to be authenticated against the nickserver. If not, like me via coccinella, those users get redirected to channel ##please_register. The same happens when trying to use the #irc channel on the freenode network. Entering this channel redirects to channel #freenode.
This happens with Coccinella from SVN on OpenBSD.

 I get the following exception:

Hook newGroupChatMessageHook failed: 1
Does not know which protocol to use in #please_register%<email address hidden>
    while executing
"[namespace current]::service::${cmd} $jlibname {#please_register%<email address hidden>}"
    ("eval" body line 1)
    invoked from within
"eval {[namespace current]::service::${cmd} $jlibname} $args"
    (procedure "service" line 2)
    invoked from within
"$cmd $jlibname mynick #please_register%<email address hidden>"
    ("eval" body line 1)
    invoked from within
"eval {$cmd $jlibname} $args"
    (procedure "jlib::cmdproc" line 8)
    invoked from within
"jlib::cmdproc ::jlib::jlib1 service mynick #please_register%<email address hidden>"
    ("eval" body line 1)
    invoked from within
"eval jlib::cmdproc {::jlib::jlib1} $cmd $args"
    (procedure "::jlib::jlib1" line 1)
    invoked from within
"$jstate(jlib) service mynick #please_register%<email address hidden>"
    ("eval" body line 1)
    invoked from within
"eval {$jstate(jlib)} $args"
    (procedure "::Jabber::Jlib" line 3)
    invoked from within
"::Jabber::Jlib service mynick $roomjid"
    (procedure "BuildRoomWidget" line 58)
    invoked from within
"BuildRoomWidget $dlgtoken $wroom $roomjid"
    (procedure "Build" line 92)
    invoked from within
"Build $roomjid"
    (procedure "NewChat" line 7)
    invoked from within
"NewChat $roomjid"
    (procedure "::GroupChat::GotMsg" line 18)
    invoked from within
"::GroupChat::GotMsg {message {from #please_register%<email address hidden> type groupchat to <email address hidden>/Coccinella@..."
    ("eval" body line 1)
    invoked from within
"eval $func $args"
Does not know which protocol to use in #please_register%<email address hidden>
    while executing
"[namespace current]::service::${cmd} $jlibname {#please_register%<email address hidden>}"
    ("eval" body line 1)
    invoked from within
"eval {[namespace current]::service::${cmd} $jlibname} $args"
    (procedure "service" line 2)
    invoked from within
"$cmd $jlibname mynick #please_register%<email address hidden>"
    ("eval" body line 1)
    invoked from within
"eval {$cmd $jlibname} $args"
    (procedure "jlib::cmdproc" line 8)
    invoked from within
"jlib::cmdproc ::jlib::jlib1 service mynick #please_register%<email address hidden>"
    ("eval" body line 1)
    invoked from within
"eval jlib::cmdproc {::jlib::jlib1} $cmd $args"
    (procedure "::jlib::jlib1" line 1)
    invoked from within
"$jstate(jlib) service mynick #please_register%<email address hidden>"
    ("eval" body line 1)
    invoked from within
"eval {$jstate(jlib)} $args"
    (procedure "::Jabber::Jlib" line 3)
    invoked from within
"::Jabber::Jlib service mynick $roomjid"
    (procedure "BuildRoomWidget" line 58)
    invoked from within
"BuildRoomWidget $dlgtoken $wroom $roomjid"
    (procedure "Build" line 92)
    invoked from within
"Build $roomjid"
    (procedure "NewChat" line 7)
    invoked from within
"NewChat $roomjid"
    (procedure "::GroupChat::GotMsg" line 18)
    invoked from within
"::GroupChat::GotMsg {message {from #please_register%<email address hidden> type groupchat to <email address hidden>/Coccinella@..."
    ("eval" body line 1)
    invoked from within
"eval $func $args"

buzzdee (sebastia) wrote :

after some more research....

using xchat to login to the freenode network and /join #openbsd or #irc shows the following in the server tab:

* #openbsd #please_register :Forwarding to another channel
* #please_register ##please_register :Forwarding to another channel
* #irc #freenode :Forwarding to another channel
but it seems this information is not sent from the jabber server to the client.

I added a lot of debug messages in prominent places in the coccinella code, appended file contains the output while trying to login:

I think one problem is that in: jlib::service::isroom
it is not detected that it is actually a groupchat room

Not sure, but maybe in ::BuddyPounce::Event
which is called before, it should be detected that this is a room and added to the list of rooms somewhere/somehow???

Not sure whether this would be the right place to do that or not, any idea hint?

sebastian

buzzdee (sebastia) wrote :

forgot to attach output file

buzzdee (sebastia) on 2009-09-29
Changed in coccinella:
assignee: nobody → buzzdee (sebastia)
milestone: none → 0.96.16
importance: Undecided → Medium
buzzdee (sebastia) on 2009-11-28
Changed in coccinella:
milestone: 0.96.16 → 0.96.18
buzzdee (sebastia) wrote :

a workaround for the above mentioned problem:
login to another channel to the same network, register the username:
/msg nickserv register <password>

then on subsequent logins, login to another channel, and type:
/msg nickserv identify <password>

afterwards it is possible to login to a channel with +r attribute

sander (s-devrieze) wrote :

Do you think this is something that needs to be fixed in Coccinella or the transports, or do you think this needs to be documented on the website?

buzzdee (sebastia) wrote :

I took a look into the code, and I saw the error message came from
jabberlib/service.tcl in jlib::service::mynick:

I do there sth. comparable to the solution to bug #432076.
I created the function handle_unsolicited_roommessages (maybe the name can/should be renamed to sth. better?)
and call it from jlib::service::mynick.

in jlib::service::mynick coccinella checks whether it knows the room, and if not, it puts out the error message.
Instead of issueing the error message, it now discovers the correct protocol and updates the necessary variables accordingly.

The method was created in case there are more ways to run into the problem, to be able to just call it.

So now I can log in to channels with mode +r (at least tested for me on <email address hidden>)
So more testing is probably a good idea, so feedback welcome ;)

The following steps needs to be done to enter an IRC channel with mode +r and shold be documented on the website:
1. try login to the intended channel as just any other channel
2. when ending up in the alternate channel, issue the command /msg nickserv identify <myPassword>
3. go back to step 1
This procedure requires that the nick used is already registered in this IRC network.
In case it is not yet registered, then in step 2 issue the command /msg nickserv register <myPassword>

The fix is committed with svn revision: 2777

Changed in coccinella:
status: New → Fix Committed
summary: - unable to loin to IRC channel when channel redirects to some other
+ unable to join to IRC channel when channel redirects to some other
channel
sander (s-devrieze) wrote :

 Can you review this page?: http://coccinella.im/faq/irc-registered-users

Also, do you know a very well-known IRC channel with mode +r that can be used as an example in that FAQ page?

buzzdee (sebastia) wrote :

take a look at the initial report, channels #irc and #openbsd on irc.freenode.net have mode +r

buzzdee (sebastia) on 2010-04-04
Changed in coccinella:
status: Fix Committed → Fix Released
v_2e (v-2e) wrote :

  By the way, why does Coccinella aks for password (optional though) before connecting to some IRC channel, if it doesn't send an "identify" command to the NickServ automatically?

buzzdee (sebastia) wrote :

do you have an example IRC server/channel where that is the case?

Or do you mean the general "Enter chatroom" window? The enter chatroom window is general purpose, also for XMPP MUC rooms, which can be protected by a password, which is sth. different than a password for a nick.

v_2e (v-2e) wrote :

  Yes, it seems that I'm talking about the general "Enter chatroom" window.
  Here is what I'm doing:
- I go to menu "Action" -> "Enter chatroom..."
- In the "Enter chatroom" window I choose the following:
   Service: irc.jabber.od.ua
   Chatroom: xfce%irc.freenode.net
   Nickname: My nickname
   Password: My password on Freenode.Net
- Then I press "Enter" button.
  After all this Coccinella enters the requested IRC channel, but does not send "identify" command with the password I entered to the NickServ and I have to do it by hand.
  The very same situation is when I type nothing for password in "Enter chatroom" window.
  Shouldn't Coccinella use the entered password to "identify" me in the IRC channel since there is a field to enter the password?

  P.S. Sorry if this is a wrong place to discuss this question. :)

buzzdee (sebastia) wrote :

Ah, OK.
I just checked with the XML Console and coccinella is sending the password to the server. So to blame the transport on the server. However, with XMPP MUCs the password is used to allow entering the channel, on IRC its usually used to identify the nick, and IIRC on IRC you can also have password protected channels. So I'd guess if the server side transport supports passwords for channels, it would take the password to enter the channel rather than to identify the nick.
I haven't tried to enter a password protected channel yet, but I think there is no way to tell the transport that the password should be used to identify the nick instead of using it for entering the password.

v_2e (v-2e) wrote :

  Well, maybe this password is really used by the IRC transport for entering the server.
  But even if the transport doesn't support "identification" in IRC channel, Coccinella always can send a "identify <password>" message to the NickServ if the user enters the password. Or do you think it would be a bad practice?

>  Well, maybe this password is really used by the IRC transport for entering the server.
>  But even if the transport doesn't support "identification" in IRC channel, Coccinella always can send a "identify <password>" message to the NickServ if the user enters the password. Or do you think it would be a bad practice?

I think this would be a bad practice: the transport is there to do the
translation between MUC <-> IRC. I guess this bug/wish should be
reported to the different IRC transport projects. Can you do this?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers