Fixed inet_pton(): Unrecognized address unknown


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:

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.
Showing 20 of 317 items
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) {
    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:

v2.2.10 Patch 1

Looks like this line (see red arrow) was recently changed. Should I put back the line from the older version to fix this issue?
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 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:
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 Bottom