View Issue Details

IDProjectCategoryView StatusLast Update
0003533unrealircdpublic2007-09-22 11:30
Reporternate Assigned To 
Status closedResolutionduplicate 
Platformi386OSAllOS VersionAll
Product Version3.2.7 
Summary0003533: CGI:IRC not working properly w/ IPv6 compiles
DescriptionBasically 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
TagsNo tags attached.
3rd party modules


duplicate of 0003311 resolvedsyzop CGI:IRC & IPv6 Issue 


2007-09-18 07:08



2007-09-18 12:15

reporter   ~0014784

Duplicate of 0003311


2007-09-18 18:06

reporter   ~0014785

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 >.>


2007-09-19 04:30

administrator   ~0014787


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


2007-09-22 11:30

reporter   ~0014792

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.

Issue History

Date Modified Username Field Change
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