View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005988 | unreal | ircd | public | 2021-11-01 17:55 | 2021-11-10 15:42 |
| Reporter | fo | Assigned To | syzop | ||
| Priority | low | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Ubuntu | OS Version | 21.04 |
| Product Version | 6.0.0-beta1 | ||||
| Fixed in Version | 6.0.0-beta3 | ||||
| Summary | 0005988: link.SERVER_LINKED_REMOTE repeats itself a lot | ||||
| Description | See 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 | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
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. |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
Ah ok, I see it now, thanks for the clarification. |
|
|
I think this fixes it, thanks for the report! :D commit 36a06b0011a951b4bad4ef7ca3949c061f0acbc1 (HEAD -> unreal60_dev, origin/unreal60_dev) Author: Bram Matthys <[email protected]> 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. |
| 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 |
