Kernel: arpresolve: can't allocate llinfo for… PF on Intel NICs + SB6141 modem
It seems like everyone else who has this problem can fix it by disallowing pfsense from taking a local IP from the modem. (Reject leases from 192.168.100.1) That isn't working for me…
Here's what I get in my system logs:
kernel: arpresolve: can't allocate llinfo for 126.96.36.199 on em3
kernel: arpresolve: can't allocate llinfo for 192.168.100.1 on em3
This basically tells me regardless of if the modem has a stable connection to it's gateway, there's still something wrong with my router. I've also tried a few of the other suggestions like:
ifconfig em3 down ; ifconfig em3 up
I've also built a script that would search the logs for that line appearing within the last few seconds and run the ifconfig down/up automatically. I've gone as far as automating a reboot but now all I have is a box that reboots way too often. It doesn't always fix the issue. What else can I try?
Supermicro 1U Atom D525 dual core w/ HT 1.8GHz
4GB ram 60GB SATA SSD
4X Intel(R) PRO/1000 Network Connection 7.4.2 (Two onboard two on PCI-e)
Contents of /boot/loader.conf.local:
Modem is Motorola SB6141
It should good signal strength but once in a while I get the following error on it:
No Ranging Response received - T3 time-out;CM-MAC=<my modem's="" mac="">;CMTS-MAC=<comcast head-end="" mac="">;CM-QOS=1.1;CM-VER=3.0;
I don't know if it's related.</comcast></my>
If you reject leases from 192.168.100.0/24, that should prevent it from obtaining such a lease.
But ultimately you're trying to fix the symptom, not the problem. Modems start handing out 192.168 IPs only when they lose connection to your ISP. That's the root problem, and nothing you do firewall-side is going to fix that. Rejecting those private leases should make it a less noticeable problem, in that you won't have a bunk DHCP lease to get rid of, but you're still losing connectivity.
This issue has been bothering me for a while. The issue is not that connectivity drops, it's that that it doesn't come back until there's some manual intervention. It's 10:00 and my pfSense log is full of arpresolve: can't allocate llinfo messages. According to the modem log the connection was down between 1:30 and 2:00. Until I hit release/renew on the Status > Interface pages pfSense didn't re-establish the connection.
I was having a very similar problem.
I searched and tried a whole lot of different solutions but the only thing that worked was wiping the box and starting over with a fresh install. Over the coarse of a week I slowly reconfigured everything back to mirror my existing setup (except for two packages, more on that below) and I am happy to say that I haven't had the problem since. My setup was moderately complex (VPN Clients, SNORT, pfBlockerNG, FreeRadius2, Traffic Shaping)
The only thing that I did not setup in the fresh system that was was pfBlockerNG and FreeRadius2. I no longer needed FreeRadius and by the time I had reconfigured the system I was burned out and just put off pfBlockerNG for another time.
I am curious to know
- Do you or have you in the past had any networks/vlans on 192.168.100.0
- Do you or have you in the past had any static routes setup for 192.168.100.0
- Do you or have you in the past had pfBlockerNG installed
- Do you or have you in the past had any networks/vlans on 192.168.100.0 No
- Do you or have you in the past had any static routes setup for 192.168.100.0 Maybe I had a firewall rule at one point, but not at the moment.
- Do you or have you in the past had pfBlockerNG installed. Yes, currently installed
I'm not sure how 192.168.100.0 is relevant because with and without pfsense configured to reject those DHCP leases the WAN issue is the same.