indrora / Atomic

Atomic: an IRC client from the ashes of yaaic
https://indrora.github.io/Atomic/
GNU General Public License v3.0
123 stars 29 forks source link

Atomic hangs with weechat IRC relay #134

Open github-cygwin opened 6 years ago

github-cygwin commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 notifications@github.com 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 .

github-cygwin commented 6 years ago

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 commented 6 years ago

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

kuba-orlik commented 6 years ago

Same with me, using znc on the server.

lemmy04 commented 5 years ago

same here with ZNC as server.