View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004018 | unreal | ircd | public | 2011-04-06 04:10 | 2012-01-22 16:12 |
| Reporter | katsklaw | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.2.10-rc1 | ||||
| Summary | 0004018: [Feature] Add CAPAB Support | ||||
| Description | Add CAPAB support, at least for clients: this makes it easier for clients to discover features before they are fully connected. Think of features like STARTTLS. ** katslaw' text, regarding server-to-server (see comments later on): ** As we have seen in Inspircd and U4, CAPAB lends a great deal of flexibility when communicating to other servers, namely services about our functionality. Case in point, Anope's proto module for Inspircd allows the ircd to tell services which modules are loaded so the services protocol can load the correct features. If a feature is added or removed, simply restart and they are both back in sync again. It should go without saying that it's vital for services and all ircds on the network to be on the same page when it comes to features. CAPAB is perfect for such a task. With CAPAB in hand it will be easier to create a more dynamic ircd and make more feature and commands optional. Unreal is a modular IRCd for sure, but not very dynamic when communicating which features are enabled or disabled. I can easily make the channel modes +aq or even +h optional in just a few minutes, but this will now mess up services unless I also alter it's proto module as well. This is still very static and not endorsing our already modular nature. Adding CAPAB will help solve this. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
This is a feature, not a minor bug, for some reason I keep forgetting to set it :/ |
|
|
katsklaw: set to feature ;-). I only have the vaguest idea of what capab is, but I think it'd probably be a good thing to have. |
|
|
Didn't know I had access to change it, sorry ;P The way I understand it is it works along the same lines as raw 005 does, Inspircd uses it to tell Anope which modules are loaded so Anope can load it's matching counterpart. Lets say for a minute that chanmodes +aq were optional and net1 disabled it, as-is we would have to edit anope's proto module to disable it. With capab we can tell anope if we have the aq module loaded so that it can set it's internals to match. CAPAB is sent during burst, so if we enable +aq then restart both the ircd and Anope, services will be informed at burst that +aq is now used. Heres a snippet from protocol/inspircd12.c } else if (strcasecmp(av[0], "CAPABILITIES") == 0) { char *h = strstr(av[1], "HALFOP"); if (h && h[7] == '1') { has_halfop = 1; } } else if (strcasecmp(av[0], "MODULES") == 0) { if (strstr(av[1], "m_globops.so")) { has_globopsmod = 1; } if (strstr(av[1], "m_services_account.so")) { has_servicesmod = 1; } if (strstr(av[1], "m_svshold.so")) { has_svsholdmod = 1; } if (strstr(av[1], "m_chghost.so")) { has_chghostmod = 1; } if (strstr(av[1], "m_chgident.so")) { has_chgidentmod = 1; Anope can use CAPAB in much the same way clients like mIRC can use raw 005 to set various settings, like mode stacking, topic lengths, supported chanmodes, etc .. |
|
|
Not commenting on CAPAB itself, but: Note that for channel modes we send the CHANMODES= line in PROTOCTL. I started doing that (many versions ago) so f.e. services could see which channel modes are in use. I don't think any of them ever did something with it though. |
|
|
hi, PROTOCTL and CAPAB do the same exact thing, so i think this bug can be closed. inspircd just has a more complex capability negotiation because their product is considerably more complex due to over-modularity. |
|
|
I presume you were speaking to katsklaw, and not me ;) Anyway this bug shouldn't be closed, you just made a patch for exactly this feature request in 0004066! I've marked that one as duplicate because it should have been posted here. Of course, thanks for the patch, I'll take a look at it, hopefully this weekend. If it's good, I'll apply it. I just haven't had a chance to read it in-depth, and I didn't see any comments from binki about it either. Once that patch is applied, we'd also need STARTTLS support. I mean, UHNAMES and NAMESX in CAPAB is nice... as it fixes some issues that PROTOCTL can not, to be more specific: enabling that capability before auto-join's take effect[*], but CAPAB gets a lot more useful when STARTTLS is added IMO. I saw some conversation somewhere regarding whether an SSL session should start immediately or not when signalling STARTTLS capability from the client to the server. I tend to an explicit STARTTLS command, but there are really two perspectives here... I don't know what other ircd(s) and clients such as kvirc do. [*] I'd refer to a conversation from me and codemastr on the bugtracker more than 7 years ago about a need for capability indication, but can't find it that quickly. |
|
|
hi, no. this CAPAB is for server-to-server notification, specifically the protocol lines katsklaw posted were part of inspircd's handshake process. 0004066 is for client-to-server. i think PROTOCTL is ok for server-to-server. CAPAB in TS5/TS6 are basically the same thing as what PROTOCTL is doing here, and unreal does not have the level of configure ability inspircd has, so there is no need for an inspircd CAPAB in my opinion. |
|
|
I already edited this issue back in December to make it client CAPAB. If you read the first few sentences of the description, you'll see ;) And I agree, there's no need for s2s CAPAB at this point AFAICT, there's no reason to use CAPAB over PROTOCTL. |
|
|
- Add CAP support. Currently implemented are: multi-prefix (NAMESX), and userhost-in-names (UHNAMES). Patch from nenotopia (0004018, 0004066). http://hg.unrealircd.com/hg/unreal/rev/39c2196a29d7 Only slightly edited/enhanced. Thanks for the patch! To do: * Do some CAP testing * Verify Windows (compile, run) * Possibly some more... After STARTTLS (advertising) support has been added, this bug can be closed. |
|
|
hi, please apply the patch in 0004077 to fix some last-minute regressions found when using the NOSPOOF feature. |
|
|
hi, the patch in 0004081 switches on the 'tls' capability for starttls, as used by inspircd. this seems to be the best solution as inspircd has already used this keyword for some time and it was agreed upon by various client and server authors etc. |
|
|
I've applied both patches, thanks! This bugid can now be closed, from my side it's purpose was getting CAP support with at least STARTTLS, which has now been completed. (For s2s CAPAB see comment 0004018:0016875) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-04-06 04:10 | katsklaw | New Issue | |
| 2011-04-06 04:48 | katsklaw | Note Added: 0016636 | |
| 2011-04-06 06:34 | ohnobinki | Note Added: 0016637 | |
| 2011-04-06 06:34 | ohnobinki | Severity | minor => feature |
| 2011-04-07 03:58 | katsklaw | Note Added: 0016638 | |
| 2011-04-07 04:01 | katsklaw | Note Edited: 0016638 | |
| 2011-04-07 04:02 | katsklaw | Note Edited: 0016638 | |
| 2011-04-09 15:23 | syzop | Note Added: 0016639 | |
| 2011-12-21 10:39 | syzop | Description Updated | |
| 2012-01-09 22:50 |
|
Note Added: 0016854 | |
| 2012-01-20 09:52 | syzop | Relationship added | has duplicate 0004066 |
| 2012-01-20 10:06 | syzop | Note Added: 0016873 | |
| 2012-01-20 18:59 |
|
Note Added: 0016874 | |
| 2012-01-20 20:56 | syzop | Note Added: 0016875 | |
| 2012-01-20 21:29 | syzop | Note Added: 0016877 | |
| 2012-01-22 10:06 |
|
Note Added: 0016880 | |
| 2012-01-22 10:33 |
|
Note Added: 0016881 | |
| 2012-01-22 16:12 | syzop | Note Added: 0016885 | |
| 2012-01-22 16:12 | syzop | Status | new => resolved |
| 2012-01-22 16:12 | syzop | Fixed in Version | => 3.2.10-rc1 |
| 2012-01-22 16:12 | syzop | Resolution | open => fixed |
| 2012-01-22 16:12 | syzop | Assigned To | => syzop |
