View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005064 | unreal | ircd | public | 2018-01-28 20:36 | 2018-03-07 10:25 |
Reporter | PeGaSuS | Assigned To | syzop | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | Unix | OS | Ubuntu | OS Version | 16.04 LTS |
Product Version | 4.0.17 | ||||
Fixed in Version | 4.0.18 | ||||
Summary | 0005064: 'set::cloak-method ip' not working properly with DNS resolving | ||||
Description | I had my network previously my network with set::options::dont-resolve (not resolving hostnames) to be able to give to my users a cloak in the format XXX.YYY.ZZZ.IP or XXX:YYY:ZZZ:IP (IPv4 or IPv6). But since UnrealIRCd 4.0.16, we have the option to enable DNS resolving and still allow the XXX.YYY.ZZZ.IP/XXX:YYY:ZZZ:IP cloaking format. So, I've enabled DNS resolving in my network and used 'set::cloak-method ip' as explained here: https://www.unrealircd.org/docs/Set_block#set::cloak-method. But I came across with one issue: different IP addresses are getting the same cloak, which didn't happened with set::options::dont-resolve enabled. | ||||
Steps To Reproduce | Enable DNS resolving and use 'set::cloak-method ip' and you'll probably face the same issue I'm facing, if enough users connect to the network | ||||
Tags | bug, conf, host, ip, ipv6, ircd | ||||
3rd party modules | m_anti_amsg, m_auditorium, m_banfix_voice, m_block_masshighlight, m_chansno, m_denyban, m_netadmins, m_noinvite, m_pmlist, m_uniquemsg all of them made by Gottem (i don't really think that any of those affects the cloaking system) | ||||
|
Side note: I've set severity to major as this affects some extbans like '+b ~q:something' as some innocent users my be sharing the same cloak. |
|
Thanks for the report. I'll take a look later this week. |
|
Confirmed. It does not occur in a single-server scenario but does occur on multi-server for remote users. |
|
Remote users were all seen as IP 255.255.255.255 by the cloaking layer, resulting in the same cloaked IP. This has now been resolved by doing a recalculation once the IP has been set. I could also have moved and duplicated code so it only has to be calculated once but that is dangerous as you have a NULL vhost for a short period of time which may cause crashes sooner or later. So went with the safe option of recalculating it... https://github.com/unrealircd/unrealircd/commit/41b7e1b73501d99b2a0a001e6564cc5c414b841d |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-01-28 20:36 | PeGaSuS | New Issue | |
2018-01-28 20:36 | PeGaSuS | Tag Attached: bug | |
2018-01-28 20:36 | PeGaSuS | Tag Attached: conf | |
2018-01-28 20:36 | PeGaSuS | Tag Attached: host | |
2018-01-28 20:36 | PeGaSuS | Tag Attached: ip | |
2018-01-28 20:36 | PeGaSuS | Tag Attached: ipv6 | |
2018-01-28 20:36 | PeGaSuS | Tag Attached: ircd | |
2018-01-28 20:39 | PeGaSuS | Note Added: 0020017 | |
2018-03-05 17:34 | syzop | Note Added: 0020019 | |
2018-03-07 10:08 | syzop | Assigned To | => syzop |
2018-03-07 10:08 | syzop | Status | new => confirmed |
2018-03-07 10:08 | syzop | Note Added: 0020039 | |
2018-03-07 10:25 | syzop | Status | confirmed => resolved |
2018-03-07 10:25 | syzop | Resolution | open => fixed |
2018-03-07 10:25 | syzop | Fixed in Version | => 4.0.18 |
2018-03-07 10:25 | syzop | Note Added: 0020040 |