View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003533||unreal||ircd||public||2007-09-18 07:08||2007-09-22 11:30|
|Summary||0003533: CGI:IRC not working properly w/ IPv6 compiles|
|Description||Basically in short, when trying to connect a CGI:IRC connection that is configured properly in the cgiirc block at least, and the client connecting is an IPv4 IP, UnrealIRCd rejects with an "Invalid IP address" killing the connection.|
This being due to line 158 in m_pass.c under /src/modules which is:
if (inet_pton(AFINET, ip, &cptr->ip) <= 0)
AFINET being set depending on the compile of UnrealIRCd, if UnrealIRCd gets compiled with IPv6 support, AFINET becomes AF_INET6 which means inet_pton() tries to compare ip as an IPv6 IP, which would obviously fail with an IPv4 client being passed into it.
Discussing this with a staff member of CGI:IRC's channel came down to basically the suggestion of modifying line 158 to be:
if ((inet_pton(AF_INET, ip, &cptr->ip) <= 0) && (inet_pton(AF_INET6, ip, &cptr->ip) <= 0))
That way it will check both really, and as long as one returns with a value of 1 it will skip the exit_client(), else if both return incorrect it will return with an exit_client()
Obviously other methods could be taken such as to check the IP before hand various ways to determine if its an IPv4 or IPv6 IP format and then set a different control for AFINET depending on that, etc.
Modification credit goes also to OUTsider @ CGI IRC's channel.
Attached is a .diff for the modification
|Tags||No tags attached.|
|3rd party modules|
cgiirc-ipv6-fix.diff (629 bytes)
||Duplicate of 0003311|
Grar... I searched, but couldn't find anything else in relation to 'IPv6' and 'CGI IRC' :/
Guess it was the missing :, figured the space would make it kinda global match it, ah well, though I think I covered it in detail a bit more than that one : P
Thanks for the note though >.>
This issue was high on my list (stupid simple bug), so I was about to work on it. I looked at your patch but that would not be the way to do things... you're using inet_pton to feed an ipv4 structure (which inet_pton would create with that flags) in an ipv6 structure (which cptr->ip is on a IPv6 compile), whether it seems to work or not... it's not 'legit'.
I made another patch to, indeed, first check if it's ipv4 and then take appropriate action.
Will commit after testing, follow 0003311
Thanks for the effort though :P
||I'll take a look at the commit, see how it looks compared to mine (I sorta did a butcher job in my network patch for IP validation just to fix it quick, haha) as I wasn't so much a fan of the double inet_pton lookup mainly, and validation before hand is generally a more common idea, but sadly that double check in the if() was a bit more cleanly than I had in mine at the time I posted it quick.|
|2007-09-18 07:08||nate||New Issue|
|2007-09-18 07:08||nate||File Added: cgiirc-ipv6-fix.diff|
|2007-09-18 07:08||nate||QA||=> Not touched yet by developer|
|2007-09-18 07:08||nate||U4: Need for upstream patch||=> No need for upstream InspIRCd patch|
|2007-09-18 07:08||nate||U4: Upstream notification of bug||=> Not decided|
|2007-09-18 07:08||nate||U4: Contributor working on this||=> None|
|2007-09-18 12:15||Stealth||Note Added: 0014784|
|2007-09-18 18:06||nate||Note Added: 0014785|
|2007-09-19 04:30||syzop||Status||new => closed|
|2007-09-19 04:30||syzop||Note Added: 0014787|
|2007-09-19 04:30||syzop||Resolution||open => duplicate|
|2007-09-19 04:32||syzop||Relationship added||duplicate of 0003311|
|2007-09-22 11:30||nate||Note Added: 0014792|