A bug? - kernel: arpresolve: can't allocate linfo for xx.xx.xx.xx
I'm pulling my hair out. From what I read in other posts this issue seems to be unsolved? And, unexpected? Could it be a bug?
kernel: arpresolve: can't allocate linfo for xx.xx.xx.xx
as soon as I add a OPT1 gateway.
My setup is this:
LAN ip - 192.168.0.1
WAN fixed ip 10.0.0.2 connected to ADSL router with fixed ip 10.0.0.1 with NAT to outside DSL ISP1 with DHCP assigned IP.
OPT1 fixed ip 10.0.1.2 connected to ADSL router with fixed ip 10.0.1.1 with NAT to outside DSL ISP2 with DHCP assigned IP.
WANGW fixed ip 10.0.0.1
OPT1GW fixed ip 10.0.1.1
All devices on LAN within subnet 192.168.0.x with unique IPs assigned by Pfsense.
ISP1 DHCP assigned IP subnet is outside of any of the above.
ISP2 DHCP assigned IP subnet is outside of any of the above.
ISP1 and ISP2 are not on same subnet
As soon as I assign the OPT1 interface, even before I create OPTGW I get hundreds of kernel: arpresolve: can't allocate linfo for 10.0.1.1 messages.
Also, connectivity to the internet is immediately severed, even though the WANGW stays online and active. I've even set the default LAN allow rule to use WANGW, thinking it might not know which gateway to use. But that had no effect.
Disabling the OPT1 interface has no effect. In order to restore connectivity the OPT1 interface must be deleted and machine restarted before connectivity is restored and kernel: arpresolve: can't allocate linfo for 10.0.1.1 messages stop.
I've tested both ISPs separately. When connected to router with IP 10.0.0.1 the gateway is up and internet accessible.
I've also swapped out the routers, such that WANGW router with IP 10.0.1.1 is connected to WAN. And, OPTGW router with IP 10.0.0.1 is connected to OPT1. Same result, internet inaccesible, WANGW reports to be online and kernel: arpresolve: can't allocate linfo for 10.0.0.1 messages, now with the other IP, reappear.
During all of this OPTGW never reported to be online - even though the router itself was in fact logged in to the ISPx.
Without the second gateway the setup works like a charm. And, it doesn't seem that anyone has managed to solve this specific issue. Even though it has been reported a number of times.
Sticky connections not enabled.
Setting up a loadbalance group and routing lan default allow through the loadbalance group makes no difference.
Anyone with ideas? Please, please help.
It seems many people will be helped when this is solved.
PS: @heper - I noted you also had the same issue. Did you manage to solve it?
Since it is obviously a network error - will it help if I set the ADSL modems to bridge mode, such that they function as old school modems?
Then use PFsense to do the login for me?
heper last edited by
It all seemed to be because my cable isp expired the dhcp lease before pfsense renewed it. Then i got assigned a local a.b.c.x ip (or so i think).
This a.b.c.x ip might have conflicted with my WAN2 dsl router subnet ….
I've solved it by putting my WAN2 subnet to something different and adding reliable NTP servers to my ESXI vm environment
In my case i had this problem once a week or so ....
Your case seems different as you can't even assign the interface.
Are you sure that you subnet is correct ?? did you set it 10.0.0.2/24 & 10.0.1.2/24 (do the same on the dsl router end)
If for example you'd have set it to 10.0.0.2/8 then you'd have conflicting adress'
have fun figuring it out :)
By the looks of it, indeed, your problem seems to be very different from mine. Congrats on solving your network conflict - sounds like your issue is difficult to replicate, so all the more difficult to debug.
Back to the problem I'm experiencing, I think you've solved this for me ;D - I indeed specified 10.0.0.2/8 and not 10.0.0.2/24. I'm going to try it this afternoon.
It would be kind if you could explain to me why there'll be a conflict in the case of /8? I'm lacking in IT network education - I'm mostly involved in R&D radar electronics, so your input would help a lot.
Aha - figured out why the conflict in case of /8 ;D
I had it the wrong way around i.e. /8 = 2^8 = 256 addresses and /24 = 2^24 = 16M. I'm more used to the 255.0.0.0 format, which makes sense intuitively.
But in fact: /8 = 2^(32-8) = 16M and /24 = 2^(32-24) = 256.
I'll change all the netmasks /24 - and now I agree, it'll probably solve the problem. FreeBSD forums all say that the above error usually indicate a physical network error or conflict. So this makes perfect sense then.