View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002565 | unreal | ircd | public | 2005-06-17 22:09 | 2006-04-27 18:29 |
| Reporter | aquanight | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | X86 | OS | Windows | OS Version | XP Pro SP2 |
| Product Version | 3.2.3 | ||||
| Fixed in Version | 3.2.5 | ||||
| Summary | 0002565: SETHOST, cloaking, and VHP | ||||
| Description | Services servers typically use PROTOCTL VHP to save them the load of having to duplicate the cloaking algorithm by having unreal send the cloaked host as the vhost. However, I have noticed a minor detail: services have no guaranteed way to distinguish if a SETHOST is setting/reverting the cloaked host or setting a vhost (oper SETHOST). This can cause a problem for services with HostServ (like anope) that allow the user to turn off the vhost. Users request to have their vhost turned off and anope can only just SVSMODE -xt and tell the user to turn +x back on if they want regular cloaking. Of course, why can't services just SETHOST the cloaked IP/host? As I said, they can't tell if a SETHOST is the cloaked host or a manual vhost (which is especially important if servers don't put x in modes-on-connect) and thus cannot determine what the cloaked host *is*. Thus, the assumption that SETHOST == MODE +xt doesn't work for VHP links. I believe this could easily be solved if unreal explicitly synched any MODE +x or +t changes prior to sending a SETHOST to a VHP link. That way services can distinguish the "(re)setting cloaked host" SETHOST from vhost SETHOSTs. In the case of SETHOST, this would simply involve sendto_server_butone_token_opt(cptr, OPT_VHP, sptr->name, MSG_UMODE2, TOK_UMODE2, "+xt"), etc prior to sending out the SETHOST, and in MODE when handling a user setting +x, send the SETHOST after sending out the mode change. This would then allow services like, again, Anope to remember a user's cloaked host/IP and replace it after a user requests to have his vhost removed. (Technically this could be solved by duplicating the cloaking routine, but this is impractical especially since third-party cloaking modules are possible. Another option would be to allow services to load the cloaking module but that would almost require duplicating the unreal API entirely, which is also impractical.) | ||||
| Steps To Reproduce | - Remove x from modes-on-connect and restrict-usermodes (so that users are initially -x and may choose to /mode +x). Rehash, and reconnect. Notice lack of +x. - Link services such as Anope with debug output on (and preferablly nofork so you can watch the output in the terminal). - After services are synched, set usermode +x. - In the services log, you'll see that services receive a SETHOST your-cloaked.ip.here for you - and then a UMODE2 +x. - Oper and use SETHOST to set your own vhost (or let it get set for you from the oper hosts). Services receive only a SETHOST, no MODE change even though you actually have +xt. Services think you are only +x though. - Now set a vhost (or if you have one already, identify and activate it). Then /hostserv off. HostServ simply SVSMODE -xt's you. It should be able to simply CHGHOST your-cloaked.ip.here but it wouldn't be able to determine this because unreal makes no real attempt to distinguish sending the cloaking host from an actual vhost with VHP links. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Can I have the Cliff Notes on this? |
|
|
@Bugz: Unless you're involved with server protocol etc, I wouldn't bother trying to understand this :p That aside, we're looking at a way for getting WinSE to be able to HOSTMASK OFF by setting the user's hostmask back to their +x cloakedhost (if applicable). This isn't possible unless we know for sure what the user's cloaked host is, which isn't possible under the current system. NICKv2 sends realhost virthost, which is fine and dandy generally but what if you have something else setting hosts or an oper /chghost'ing or /sethost'ing. We're asking for a way around this, perhaps by the sending of the +x host through another method :p. |
|
|
Considering that cloaking borrows in the existing vhost stuff, I don't think finding an alternate method is suitable. It'll be enough for services to simply know upon receiving a vhost that if it's actually the realhost (user is -x), the cloaked host (user is +x-t), or a vhost (user is +xt). By sending the proper MODE messages, VHP links can be easily told of this. (This is already not a problem with NICKv2 or CHGHOST (since CHGHOST is *always* a vhost), only SETHOST). (Yes this is a problem if someone is introduced with a vhost, or goes from connected without +x straight to having a vhost, but since unreal doesn't store the cloaked host anyway, there's not much that can be done :) .) |
|
|
This issue is familiar to me, and I'd second it. At present I have to send a USERHOST and get back the answer asynchronously, when the umode x changes. I could cheat a little, tho haven't fully implemented it. |
|
|
SVSMODE -x SVSMODE +x Or would SVSMODE -x+x work? I dont know much about protocol, but if a SETHOST is sent out on a +x, would that work? |
|
|
I've been mucking around in Unreal server protocol for about a year now. No, we don't get a SETHOST on change of umode x. Nor does svsmode +x actually turn on cloaking. You can request the vhost with USERHOST, but that has the disadvantage of being asynchronous. Odder, I have noted that there is no UMODE2 sent alongside a SETHOST or CHGHOST. This causes some interesting issues with what I expect to see in the user data. I'm expecting I'll have to make the sethost/chghost handlers to also send a (virtual) UMODE2 into my loopback. |
|
|
I should note the existence of a module providing CLOAKHOST. This could allow you to get the appropriate cloaked host for a user. in combination with checking if umode t is set, you could (in theory, this is _somewhat_ imperfect), know if hte vhost is the cloakhost. if it is not, you could use the CLOAKHOST cmd. but that would be asynchronous. Then cache it. fwiw, until I learned the VHP trick, I had to use USERHOST to grab the vhost on every connect. similar with USERIP until I learned how to decode the NICKIP (I'm not using C, so I couldn't just grab Unreal's code) if anybody else is using Perl with this, you run it through teh base64 decoder, then use join('.', unpack('C4', $1)); # This yields it as a dotted quad string. Any other conversions, I'll leave as an exercise to the reader. |
|
|
@SETHOST: Yes, servers are expected to assume MODE +xt when receiving SETHOST, but this isn't always correct as is the case of VHP. And you only receive a SETHOST / MODE nick +x type deal if the cloaked host had been overwritten (a prior sethost/chghost). @CLOAKHOST: That'd be nice, if it was built-in. Oh and there's two problems with USERHOST : It's not guaranteed to be the cloaked host (you're still in the same boat as with VHP), and I don't think it's designed to be flung between servers (even though it does have a token :\ ). |
|
|
It does work btwn servers, and you're always asking your neighboring server. It might not be well suited, but it works. I know it won't always be the cloakhost. However you can guess based on if umode +t is set. But you only know that at connect and if you emulate the +xt on receiving CHGHOST/SETHOST. [edit] I'm wondering if my understanding is wrong... cuz it's at least different. My understanding is that SETHOST/CHGHOST always means +xt. (and it doesn't hurt to +xt if +x is already set, or even +xt). This also means that if we see +x set, we can assume that we should set vhost=cloakhost (assuming we know it). if +xt was explicitly set when a CHGHOST is done, we'd then need to differentiate btwn +x and +xt (or +t) being set. if at some time, someone explicitly sets their vhost to be the same as their cloakhost, that's not the services fault for not knowing. all i see is you trying ot reduce calls to USERHOST. Maybe you don't use USERHOST at all yet? I know Auspice used USERHOST... That's where I got the idea from originally. I don't think it even used VHP, tho I never checked. Also beware, if you send USERHOST using an opered agent, you'll always get the real-host. In this case, that's not desirable. [/edit] I haven't written the bit with feeding the +xt into the loopback. It so far hasn't been that important. Especially as I already knew that certain modes were 'weird'. like +s. which is never sent between servers. same with +O (tho +O is obvious) On the other hand I'm currently working on a new branch with a lot of new features and fixing up various bugs. Something I ran into recently was that I forgot to implement RFC1459's JOIN 0. I thought that the server would pass it to me as a series of PARTs or PART #chan1,#chan2. It makes for an excuse to push in stuff like this. Trouble is, the more patches I push in, the longer it will be until I can start _using_ it. |
|
|
Hmm would 0002613 solve this? And (assuming you have read 0002613), if you would -t (but not -x) and we sent out a SETHOST with the cloakedhost... Would this then be ok? Or are there still problems then... Yes, I'm sorry I have not 100% read everything of above, I'm tired and it's a bit too technical for me to read right now ;). |
|
|
2613 would simplify the HS OFF case, but it would not simplify (nor in any real way change) the 2565 (this bug) case. I don't really want to extend the NICKv2 protocol for this either, given that it's got enough stuff crammed into it already, and each NICKv2 change [potentially?] shortens the max GECOS field, which tends to bug users. |
|
|
Well the thing is I read here (aquanight, original bugreport): - Now set a vhost (or if you have one already, identify and activate it). Then /hostserv off. HostServ simply SVSMODE -xt's you. It should be able to simply CHGHOST your-cloaked.ip.here but it wouldn't be able to determine this because unreal makes no real attempt to distinguish sending the cloaking host from an actual vhost with VHP links. hence my thoughts.. it could simply -t if <thatotherbugid> would be implemented. But I guess you are saying it extends further, then.. I'm afraid I cannot comment on that today :P |
|
|
<thatotherbugid> == 0002613 |
|
|
Well, it seems to me that just the "if +xt and then -t, give user cloakhost"-thing would already solve quite some things. For the rest - which I agree is also a problem - I propose to add a new PROTOCTL thing that adds a new parameter to NICK which contains the cloaked host (making VHP no longer needed [but VHP will stay, naturally]). If I'm not mistaken, we are currently not hitting the 512 (510) limit by far, calculations below: /* ** m_nick ** parv[0] = sender prefix 63 (HOSTLEN) ** parv[1] = nickname 31 (NICKLEN) ** if from new client -taz ** parv[2] = nick password ** if from server: ** parv[2] = hopcount 3 ** parv[3] = timestamp 10 ** parv[4] = username 10 (?) ** parv[5] = hostname 63 (HOSTLEN) ** parv[6] = servername 63 (HOSTLEN) ** if NICK version 1: ** parv[7] = servicestamp ** parv[8] = info ** if NICK version 2: ** parv[7] = servicestamp 10 ** parv[8] = umodes 10 (EDUCATED GUESS) ** parv[9] = virthost, * if none 63 (HOSTLEN) ** parv[10] = info ** if NICKIP: ** parv[10] = ip 25 (LAZY GUESS [ipv6]) ** parv[11] = info 50 (REALLEN) */ Which adds up to 401. Anyway, to give some extra space for mistakes and/or more than 10 modechars, let's just say 425 (not that this would really be reached, but OK! Just hypothetical ;p).. Feel free to correct if I'm horribly wrong, but please don't nick-pick just a few bytes :P Anyway... So if we would add a cloakfield (as usual, right before the info field) if PROTOCTL "SFHDSIFDS" is given (j/k, I'll think of a name..).. then we got still enough room... 425 + 63 = 489 < 510 I don't suspect that many services are directly going to switch over once this is in, but it's nice as an option :P. EDIT: layout fix |
|
|
hm... since we don't have "extended" umodes (like we have for cmodes), I assume max 32 usermodes (and add one for the + I think?), and IPv6 will be 24 (16 bytes, b64 -> 24 "digits"), I think without it'll max out at 440 (with no TOKEN or NS), add another 64 for the cloakhost, it's 504... so yeah, no danger of going over there :P course, NS will shorten it by (HOSTLEN-3) * 2 (120) since both prefix and server param get numericized, and TOKEN saves another all of 3 bytes :P so with those it'd max out at 381... yup, no problem there! :P |
|
|
ok, thanks for the doublecheck :P |
|
|
It's probably not relevant, but I do remember one network that had modified it's ircd to get back the old 'long' GECOS. I don't know what length it was, and they said that beta17 vs 3.2.1, the GECOS field was shortened. Maybe it was, maybe it wasn't, I never noticed. I have noticed different ircds cutting off people's GECOS fields at different places, which annoys some users. Unfortunately, I have never measured the max lengths. However, this is the basis of my comment about shortening the GECOS. If we still have room to spare, then good, we don't have to worry about it. |
|
|
PROTOCTL CLK added in CVS [.489], no docs added though, but see Changelog for details. Hope it works... |
|
|
[quote]no docs added though[/quote] Of course, you probably knew I would fix that ;p . |
|
|
yup Though actually I meant doc/technical/protoctl.txt which I should have done :P. {Then again.. for some mysterious reason VHP is not mentioned in there either!} |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-06-17 22:09 | aquanight | New Issue | |
| 2005-06-18 01:00 | Stealth | Note Added: 0010093 | |
| 2005-06-18 01:05 | w00t | Note Added: 0010094 | |
| 2005-06-18 01:11 | aquanight | Note Added: 0010095 | |
| 2005-06-18 01:13 | aquanight | Note Edited: 0010095 | |
| 2005-06-18 01:13 | aquanight | Note Edited: 0010095 | |
| 2005-06-19 05:42 | tabrisnet | Note Added: 0010100 | |
| 2005-06-25 20:56 | JasonTik | Note Added: 0010126 | |
| 2005-06-25 21:04 | tabrisnet | Note Added: 0010127 | |
| 2005-06-25 21:13 | tabrisnet | Note Added: 0010128 | |
| 2005-06-25 21:23 | tabrisnet | Note Edited: 0010128 | |
| 2005-06-25 21:47 | aquanight | Note Added: 0010129 | |
| 2005-06-25 21:48 | aquanight | Note Edited: 0010129 | |
| 2005-06-25 21:53 | aquanight | Note Edited: 0010129 | |
| 2005-06-26 00:56 | tabrisnet | Note Added: 0010130 | |
| 2005-06-26 01:12 | tabrisnet | Note Edited: 0010130 | |
| 2006-03-15 15:19 | syzop | Note Added: 0011377 | |
| 2006-03-15 15:39 | tabrisnet | Note Added: 0011379 | |
| 2006-03-15 15:52 | syzop | Note Added: 0011380 | |
| 2006-03-15 18:38 | Stealth | Note Added: 0011383 | |
| 2006-03-15 18:38 | Stealth | Note Edited: 0011383 | |
| 2006-03-25 14:01 | syzop | Note Added: 0011435 | |
| 2006-03-25 14:02 | syzop | Note Edited: 0011435 | |
| 2006-03-25 14:23 | aquanight | Note Added: 0011436 | |
| 2006-03-25 14:31 | syzop | Note Added: 0011437 | |
| 2006-03-31 12:11 | tabrisnet | Note Added: 0011460 | |
| 2006-04-02 16:48 | syzop | Relationship added | child of 0002748 |
| 2006-04-16 18:30 | syzop | Note Added: 0011560 | |
| 2006-04-17 01:16 | aquanight | Note Added: 0011569 | |
| 2006-04-17 10:55 | syzop | Note Added: 0011570 | |
| 2006-04-27 18:29 | syzop | Status | new => resolved |
| 2006-04-27 18:29 | syzop | Fixed in Version | => 3.2.5 |
| 2006-04-27 18:29 | syzop | Resolution | open => fixed |
| 2006-04-27 18:29 | syzop | Assigned To | => syzop |
