For those seeing "arpresolve: can't allocate llinfo" messages and having routing failures
-
For anyone that has experienced an issue where routing completely fails on an interface and you see a spammed message in the system logs that looks like "arpresolve: can't allocate llinfo" this may be of help to you.
The root cause is that making a system setting change is somehow creating a bogus route in the routing table. You will see the interface that is not working now has a route for its gateway set to the same IP address (routing to itself). Removing the bad route resolves the issues immediately.
You can use Diagnostics > Command Prompt to run the following:
- netstat -r (look for any entry where the route and gateway are the SAME)
- route delete -net %bad_ip_route_here%
The frustrating thing about this apparent bug is that it happens rather randomly when making almost any change to the firewall settings. In my case, I typically see it appear when making changes to firewall rules, gateway or DNS settings. It has caused me many headaches as I haven't learned to go check the system log EVERY time I finish making changes to see if I "lost the dice roll" and need to fix it again.
I've been managing the same pfSense install since around 2.4.5 and I feel like this started becoming an issue for me around 2.5.2 (currently using 2.7.2). I even rebuilt the config from scratch on 2.7.2 thinking somehow my config file has been rolling something forward each time. This setup has 8 VLANs and 2 WANs which work fine as long as nothing is touched.
I would be interested to hear if any others have experienced this same issue and/or have anything to add.
-
I've run into this as well, but with outbound NAT.
See:
https://forum.netgate.com/topic/181522/more-starlink-arpresolve-can-t-allocate-llinfo-error-issues/2?_=1747413800900
This has to be one of the least helpful error messages in all of pfSense. That's saying something, as it has a lot of competition as far as unhelpful error messages go. It literally points the hapless admin nowhere useful.
-
That error is saying that the system is trying to add an IP as local to the arp table but cannot because it no longer has an interface in that subnet.
So commonly it means it's trying to reach a gateway IP but the WAN is down so the gateway doesn't exist locally.
-
@stephenw10 said in For those seeing "arpresolve: can't allocate llinfo" messages and having routing failures:
That error is saying that the system is trying to add an IP as local to the arp table but cannot because it no longer has an interface in that subnet.
So commonly it means it's trying to reach a gateway IP but the WAN is down so the gateway doesn't exist locally.
It's be great if the error message said that^. Customers aren't likely to be router developers.
-
It's an upstream, FreeBSD, error. We don't modify that, doing so would be extremely unhelpful for troubleshooting upstream issues. And be yet more technical debt.
-
@stephenw10 I understand the conflict.
If Netgate contributes to the open-source project, maybe this is an effort where it can contribute, namely, end-user comprehensible error messages.
If that's "too hard" then solve it with documentation: initiate an error messages and codes section of the user manual which lists the error messages, then what it means and directions to take for recovery.
As it is, customers are left thrashing around with support, or this forum, often at Negate's direct or indirect, uncompensated, expense.
For instance, DEC had the OpenVMS error messages and codes manual, which was helpful to the customers.
It seems to me we've regressed since then where error messages appear to have been made up on the spot by the developers and are substantially meaningful on their face mostly to developers.
Customers support the business. Making their life harder makes the business' life harder. Is that what business leadership wants?
Example:
https://www.digiater.nl/openvms/doc/alpha-v8.3/ovms_archived/OVMS_MSG_REF_AL.PDF
