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 |
| Reporter | nate | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Platform | i386 | OS | All | OS Version | All |
| Product Version | 3.2.7 | ||||
| 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. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
|
|
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 >.> |
|
|
heh. 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. |
| 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 |
