Atomic hangs with weechat IRC relay

[github-cygwin]

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]

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

[indrora]

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 ***@***.***> 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 <#134 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcuOM_wRjybqDja_gN61YFMG51JfOVCks5sQzXagaJpZM4Oga1K> .

[github-cygwin]

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

[manavortex]

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

[kuba-orlik]

Same with me, using znc on the server.

[lemmy04]

same here with ZNC as server.