realtek-re-kmod missing in pfSense 2.6 repository?

Knight

This post is deleted!

Knight

This post is deleted!

stephenw10

Yes, that is what happens because the FreeBSD ABI version is different. However when you switch back to 2.7 it should change back to 14.
You should see the repo pkg upgrade or downgrade in the logs when you do.

However I can't replicate that currently. In fact there seems to b exactly the opposite problem; the stable ABI is not updated to 12 so i cannot update from it. Looking at that now.

Steve

Knight

This post is deleted!

skogs

Please keep this thread on topic. People click this topic specifically for realtek issues caused by years of neglect. Realtek hardware exists and works fine mostly everywhere...we just need to do manual foo to fix it here.

Normally I'm not one to complain, but we're talking about upgrades, downgrades, and complaints about posts being spam...

--please don't reply to this; just go about your day--

w0w

I can confirm that netmap is not working correctly with these drivers in pfSense, so do not try to use the inline mode for suricata or snort. It will crash shortly after setting applied or after reboot.
P.S.
I've tried builds based on Freebsd 12 only and at least 3 different realtek cards, if you have any luck with other version or hardware, please let us know.

MxcZXAKM

@w0w for the record I had the same issue with inline & legacy, made no difference.

w0w

@mxczxakm for the record, I have crash and kernel dump on all three variants and your problem looks different for me. Create a new topic and post there as much information as you can.

bepa888

realtek-re-kmod version 197.00 for pfSense 2.6 / FreeBSD 12 is out:

fetch -v https://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/realtek-re-kmod-197.00.pkg

pkg install -f -y realtek-re-kmod-197.00.pkg

My box's WAN and LAN interfaces periodically flapped with the older v196.04. I hope the latest Realtek driver version 197.00 is more stable.

w0w

@bepa888
I've been using it for a week and haven't noticed a difference.

MxcZXAKM

I’ve been running with the new driver and suricata in legacy without an issue for today anyways.

RK0

I decided to upgrade earlier today...it went without a hitch. Running 2.6 with two Realtek ethernet controllers, a RTL8111K and a RTL8111H in a Lenovo ThinkCentre M90n IoT dual NIC system.

MxcZXAKM

Eventually it started dropping my wireguard connection on/off and eventually it locked up the LAN so i couldn’t log in. I went back to no Suricata which still works just fine.

w0w

@mxczxakm
It seems to me that there are several problems mixed in here, some sort of defective or incompatible hardware is mixed with incomplete/missed suricata settings.

MxcZXAKM

@w0w said in realtek-re-kmod missing in pfSense 2.6 repository?:

@mxczxakm
It seems to me that there are several problems mixed in here, some sort of defective or incompatible hardware is mixed with incomplete/missed suricata settings.

Ok, thanks, I’ll keep digging. I think I’m going to move away from this Zima board again, too underpowered.

MxcZXAKM

The issue is still the Realtek NICs. I found an article exactly to my board & issue. He ended up switching to an Intel NIC via PCIe to fix this issue in the end.

https://www.martinrowan.co.uk/2022/05/installing-pfsense-2-6-on-zimaboard/

alt text

Also of note:
https://forums.serverbuilds.net/t/demystifying-intel-pro-1000-quad-port-nics/2401

w0w

@mxczxakm
https://be-virtual.net/pfsense-arpresolve-cant-allocate-llinfo-for-x-x-x-x-on-emx/
Example of similar issues on Intel em driver...and realtek also...
There are two, at least, different solutions provided, one is to disable ARP daemon, whatever it means, and the second is to use dumb switch on this port, which is getting those messages like cant-allocate-llinfo what ever...

MxcZXAKM

@w0w thanks, his solution seemed to just be setting a static ARP/MAC for his connected rotating server. I have a direct pipe to the WAN on mine, simple home setup.

stephenw10

Usually seeing that message indicates pfSense no longer has an interface with an IP address in the same subnet as the indicate IP so it cannot ARP for it. So usually it's the gateway address on a dynamic connection and the interface has lost it's lease or similar.
Adding a static ARP entry there prevents it trying so you don't see that error but doesn't actually allow it to function in that circumstance. Usually those errors are only while a WAN reconnects.

Steve

MxcZXAKM

@stephenw10 maybe setting the default gateway to WAN instead of automatic would help but in my case I can’t because of the VPN connection.