Atomic icon indicating copy to clipboard operation
Atomic copied to clipboard

Atomic hangs with weechat IRC relay

Open github-cygwin opened this issue 8 years ago • 6 comments

Hi,

running weechat-1.9 on Fedora 25 and Atomic 2.1 on Android, yesterday I was trying to use weechat's IRC relay with atomic:

/relay add ipv4.irc.Freenode 9001
/set relay.network.password "pwd"

Then I configured Atomic to connect to the weechat relay. Connect succeeds, but then it just hangs:

[12:05]  Connected to wee.free
[12:05]  Now logging in...

I activated relay raw output, and it turns out that weechat gets a request from Atomic which it never replies to:

23.07 12:05 --> [1] irc.Freenode PASS pwd
23.07 12:05 --> [1] irc.Freenode CAP LS
23.07 12:05 NICK corinna
23.07 12:05 USER corinna 8 * :Corinna Vinschen
23.07 12:05 <-- [1] irc.Freenode :weechat.relay.irc CAP nick LS :server-time
23.07 12:05 --> [1] irc.Freenode CAP REQ :

From the weechat source it seems that "CAP REQ :" will result in a call to relay_irc_search_server_capability() with an empty string. This in turn will skip the CAP ACK reply code.

Question is, why does Atomic send "CAP REQ :" at all? Shouldn't it send "CAP REQ :server-time" since that's what it got back from the "CAP LS" call?

If I'm correct here, is there a chance for a quick fix? I really like Atomic and it's pretty unfortunate that it doesn't work with weechat.

Thanks, Corinna

github-cygwin avatar Jul 23 '17 10:07 github-cygwin

I just debugged this a little further and it seems that the real problem is that Atomic doesn't send a "CAP END". It seems to expect that the login continues after sending "CAP REQ :". I applied the following patch to weechat to workaround this:

diff --git a/src/plugins/relay/irc/relay-irc.c b/src/plugins/relay/irc/relay-irc.c
index 99fb0f3..f3253cf 100644
--- a/src/plugins/relay/irc/relay-irc.c
+++ b/src/plugins/relay/irc/relay-irc.c
@@ -1277,6 +1277,10 @@ relay_irc_recv_command_capab (struct t_relay_client *client,
                              (RELAY_IRC_DATA(client, nick)) ? RELAY_IRC_DATA(client, nick) : "nick",
                              str_capab);
         }
+       else if (!strcmp (argv[1], ":"))
+       {
+            RELAY_IRC_DATA(client, cap_end_received) = 1;
+       }
     }
     else if (weechat_strcasecmp (argv[0], "end") == 0)
     {

This lets Atomic continue. That's a bit puzzeling to me, but apparently it works with other servers like Freenode. Wouldn't it make more sense to send "CAP END"?!?

Thanks, Corinna

github-cygwin avatar Jul 23 '17 12:07 github-cygwin

I based the Atomic behavior off the behavior of HexChat at the time, which did not send CAP END.

On Sun, Jul 23, 2017 at 5:00 AM, Corinna Vinschen [email protected] wrote:

I just debugged this a little further and it seems that the real problem is that Atomic doesn't send a "CAP END". It seems to expect that the login continues after sending "CAP REQ :". I applied the following patch to weechat to workaround this:

diff --git a/src/plugins/relay/irc/relay-irc.c b/src/plugins/relay/irc/relay-irc.c index 99fb0f3..f3253cf 100644 --- a/src/plugins/relay/irc/relay-irc.c +++ b/src/plugins/relay/irc/relay-irc.c @@ -1277,6 +1277,10 @@ relay_irc_recv_command_capab (struct t_relay_client *client, (RELAY_IRC_DATA(client, nick)) ? RELAY_IRC_DATA(client, nick) : "nick", str_capab); }

  •   else if (!strcmp (argv[1], ":"))
    
  •   {
    
  •        RELAY_IRC_DATA(client, cap_end_received) = 1;
    
  •   }
    
    } else if (weechat_strcasecmp (argv[0], "end") == 0) {

This lets Atomic continue. That's a bit puzzeling to me, but apparently it works with other servers like Freenode. Wouldn't it make more sense to send "CAP END"?!?

Thanks, Corinna

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/indrora/Atomic/issues/134#issuecomment-317248210, or mute the thread https://github.com/notifications/unsubscribe-auth/AAcuOM_wRjybqDja_gN61YFMG51JfOVCks5sQzXagaJpZM4Oga1K .

indrora avatar Aug 01 '17 17:08 indrora

The standard implies that CAP END is required: http://ircv3.net/specs/core/capability-negotiation-3.1.html

"If a client issues a REQ subcommand, registration must be suspended until an END subcommand is received."

It seems several IRC servers (like, e.g, freenode) will still continue the registration process, but hexchat sends CAP END these days, too.

Thanks, Corinna

github-cygwin avatar Aug 01 '17 17:08 github-cygwin

Experiencing the same issue with znc. Also, no clue where I find the logs, or I'd include those... :)

manavortex avatar Oct 23 '17 08:10 manavortex

Same with me, using znc on the server.

kuba-orlik avatar May 30 '18 21:05 kuba-orlik

same here with ZNC as server.

lemmy04 avatar Oct 03 '18 11:10 lemmy04