View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004166||unreal||ircd||public||2013-01-29 04:14||2013-02-19 19:36|
|Platform||Linux||OS||CentOS x64||OS Version||6.3|
|Fixed in Version||188.8.131.52|
|Summary||0004166: Anope Services link protocol issue|
|Description||Anope 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 Reproduce||Set 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 Information||I was told by Jobe to submit this as a bug here, on the Unreal IRCd bug tracker.|
|Tags||No tags attached.|
|3rd party modules||m_banlink, textban, m_privdeaf, rmtkl|
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?
||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.|
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.
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.
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))
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.
m_mode.patch (364 bytes)
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.
|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||=> 184.108.40.206|
|2013-02-19 19:36||syzop||Resolution||open => fixed|
|2013-02-19 19:36||syzop||Assigned To||=> syzop|