View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001876 | unreal | ircd | public | 2004-06-16 22:39 | 2004-06-24 20:58 |
| Reporter | al5001 | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Product Version | 3.2 | ||||
| Summary | 0001876: (IPv6) - Long substring address channel bans are ineffective. | ||||
| Description | This issue occurs when banning a user from a channel with a long IPv6 substring address, such as fe80:0000:0000:0000:0000:0000:0000:0001. -Banning *!*@fe80:0000:0000:0000:0000:0000:0000:0001 Will not affect the user. -Banning *!*@fe80::0001 will affect the user. -Banning *!*@fe80:0:0:0:0:0:0:0001 will affect the user. | ||||
| 3rd party modules | |||||
|
|
First thing, you failed to provide the IP you say it does/doesn't work with. But, I'm not really sure I'm ready to consider this a bug. It's not, we didn't add these things. Unreal matches as a hostmask, and that's how it must. Tell me, what if you enter 123::123*, how do we interpret that? We can't. How many 0's does the :: represent? There is no way to tell. Quickly glancing over those, none of them should work. And if they do, I really don't know how. So I need more info before I can do anything. |
|
|
I would like to add that banning *@0:0:0:0:0:0:0:1 will not affect a user with that address. (this is the same address as ::1, and a ban on ::1 will affect the user) Banning the short form address will affect the user. I don't see any reason to add support for banning those full canonical forms, because it means extra work, and also because it's not critical, only to those who insist on banning the full canonical address form. The short form is easier to type however, it may be a good idea to put that in the documentation, telling people to replace long strings of 0's with :: and to omit up to 3 leading 0's inside each octet before setting channel bans on IPv6 addresses. The IRCd omits them automatically, though, so you won't have to worry much about it. But say you came across an IPv6 address in full canonical form and wanted to ban it, you cannot ban the full form, you must translate it into short form, as shown below. Example: Full canonical form: fe80:0000:0000:0000:0000:0000:0000:0001 Short form: fe80::1 Note: there are many other forms you can make from this, such as omitting the first 3 leading 0's in each octet, but please, for the sake of simplicity, just stick with the short one. edited on: 2004-06-16 23:57 |
|
|
Well, 123::123 would be the same as 0123:0000:0000:0000:0000:0000:0000:0123... or it could be written like this 123:0:0:0:0:0:0:123. On top of that there is also CIDR in IPv6, which is not yet implemented in the IRCd. The IP it doesn't work with is my own IP, but this issue can be done with any IPv6 address that has the long strings of 0's. |
|
|
I didn't say 123::123, I said 123::123*. Bans support wildcards. There is no way to interpret that because you can not tell how many segements of 0's the :: represents, because the * could also represent 0's. Anyway though, saying "my IP" doesn't help me. I need to see the actual IP, as Unreal displays it. Instead of giving me a ton of info I didn't ask for, just give me the IP you say those bans match, that's what I need. |
|
|
Okay. Full canonical form of my IP: 3ffe:bc0:8000:0000:0000:0000:0000:33e2 I connected to my server with this address. UnrealIRCd changes the address to a different form by omitting the first 3 0's in each octet, but does not replace the strings of 0's with ::, which is fine. There is no bug with that, since the address can be interpreted in three different ways. --- al5001 :is connecting from *@3ffe:bc0:8000:0:0:0:0:33e2 A shorter form of the IP is: 3ffe:bc0:8000::33e2 Bans that affect this user: *@3ffe:bc0:8000:0:0:0:0:33e2 *@3ffe:bc0:8000::33e2 Bans that do not affect this user: *@3ffe:bc0:8000:0000:0000:0000:0000:33e2 edited on: 2004-06-17 00:10 edited on: 2004-06-17 19:25 |
|
|
*@3ffe:bc0:8000::33e3 If that affects the user, we have a big problem, because Unreal's +b does NOT deal with :: at all. That should 100% NOT work. |
|
|
This is how an ipv6 user will look like on unreal: [20:33:34] * Zwei (x@fe80:0:0:0:250:fcff:fe2b:eb1b) has joined #test so it doesn't have any leading zero's or something (aka: fe80:0000:0000:etc) Then, a ban on the exact string: [20:33:47] * Ein sets mode: +b *!*@fe80:0:0:0:250:fcff:fe2b:eb1b [20:33:49] * Zwei was kicked by Ein (Ein) :maintest.test.net 474 Zwei #test :Cannot join channel (+b) works.. [20:36:48] * Ein sets mode: +b *!*@fe80::250:fcff:fe2b:eb1b [20:36:56] * Zwei was kicked by Ein (Ein) :maintest.test.net 474 Zwei #test :Cannot join channel (+b) so you are right. Now how does this come? Breakpoint 1, is_banned (sptr=0x8191ae8, chptr=0x8191158, type=0) at channel.c:574 574 int dovirt = 0, mine = 0; (gdb) n 577 if (!IsPerson(sptr)) (gdb) 580 ban_realhost = realhost; (gdb) 581 ban_ip = ban_virthost = NULL; (gdb) 583 if (MyConnect(sptr)) { (gdb) 584 mine = 1; (gdb) 585 s = make_nick_user_host(sptr->name, sptr->user->username, Inet_ia2p(&sptr->ip)); (gdb) 586 strlcpy(nuip, s, sizeof nuip); (gdb) 587 ban_ip = nuip; (gdb) 590 if (sptr->user->virthost) (gdb) x/s ban_ip 0x80d0440 <nuip.2>: "Zwei!x@fe80::250:fcff:fe2b:eb1b" tada :P I guess I should use a different function for this? The one that will use the same form as how a user shows up :P. |
|
|
char *Inet_ia2p(struct IN_ADDR *ia) - does ipv6 and ipv4 (autodetect ::ffff:a.b.c.d) - returns ipv6 in compressed form :/ char *Inet_ia2pNB(struct IN_ADDR *ia, int compressed) - allows to specify 'compressed' - does not handle ipv4 seperately (so will use ffff crap) char *inetntop(int af, const void *in, char *out, size_t the_size) - will always use non-compressed form - requires af type / not suitable for us const char *inet_ntop(int af, const void *src, char *dst, size_t size) - will use compressed form - requires af type / not suitable for us hm ;). Inet_ia2pNB is/was pretty close. It's currently (only) in use by src/modules/m_server.c for: /* * We first try match on uncompressed form ::ffff:192.168.1.5 thing included */ if (!aconf) aconf = Find_link(cptr->username, cptr->sockhost, Inet_ia2pNB(&cptr->ip, 0), servername); /* * Then on compressed */ if (!aconf) aconf = Find_link(cptr->username, cptr->sockhost, Inet_ia2pNB(&cptr->ip, 1), servername); Hmhm :). Basically the question is.. are we gonna change 1, and if so which? Or are we going to add yet-ANOTHER-one :P. |
|
|
Stupid me... we have sptr->sockhost for that! Confusing stuff btw: sptr->sockhost = uncompressed form Inet_ia2p() and get_ip() = compressed form I wouldn't be surprised if this general inconsistency causes lot of subtle (non-)match bugs, perhaps something to review in the future ;). Anyway, this particular ban bug is fixed in CVS (.70). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-06-16 22:39 | al5001 | New Issue | |
| 2004-06-16 23:26 |
|
Note Added: 0006658 | |
| 2004-06-16 23:45 | al5001 | Note Added: 0006660 | |
| 2004-06-16 23:52 | al5001 | Note Added: 0006661 | |
| 2004-06-16 23:55 |
|
Note Added: 0006662 | |
| 2004-06-16 23:57 | al5001 | Note Edited: 0006660 | |
| 2004-06-17 00:04 | al5001 | Note Added: 0006663 | |
| 2004-06-17 00:09 | al5001 | Note Edited: 0006663 | |
| 2004-06-17 00:10 | al5001 | Note Edited: 0006663 | |
| 2004-06-17 00:10 |
|
Note Added: 0006664 | |
| 2004-06-17 14:40 | syzop | Note Added: 0006673 | |
| 2004-06-17 14:55 | syzop | Note Added: 0006674 | |
| 2004-06-17 19:25 | al5001 | Note Edited: 0006663 | |
| 2004-06-24 20:07 | syzop | Status | new => assigned |
| 2004-06-24 20:07 | syzop | Assigned To | => syzop |
| 2004-06-24 20:58 | syzop | Status | assigned => closed |
| 2004-06-24 20:58 | syzop | Note Added: 0006776 |
