View Issue Details

IDProjectCategoryView StatusLast Update
0004166unrealircdpublic2013-02-19 19:36
ReporterMagiobiwan Assigned Tosyzop  
Status resolvedResolutionfixed 
PlatformLinuxOSCentOS x64OS Version6.3
Product Version3.2.10 
Fixed in Version3.2.10.1 
Summary0004166: Anope Services link protocol issue
DescriptionAnope 1.8.7 and Unreal 3.2.10 don't link together properly. There appear to be some issues in the setting of usermodes for Anope BotServ bots. When I had Anope 1.8.7 linked to my server which was running 3.2.9, the BotServ bots recieved usermodes +Sq as they are supposed to. However, with Unreal 3.2.10, they do not. Anope Debug logs show the modes being sent on startup, however they do not appear in a /whois of the bot. I was diagnosing this issue with Jobe, who should be able to provide more details if needed.
Steps To ReproduceSet up Unreal 3.2.10 and Anope 1.8.7, and link them together. Create a BotServ bot and do a /whois on it, and note the lack of usermodes +Sq on it, which it should have.
Additional InformationI was told by Jobe to submit this as a bug here, on the Unreal IRCd bug tracker.
TagsNo tags attached.
3rd party modulesm_banlink, textban, m_privdeaf, rmtkl



2013-01-30 03:40

reporter   ~0017397

I believe this may have happened with the new remove_oper_modes() (changeset 5200:d9d5cc06d06d) and requiring +o to use modes S and q. It seems somewhere along the way the server is treating remote users as local users and removing modes erroneously. This is resulting in a desync by Unreal updating the user's modes on the local server while remote servers (and services) still see the modes that were originally set.

It seems to me we should be checking if the target is MyClient() and !IsULine(), the only question is where are we missing this vital check?


2013-01-30 06:27

reporter   ~0017402

I can confirm that it's related to the Bots not having usermode +o. I modified the Unreal 3.2 protocol for Anope to set +o for the Bots and they now recieve the modes correctly.


2013-01-30 09:59

reporter   ~0017403

Last edited: 2013-01-30 10:02

View 2 revisions

I don't see why we don't treat all clients on set::services-server as +Sq to be honest or at least imply they are.

If said protection was implied, we wouldn't need the usermode +S.


2013-01-30 14:15

reporter   ~0017405

Last edited: 2013-01-30 15:37

View 2 revisions

set::services-server is to define which server is for services for alias blocks and numeric responses. It serves no other purpose.

The reason we don't assume set::services-server is +Sq is so netadmins don't set a client server in set::services-server so they can have an operfunserver.

U:Lines work a little differently by letting the server set such special modes without the need to set +o on all the pseudo users, and U:lining a client server doesn't work because the clients don't have the ability to set such modes without modules/hacks/+o.

EDIT: Though it seems this bug is no longer about U:Lines, but rather about servers improperly handling modes.


2013-02-16 19:48

reporter   ~0017420

Is there any chance of getting this fixed soon? Should be as simple as:

diff -r 7cf8a40bddfb src/modules/m_mode.c
--- a/src/modules/m_mode.c Wed Feb 13 22:33:12 2013 +0100
+++ b/src/modules/m_mode.c Sat Feb 16 13:47:13 2013 -0500
@@ -2484,7 +2484,7 @@
        if ((setflags & UMODE_INVISIBLE) && !IsInvisible(sptr))

- if (!IsAnOper(sptr))
+ if (MyConnect(sptr) && !IsAnOper(sptr))




2013-02-16 20:26

reporter   ~0017421

This will likely be fixed in 3.2.11. Until then, use the latest version of Anope (Anope implemented a workaround in their SVN a few weeks ago).

This is NOT a major enough bug to warrant an immediate release.


2013-02-17 00:22


m_mode.patch (364 bytes)


2013-02-19 19:36

administrator   ~0017423

Fixed in default branch (5233:67300f8612ed) and unreal34 (5234:e5a0bac3f51c).

- Don't remove oper-modes such as +S from non-local clients. Reported by
  Magiobiwan (0004166). This caused an issue with bots from anope BotServ
  where user modes +Sq were stripped by the IRCd.

And I agree with Stealth.

Issue History

Date Modified Username Field Change
2013-01-29 04:14 Magiobiwan New Issue
2013-01-30 03:40 Stealth Note Added: 0017397
2013-01-30 03:40 Stealth Status new => acknowledged
2013-01-30 06:27 Magiobiwan Note Added: 0017402
2013-01-30 09:59 katsklaw Note Added: 0017403
2013-01-30 10:02 katsklaw Note Edited: 0017403 View Revisions
2013-01-30 14:15 Stealth Note Added: 0017405
2013-01-30 15:37 Stealth Note Edited: 0017405 View Revisions
2013-02-12 07:01 dummy Status acknowledged => has patch
2013-02-16 19:48 Adam- Note Added: 0017420
2013-02-16 20:26 Stealth Note Added: 0017421
2013-02-17 00:22 Stealth File Added: m_mode.patch
2013-02-19 19:36 syzop Note Added: 0017423
2013-02-19 19:36 syzop Status has patch => resolved
2013-02-19 19:36 syzop Fixed in Version =>
2013-02-19 19:36 syzop Resolution open => fixed
2013-02-19 19:36 syzop Assigned To => syzop