View Issue Details

IDProjectCategoryView StatusLast Update
0005988unrealircdpublic2021-11-10 15:42
Reporterfo Assigned Tosyzop  
PrioritylowSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version21.04
Product Version6.0.0-beta1 
Fixed in Version6.0.0-beta3 
Summary0005988: link.SERVER_LINKED_REMOTE repeats itself a lot
DescriptionSee https://0bin.net/paste/VZ+h7WXJ#48OVD29PcHaDGEEa7yI-zBpa7Xj9QhrouEf2wVzrtIS for an example.

As an additional point, it seems that server's uplink info gets sent in , as opposed to linked server, which is probably related.
 cf. https://0bin.net/paste/6oiu3-61#7UdRHitCDSRGsgKm3pRA8fQlX4Vs2lLYeuXLpfAsyKB
TagsNo tags attached.
3rd party modules

Activities

fo

2021-11-02 01:46

reporter   ~0022155

another example:
https://0bin.net/paste/dPAyKQvi#hm1CCDXKvcOOCiTXkMDp1WZEERSDUiXrABdGrd8CecM

P.S. I strongly suggest moving link.SERVER_LINKED_REMOTE from remote servers to a separate snomask or outright ignoring it, cause it's kinda spammy, as you can see above.

fo

2021-11-02 02:13

reporter   ~0022156

After some additional testing, it seems indeed that link.SERVER_LINKED_REMOTE is indeed showing values of connected server's uplink instead of actual connected servers.
Test setup:
relevant topo:
irc.freenode.ceo (20) 9EE
|-sixually.piss.in.my.pasteurizedbathwater.com (1) 716
| `-services.piss.town (2) 0A0

operator on sixually.piss.in.my.pasteurizedbathwater.com squits services.piss.town and then reconnects them. sixually.piss.in.my.pasteurizedbathwater.com stays connected to the network.

received snotes:
[04:04:15] * sixually.piss.in.my.pasteurizedbathwater.com: link.SQUIT [info] SQUIT: Forced server disconnect of services.piss.town by alice2 ()
[04:04:15] * sixually.piss.in.my.pasteurizedbathwater.com: link.LINK_DISCONNECTED [error] Lost server link to services.piss.town [2001:470:1872:9155:0:0:0:6667]:
[04:06:29] * sixually.piss.in.my.pasteurizedbathwater.com: link.SERVER_LINKED [info] Server linked: sixually.piss.in.my.pasteurizedbathwater.com -> services.piss.town [secure: TLSv1.2-ECDHE-ECDSA-AES256-GCM-SHA384]
[04:06:29] * irc.freenode.ceo: link.SERVER_LINKED_REMOTE [info] Server linked: sixually.piss.in.my.pasteurizedbathwater.com (via irc.freenode.ceo)
[04:06:29] * sixually.piss.in.my.pasteurizedbathwater.com: link.SERVER_SYNCED [info] Link services.piss.town -> sixually.piss.in.my.pasteurizedbathwater.com is now synced [secs: 2, recv: 698, sent: 319085

syzop

2021-11-05 15:01

administrator   ~0022167

Take a network (we are A): A--B--C--D

The "via xyz" indeed means the uplink for us, from our point of view. So it would be "D (via B)"
And from what I can read you expect it to be the uplink from the other server point of view, so: "D (via C)"
Of course, technically, both are right.

Anyway, interesting. I can understand that POV. I will ponder a bit about this in the upcoming weeks :D

fo

2021-11-05 21:10

reporter   ~0022169

I really am bad at explaining, it seems.

Relevevant part of topo before testing:

[22:39:18] * conga.aat.the.shitposting.space: conga.aat.the.shitposting.space (2) 7FA
[22:39:18] * conga.aat.the.shitposting.space: |-irc.freenode.ceo (18) 9EE
[22:39:18] * conga.aat.the.shitposting.space: | |-sixually.piss.in.my.pasteurizedbathwater.com (0) 716

Operator on sixually.piss.in.my.pasteurizedbathwater.com connects services.piss.town from under sixually.piss.in.my.pasteurizedbathwater.com, so topo is now:

* conga.aat.the.shitposting.space: conga.aat.the.shitposting.space (2) 7FA
* conga.aat.the.shitposting.space: |-irc.freenode.ceo (18) 9EE
* conga.aat.the.shitposting.space: | |-sixually.piss.in.my.pasteurizedbathwater.com (0) 716
* conga.aat.the.shitposting.space: | `-services.piss.town (2) 0A0

Snotes received during connection:

[22:46:00] * sixually.piss.in.my.pasteurizedbathwater.com: link.SERVER_LINKED [info] Server linked: sixually.piss.in.my.pasteurizedbathwater.com -> services.piss.town [secure: TLSv1.2-ECDHE-ECDSA-AES256-GCM-SHA384]
[22:46:00] * conga.aat.the.shitposting.space: link.SERVER_LINKED_REMOTE [info] Server linked: sixually.piss.in.my.pasteurizedbathwater.com (via irc.freenode.ceo)
[22:46:02] * sixually.piss.in.my.pasteurizedbathwater.com: link.SERVER_SYNCED [info] Link services.piss.town -> sixually.piss.in.my.pasteurizedbathwater.com is now synced [secs: 0, recv: 722, sent: 327746]
[22:46:22] * services.piss.town: Link sixually.piss.in.my.pasteurizedbathwater.com -> services.piss.town is now synced [secs: 22]

Note that link.SERVER_LINKED_REMOTE from conga.aat.the.shitposting.space shows that sixually.piss.in.my.pasteurizedbathwater.com was connected during testing and not services.piss.town. sixually.piss.in.my.pasteurizedbathwater.com stayed connected and was never disconnected during the testing.

So, following your previous example, when I am connecting D, I am receiving link.SERVER_LINKED_REMOTE snote about the connection of "C (via B)", and that's my issue.

P.S. re: uplink I'd prefer another server PoV in via, but that's not the issue here.

syzop

2021-11-10 15:12

administrator   ~0022180

Ah ok, I see it now, thanks for the clarification.

syzop

2021-11-10 15:42

administrator   ~0022181

I think this fixes it, thanks for the report! :D

commit 36a06b0011a951b4bad4ef7ca3949c061f0acbc1 (HEAD -> unreal60_dev, origin/unreal60_dev)
Author: Bram Matthys <syzop@vulnscan.org>
Date: Wed Nov 10 15:38:59 2021 +0100

    A few changes to server linking notices:
    1) Don't forward link.SERVER_LINKED since we already generate
       link.SERVER_LINKED_REMOTE ourselves.
    2) Fix using wrong server name(s) in link.SERVER_LINKED_REMOTE
       reported by flo in https://bugs.unrealircd.org/view.php?id=5988
    3) Don't show link.SERVER_LINKED_REMOTE messages when we
       are syncing to a network, otherwise you would get eg 50 of
       such messages for 50 servers when you link in 1 server.

Issue History

Date Modified Username Field Change
2021-11-01 17:55 fo New Issue
2021-11-02 01:46 fo Note Added: 0022155
2021-11-02 02:13 fo Note Added: 0022156
2021-11-05 15:01 syzop Note Added: 0022167
2021-11-05 21:10 fo Note Added: 0022169
2021-11-10 15:12 syzop Note Added: 0022180
2021-11-10 15:42 syzop Assigned To => syzop
2021-11-10 15:42 syzop Status new => resolved
2021-11-10 15:42 syzop Resolution open => fixed
2021-11-10 15:42 syzop Fixed in Version => 6.0.0-beta3
2021-11-10 15:42 syzop Note Added: 0022181