View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006498 | unreal | ircd | public | 2025-02-17 12:21 | 2025-07-13 10:56 |
| Reporter | Jellis | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Debian | OS Version | 12 |
| Product Version | 6.1.9.1 | ||||
| Fixed in Version | 6.2.0-beta1 | ||||
| Summary | 0006498: JUPE in Anope Causes UnrealIRCd to Drop and Reconnect server | ||||
| Description | When using the JUPE command in Anope on the latest versions of UnrealIRCd, the expected behavior (preventing a specific server from reconnecting) is not maintained. Instead, the following issue occurs: 1. The juped server is disconnected from the network. 2. Services introduce a new pseudo-server for the juped name. 3. Due to autoconnect being enabled on the leaf server, the original server reconnects and replaces the juped pseudo-server. 4. This cycle effectively makes JUPE ineffective in preventing the server from reconnecting. This issue will possibly cause UnrealIRCd to blame Anope and Anope to blame UnrealIRCd yet I make this post here (as suggested by PeGaSus, alice and syzop on the unreal-support channel) to have it reported and have all devs look at the issue. | ||||
| Steps To Reproduce | 1. Have a hub (e.g., irc1) with services (Anope) linked to it. 2. Have two leaf servers (irc2, irc3) connected to the hub with autoconnect enabled. 3. Use JUPE in Anope on irc2. Observe that: - irc2 disconnects. - Services introduce a pseudo-server. - irc2 reconnects due to autoconnect, replacing the pseudo-server introduced by services. Relevant logs/Error Messages: [error] Link with server irc2.example.net causes older link with same server via services.example.net to be dropped. | ||||
| Additional Information | Expected Behavior: The juped server (irc2) should remain disconnected, and the pseudo-server introduced by services should persist. UnrealIRCd should not allow autoconnect to override an active JUPE. Workaround: Disabling autoconnect on the leaf servers and enabling it on the hub instead prevents the issue, as the hub sees the juped pseudo-server and does not attempt to reconnect the original server. However, this is not an ideal solution as it reverses the intended connection flow (hubs should not initiate connections). Also it's not always the case services will be connected to a hub so it's still a bug in any case. We've discussed this issue on #unreal-support in quite length (special thanks to PeGaSuS and alice for their input) The issue seems to be a combination of Anope not properly marking the JUPE and UnrealIRCd replacing an existing U-lined server with a reconnecting one. Anope developers may suggest this is an UnrealIRCd issue, and vice versa, so both projects might need to coordinate to fully resolve the problem. This behavior was not observed in earlier versions of UnrealIRCd and Anope (to my knowlegde, using /OS JUPE for years but offcourse - not that often). Jupe is a powerfull administrative feature I like to have a bad behaving server, or whatever issue, quickly be disabled on the network without going into configs. I realise JUPE by itselff is Anope but the connection/link part is on both UnrealIRCd and Anope :) The issue was replicated by PeGaSuS and the workaround (not letting leaf autoconnect) was also replicated by PeGaSuS confirming this report. Proposed Fix: UnrealIRCd should recognize the pseudo-server introduced by services and prevent an autoconnected server from replacing it. Possibly enforce a restriction that prevents a non-U-lined server from replacing an existing link from U-lined server, or work with SID's of the server or something, dev's know alot more about this than I :) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Thanks for submitting the bug! Yes I think we should (and can) deal with this on our side. We can detect it is behind a ULine() - and thus know it is juped - and then block a new server connection :) |
|
|
Thanks, this is now fixed in 6.2.0. Note that 6.2.0 is currently not stable. Commit: https://github.com/unrealircd/unrealircd/commit/93720a9533d2e3274a2c1239441e823ea8ee4d5a commit 93720a9533d2e3274a2c1239441e823ea8ee4d5a (HEAD -> unreal60_dev) Author: Bram Matthys <[email protected]> Date: Sun Jul 13 10:53:46 2025 +0200 Fix OS JUPE still allowing server in. Since UnrealIRCd 6.0.0 when a server connects, we like to drop the existing link so they don't need to wait on "Ping timeout". However, that goes against the JUPE stuff that Services tend to use, it basically negates it. We now check if the uplink is u-lined (like for services) and if that is the case we deny the link with "Server Exists (Juped)". So just like before U6, and with a slightly more helpful message even. Reported by Jellis in https://bugs.unrealircd.org/view.php?id=6498 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-02-17 12:21 | Jellis | New Issue | |
| 2025-02-17 12:23 | syzop | Assigned To | => syzop |
| 2025-02-17 12:23 | syzop | Status | new => acknowledged |
| 2025-02-17 12:23 | syzop | Note Added: 0023433 | |
| 2025-07-13 10:56 | syzop | Status | acknowledged => resolved |
| 2025-07-13 10:56 | syzop | Resolution | open => fixed |
| 2025-07-13 10:56 | syzop | Fixed in Version | => 6.2.0-beta1 |
| 2025-07-13 10:56 | syzop | Note Added: 0023456 |
