View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002933 | unreal | ircd | public | 2006-05-29 18:05 | 2006-11-03 17:38 |
| Reporter | avenger | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | i386 | OS | Linux | OS Version | 2.4.32 |
| Product Version | 3.2.4 | ||||
| Fixed in Version | 3.2.6 | ||||
| Summary | 0002933: SVSMODE +x error | ||||
| Description | When 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 Reproduce | Log 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 :services.network.org v <nick> -xt /os raw :services.network.org v <nick> +x You may /whois the user between each command to see how the vhost will behave during each phase. | ||||
| Additional Information | SVSMODE 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). | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
|
|
Check out http://bugs.unrealircd.org/view.php?id=2565 |
|
|
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. |
|
|
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! ;) |
|
|
Right. 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. :} |
|
|
Perhaps the +x and +t should all be (mostly) rewriten? Then we can have proper -x/+x and -t reactions :) |
|
|
xref http://bugs.unrealircd.org/view.php?id=2613 |
|
|
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 (0002933). 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. |
| 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 |
