View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004009unrealircdpublic2011-03-05 01:282015-08-08 09:16
Reporterkatsklaw Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionno change required 
Product Version3.2.8 
Fixed in Version3.4-beta1 
Summary0004009: Linking server returns wrong name when link denied
Description-rampage.ircmadness.net- *** Connecting to madness.ircmadness.net[72.20.21.111].
-
-rampage.ircmadness.net- *** LocOps -- Link denied for rampage.ircmadness.net([email protected]) (No link block named 'rampage.ircmadness.net') [@72.20.21.111.52052]
-
-rampage.ircmadness.net- *** LocOps -- ERROR :from madness.ircmadness.net[72.20.21.111] -- Link denied (No matching link configuration) [@72.20.21.111.52052]
-
-rampage.ircmadness.net- *** LocOps -- ERROR :from madness.ircmadness.net[72.20.21.111] -- Closing Link: [72.20.21.111] (Link denied (No matching link configuration))
-
-rampage.ircmadness.net- *** LocOps -- Server madness.ircmadness.net[72.20.21.111] closed the connection
Steps To Reproduceconnect to server1, have server1's IP in the link block for server2.
on server1 type: /connect server2

Notice the first message says it's connecting to server2 at server1's IP
Next notice that server1 is listed in the error message correctly.
Now look at all the remaining messages and notice that server2's name with server1's IP is displayed.

TagsNo tags attached.
Attached Files
unrealircd.conf (20,816 bytes)
3rd party modules

Activities

syzop

2011-03-08 21:19

administrator   ~0016616

You should read it like this:

This is from the 'outgoing connection' point of view:
rampage.ircmadness.net- *** Connecting to madness.ircmadness.net[72.20.21.111].
rampage.ircmadness.net- *** LocOps -- ERROR :from madness.ircmadness.net[72.20.21.111] -- Link denied (No matching link configuration) [@72.20.21.111.52052]
rampage.ircmadness.net- *** LocOps -- ERROR :from madness.ircmadness.net[72.20.21.111] -- Closing Link: [72.20.21.111] (Link denied (No matching link configuration))
rampage.ircmadness.net- *** LocOps -- Server madness.ircmadness.net[72.20.21.111] closed the connection

And this from the ircd seeing an incoming connection point of view:
rampage.ircmadness.net- *** LocOps -- Link denied for rampage.ircmadness.net([email protected]) (No link block named 'rampage.ircmadness.net') [@72.20.21.111.52052]

katsklaw

2011-03-08 23:57

reporter   ~0016617

still seems kinda convoluted, why do we need 3 redundant LocOps btw?

1> ok I'll try to connect
2> connection failed cuz reason1
3> connection failed cuz reason1, cancelling
4> ok I'll finally cancel now for real.

why can't we have something like:

1> trying to connect
2> cant connect because reason1, cancelling.

mahdkoosh

2011-03-27 23:56

reporter   ~0016630

Last edited: 2011-03-28 10:32

 link sarnevesht.zapto.org
{
   username *;
   hostname 208.51.78.252;
   bind-ip 208.51.78.252;
   port 6667;
   hub *;
   password-connect "*";
   password-receive "*";
   class servers;
      options {
         autoconnect;
      };
};

link sarnevesht.zapto.org

{

    username *;

    hostname 208.51.78.252;

    bind-ip 208.51.78.252;

    port 6667;

    hub *;

    password-connect "*";

    password-receive "*";

    class servers;

        options {

            /* Note: You should not use autoconnect when linking services */
            autoconnect;

        };
};

syzop

2012-01-22 17:29

administrator   ~0016894

Last edited: 2012-01-22 17:31

 katsklaw:
the 2> and 3> could be combined I think, the others cannot.
basically you receive message 2 & 3 because any ERROR message is sent to ircops, and both are 'ERROR :xyz' messages.
in src/modules/m_server.c there's many times an explicit sendto... ERROR:.. and then exit_client.. which does the same. usually the 1st ERROR message is more descriptive than the 2nd because it allows format strings.
Example:
                sendto_one(cptr, "ERROR :Invalid numeric (%s)",
                        servername);
                return exit_client(cptr, cptr, &me, "Invalid remote numeric");

What we *could* do is get rid of the (1st) explicit 'ERROR', and keep the (2nd) one in exit_client, but then the 2nd one should be as detailed as the 1st one originally was... one can fill a buffer, or - better: - we could make it cleaner and make an exit_client_fmt() [name is just a suggestion] which accepts a format string & arguments.

Another point you made is that the 'ERROR :from madness.ircmadness.net' can be confusing. The name comes from the link { } block (of the outgoing connect), but the user will probably believe that this is indeed 'madness.ircmadness.net', which is not true: it never connected to a server named like that (it connected to itself).
Not sure how to make that more clear... as right now there's no way to know the actual remote server name. Maybe some rewording, not sure, could make the message too long (and 'too correct').

This item is not very high on my priority list, I must confess.

EDIT: added an example

syzop

2015-08-08 09:15

administrator   ~0018581

I think this can be closed.
Also a number of error messages have been improved when linking.

Issue History

Date Modified Username Field Change
2011-03-05 01:28 katsklaw New Issue
2011-03-08 21:19 syzop Note Added: 0016616
2011-03-08 23:57 katsklaw Note Added: 0016617
2011-03-27 23:40 mahdkoosh File Added: unrealircd.conf
2011-03-27 23:56 mahdkoosh Note Added: 0016630
2011-03-27 23:56 mahdkoosh Status new => has patch
2011-03-27 23:57 mahdkoosh Note Edited: 0016630
2011-03-28 00:00 mahdkoosh Tag Attached: Auditorium
2011-03-28 00:00 mahdkoosh Tag Attached: IDLE
2011-03-28 00:00 mahdkoosh Tag Attached: My
2011-03-28 00:00 mahdkoosh Tag Attached: OPER
2011-03-28 00:00 mahdkoosh Tag Attached: UMODE
2011-03-28 00:00 mahdkoosh Tag Attached: WHOIS
2011-03-28 00:01 mahdkoosh Tag Detached: Auditorium
2011-03-28 00:01 mahdkoosh Tag Detached: IDLE
2011-03-28 00:01 mahdkoosh Tag Detached: My
2011-03-28 00:01 mahdkoosh Tag Detached: OPER
2011-03-28 00:01 mahdkoosh Tag Detached: UMODE
2011-03-28 00:01 mahdkoosh Tag Detached: WHOIS
2011-03-28 00:26 mahdkoosh Note Edited: 0016630
2011-03-28 10:29 mahdkoosh Note Edited: 0016630
2011-03-28 10:30 mahdkoosh Note View State: 0016630: private
2011-03-28 10:31 mahdkoosh Note Edited: 0016630
2011-03-28 10:32 mahdkoosh Note Edited: 0016630
2011-03-28 10:33 mahdkoosh Note View State: 0016630: public
2011-12-25 16:46 syzop Status has patch => new
2012-01-22 17:29 syzop Note Added: 0016894
2012-01-22 17:30 syzop Status new => acknowledged
2012-01-22 17:31 syzop Note Edited: 0016894
2015-08-08 09:15 syzop Note Added: 0018581
2015-08-08 09:15 syzop Status acknowledged => resolved
2015-08-08 09:15 syzop Fixed in Version => 3.4-beta1
2015-08-08 09:15 syzop Resolution open => no change required
2015-08-08 09:15 syzop Assigned To => syzop