Fixed inet_pton(): Unrecognized address unknown

AndyB

Well-known member
Affected version
XF v2.2.10 Patch 1
Since yesterday after upgrading to XF v2.2.10 Patch 1, there has been several hundred server error logs like this:

1658393353663.png
 

Kier

XenForo developer
Staff member
We've been running the new code here for several days and we've seen nothing like this. Further, I don't see how you could ever end up with unknown as the input to inet_pton, I suspect there is rogue add-on code at work here, but I await your further analysis.
 

Oldengine

Active member
Showing 20 of 317 items
Next
Log out
Community platform by XenForo®SMOKSTAK® is a Registered Trade Mark in the U.S. Trademark Office. "A Community of Antique Engine Enthusiasts." Copyright © 2000-2020 by Harry Matthews Inc. P.O. Box 5612, Sarasota, FL 34277v2.2.10 Patch 1

Server error log
  • ErrorException: [E_WARNING] inet_pton(): Unrecognized address unknown
  • src/XF/Util/Ip.php:382
  • Generated by: Unknown account
  • Jul 21, 2022 at 7:48 AM

Stack trace​

#0 [internal function]: XF::handlePhpError(2, '[E_WARNING] ine...', '/home/smoky/pub...', 382, Array)
#1 src/XF/Util/Ip.php(382): inet_pton('unknown')
#2 src/XF/Pub/Controller/AbstractController.php(151): XF\Util\Ip::checkIpsAgainstBinaryRangeList(Array, Array)
#3 src/XF/Pub/Controller/AbstractController.php(17): XF\Pub\Controller\AbstractController->assertIpNotBanned()
#4 src/XF/Mvc/Controller.php(125): XF\Pub\Controller\AbstractController->preDispatchType('Index', Object(XF\Mvc\ParameterBag))
#5 src/XF/Mvc/Dispatcher.php(351): XF\Mvc\Controller->preDispatch('Index', Object(XF\Mvc\ParameterBag))
#6 src/XF/Mvc/Dispatcher.php(263): XF\Mvc\Dispatcher->dispatchClass('XF:Thread', 'Index', Object(XF\Mvc\RouteMatch), Object(XFMG\XF\Pub\Controller\Thread), NULL)
#7 src/XF/Mvc/Dispatcher.php(115): XF\Mvc\Dispatcher->dispatchFromMatch(Object(XF\Mvc\RouteMatch), Object(XFMG\XF\Pub\Controller\Thread), NULL)
#8 src/XF/Mvc/Dispatcher.php(57): XF\Mvc\Dispatcher->dispatchLoop(Object(XF\Mvc\RouteMatch))
#9 src/XF/App.php(2353): XF\Mvc\Dispatcher->run()
#10 src/XF.php(524): XF\App->run()
#11 index.php(20): XF::runApp('XF\\Pub\\App')
#12 {main}

Request state​

array(4) {
["url"] => string(44) "/forum/threads/texas-shooting.222916/page-11"
["referrer"] => bool(false)
["_GET"] => array(0) {
}
["_POST"] => array(0) {
}
}
 

Xon

Well-known member
PHP:
    public function assertIpNotBanned()
    {
        $bannedIps = $this->app()->container('bannedIps');
        $result = \XF\Util\Ip::checkIpsAgainstBinaryRangeList($this->request->getAllIps(), $bannedIps['data']);

I'm guessing it is junk an incorrectly setup webserver which is allowing arbitrary text via CLIENT_IP/X_FORWARDED_FOR headers. The getIp function probably needs a bit of hardening to validate/parse the external headers if they are set.
 
Last edited:

AndyB

Well-known member
v2.2.9
pic001.jpg

v2.2.10 Patch 1
pic002.jpg

Looks like this line (see red arrow) was recently changed. Should I put back the line from the older version to fix this issue?
 

PaulB

Well-known member
So the problem comes from an incompatible addon?
No. It comes from using an old version of PHP that generates a warning when fed an invalid IP address instead of returning false like newer versions do. This behavior was changed in PHP 7.3, which is probably why @Kier et al haven't been able to reproduce it.

Really, the best solution here is to update to a newer version of PHP, but as long as XenForo supports PHP versions prior to 7.3, the fix on their end is to suppress the warning with @ or use a try-catch to disregard the error.

Edit: The underlying cause wasn't obvious because PHP removed any mention of the warning from their documentation. When you encounter language-level errors (rather than exceptions) that don't align with the current documentation, usually that's a sign the failure mode of the function changed between PHP versions--and, indeed, plugging this into 3v4l.org shows that's what happened here.

XenForo tries to correctly handle bogus input, which it needs to do since some of the input comes from user-supplied headers. PHP's handling of bogus data passed to inet_pton has changed over time. By prefixing inet_pton with @, you're effectively opting into the newer behavior. This will allow inet_pton to return false, which XenForo will correctly interpret to mean the IP address is invalid.

If you're encountering this issue, rather than manually fixing it, please consider upgrading to a newer version of PHP. :) I know that's a tall ask for a lot of sites, but if you were waiting for an excuse, now is as good an opportunity as any.
 
Last edited:

Baby Community

Well-known member
Thank you, Paul. You're 100% correct, the forum is running PHP 7.2. I will talk to the forum owner to arrange upgrading his PHP version.
for example xenforo gives information about a version when it is released. mysql: 5.5 also use PHP:8. Following those recommendations is to get the most out of the forum
 
Top