View Issue Details

IDProjectCategoryView StatusLast Update
0002933unrealircdpublic2006-11-03 17:38
ReporteravengerAssigned Tosyzop 
Status resolvedResolutionfixed 
Platformi386OSLinuxOS Version2.4.32
Product Version3.2.4 
Target VersionFixed in Version3.2.6 
Summary0002933: SVSMODE +x error
DescriptionWhen services issue mode +x to restore users's original Cloak, instead of resetting the vhost, nothing is done and the vhost simply remains the same before svs/2/mode -xt
Steps To ReproduceLog as a services, or get access to /os raw, after assigning a Vhost to you throught HostServ or such a service which sends CHGHOST to the client. Then send the text command throught the services server: :NickServ SVS2MODE <nick> -xt ;; then send :Nickserv SVS2MODE <nick> +x

SVSMODE does the same as well... Other way to reproduce:
/CHGHOST <nick> a.given.vhost
/os raw v <nick> -xt
/os raw v <nick> +x

You may /whois the user between each command to see how the vhost will behave during each phase.
Additional InformationSVSMODE does the same problem. As stated, the only difference between SVS2MODE to SVSMODE is that SVS2MODE still sends the mode change to the client, while SVSMODE no longer does.

the 'v' command stands for SVS2MODE token.

You can't send by services a 'MODE, UMODE or UMODE2' which -would- do the trick. Ah. To reproduce 'normal' behavior (assuming mIRC client)
//CHGHOST $me a.given.vhost
//mode $me -x
//mode $me +x

All this were tested assuming ircd has the 'host cloak' with the three cloak-keys set, and all the same throughout the network, and services u-lined (as they can actually change any umode throught SVSMODE).
TagsNo tags attached.
3rd party modules


child of 0002936 resolvedsyzop 3.2.6 Release 



2006-05-29 18:08

reporter   ~0011793

Check out

2006-05-30 08:51


m_svsmode_modeaddx.patch (3,578 bytes)


2006-05-30 09:00

reporter   ~0011803

Last edited: 2006-05-30 09:09

RandomNumber, well, it is truly a solution for the problem. But there's still a miss: SVSMODE/SVS2MODE +x behave not like ordinary MODE +x. They just send the mode change (as applicable) and the UMODE_HIDE to the user pointer, but does not analyse if it is a case to re-calculate the Cloak (if no +t is present).

This patch I provided is to unreal 3.2.4 and will fix the issue by setting the behavior of SVSMODE 'x' case (when MODE_ADD) to the same as normal MODE would do (actually, I copied the code from m_mode.c and adapted the pointers to match the names from do_svsmode m_svsmode.c's function.

I am not intended in changing the ircd in any manner, take this patch as a suggestion, I prefer using out-of-box Unreal ircd code (without changing a singe line from the code), but as in the #unreal-support channel they seemed no care for the issue, and I should put services working, I were forced to make this patch and see things working by myself. The patch is not also bug-free, I have not tested it when multiple servers are on also.

EDIT: Ah, the point is: with the fix on the suggested link, there will supposedly still have the error with the mode change. That is: If a user logs on, and the ircd does not do host cloaking by default (it will not calculate the cloak then, right?), and services send a SVSMODE +x, the user will remain with the main IP instead of a cloak. This patch intends in issuing the same procedures ordinary /MODE would do if the own user types //mode $me +x (in mIRC for example). The procedures include issuing 'make_virthost()' which will generate the cloaked host if applicable. The same tests were copy-pasted from m_mode.c to m_svsmode.c.


2006-05-30 10:19

administrator   ~0011804

I didn't know it had such odd behavior on -x/+x (oddly enough, bug 0002565 doesn't really make that clear), and my first reaction would too be "let's just fix that"... But.. second thing that comes up with my mind is: wouldn't it break stuff?
I'm thinking, maybe a better solution would be to act on -x: namely to free the vhost and put the cloaked host in that field (but not activate it). That way a (next) +x would use the cloaked host. So with SVSMODE target -xt+x you could then set the user cloaked (I know, just "-t" is nicer, but.. bleh). While still remaining compatible with services doing SETHOST, mode +xt (after all, when setting +x it might not know yet +t is going to be set, unless you want to look-ahead, blabla).

Problem is, we just went into testing stage a few days ago, and that basically means... "don't touch CVS right now!" ;). So will take a look at that post-3.2.5 (which is in 3 weeks).
Bad timing... can happen! ;)


2006-05-30 20:42

reporter   ~0011805


Ah, you say to build the cloak (in the hidden host var or something like it) on -x mode. Right. So, don't forget to also fill that variable with the cloaked host 'on connection', cause I think that the +x does the make_virthost() upon connection so, if you change the procedure from +x to -x, maybe it will be needed then to have somewhere else the make_virthost() for new connections.

Well, just a reminder for when you look here at a later time. :}


2006-05-30 23:21

reporter   ~0011806

Perhaps the +x and +t should all be (mostly) rewriten?

Then we can have proper -x/+x and -t reactions :)


2006-07-04 21:53

reporter   ~0012055

Last edited: 2006-07-04 21:54



2006-11-03 17:38

administrator   ~0012568

Fixed in CVS (32* and 33*):
- Using SVSMODE (or SVS2MODE) to set -x will now actually remove the vhost from memory,
  instead of letting it magically reappear whenever +x is set. This means services can
  now properly "unvhost" a user by sending a "SVSMODE User -x+x" (then any existing vhost
  will be removed and user will have a cloaked host). Reported by avenger and others

One note... I did not implement the denied/forcerejoin/etc stuff...... (yet?). Anyway that asside, it seems to work.

I tested things and they appear to work as expected... If you think anything is super-wrong, let me know.

Issue History

Date Modified Username Field Change
2006-05-29 18:05 avenger New Issue
2006-05-29 18:08 RandomNumber Note Added: 0011793
2006-05-30 08:51 avenger File Added: m_svsmode_modeaddx.patch
2006-05-30 09:00 avenger Note Added: 0011803
2006-05-30 09:09 avenger Note Edited: 0011803
2006-05-30 10:19 syzop Note Added: 0011804
2006-05-30 20:42 avenger Note Added: 0011805
2006-05-30 23:21 Stealth Note Added: 0011806
2006-05-31 07:20 syzop Status new => confirmed
2006-05-31 07:23 syzop Relationship added child of 0002936
2006-07-04 21:53 tabrisnet Note Added: 0012055
2006-07-04 21:54 tabrisnet Note Edited: 0012055
2006-07-04 21:54 tabrisnet Note Edited: 0012055
2006-11-03 17:38 syzop Status confirmed => resolved
2006-11-03 17:38 syzop Fixed in Version => 3.2.6
2006-11-03 17:38 syzop Resolution open => fixed
2006-11-03 17:38 syzop Assigned To => syzop
2006-11-03 17:38 syzop Note Added: 0012568