View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006498 | unreal | ircd | public | 2025-02-17 12:21 | 2025-02-17 12:23 |
| Reporter | Jellis | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | Linux | OS | Debian | OS Version | 12 |
| Product Version | 6.1.9.1 | ||||
| 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 | |||||
