Yeah that would have helped! Tested on a Win10 machine and can't get it to show in device manager there either. Maybe to have a look for a different device.

Thanks for the reply though.

Yup.

This list is very useful when looking for NICs: https://forums.servethehome.com/index.php?threads/list-of-nics-and-their-equivalent-oem-parts.20974/

Steve

Just wondering, maybe "bypassing" pfSense as the main OS could solve the problem. Could you try to install ESXi on the host and see if all network interfaces are detected correctly? Just a thought

Indeed, see: https://www.netgate.com/blog/pfsense-2-5-0-development-snapshots-now-available.html

@fireodo

You welcome 😉

@NRgia said in Netmap not supported for Intel X553 driver in pfSense 2.5.0:

@trumee said in Netmap not supported for Intel X553 driver in pfSense 2.5.0:

I have a Supermicro motherboard 'A2SDi-4C-HLN4F' which uses X553 chipset. It is presently running Stable 2.4.5-p1 and Snort. Is this release affected by this issue?

My tests didn't include testing Snort on Stable 2.4.5. I was asked to install Snort on 2.5.0-devel by another user, to compare Snort vs Suricata, in the matter of speed and it was a little lower for me when I tested with Snort.

After some discussions with the guys that maintain Netmap, Intel drivers, Supermicro support, FreeBSD, I was directed to Suricata maintainers.

I took my time and tried various tutorials that optimize some networking parameters, but I got only small variances in performance like 30-40 Mbps.

My last try will be to have a chat with Suricata guys.
I hope they will not recommend me a Napatech card
Napatech products link , or something.
I will update if I find something of interest.

One issue that is likely at play with both Suricata and Snort (Snort on FreeBSD-11.x) is that on FreeBSD the netmap host stack originally exposed only a single ring. NIC drivers, on the other hand, pretty much uniformly expose multiple rings. The more rings you have, the higher the theoretical throughput can be.

The latest iteration of netmap on FreeBSD finally offers a multiple ring interface for the host stack. The host stack is the connection to the kernel itself. Most of the original implementations of netmap envisoned sending packets between two NIC interfaces directly (that is, without necessarily going through the kernel network stack). So to put this in Suricata terms, think of using two physical NICs and having Suricata sit between them policing traffic between the two NICs. In that scenario all rings available in the NIC drivers would be used.

But Suricata on pfSense needs to interract with the kernel network stack because we want to inspect traffic as it flows to and from the NIC to the pf firewall engine in the kernel. Also, we don't want to use up two valuable hardware NIC ports just to have an "in" and an "out" path. We want to use a single NIC for an interface.

Starting with FreeBSD-12 and the move to the iflib networking API, netmap now exposes a multi-ring netmap interface for the host stack. However, for the moment I don't believe Suricata 5.x is using that interface in order to maintain backwards compatibility with older netmap API versions.

I would expect that CPU to pass that easily, though I have never tested that particular hardware myself.

Steve

Thanks, I'm still learning.

Use the SG-3100 and the new device in a lab playground.
I think is the best solution.

I figured out after a couple of days why it was not working. I think not really documented clearly, how it's supposed to work, at least I didn't find out: info are scattered around in the APC forum discussions and the some of the docs.
First of all, for the PCNET type, it uses pass/auth phrase instead of password and that needs to defined in the NMC web-gui, which is placed in rather odd-place: under Configuration > Shutdown:

6fdbe869-42bd-4a69-94d5-8cd0b80dbd02-image.png

re. https://www.se.com/uk/en/faqs/FA159659/

That user (e.g. netman, which I setup as a network-only user) must be created first. PCNS uses both the password & pass-phrase for that user and APCUPSD uses only the pass-phrase. After that both started working. Hope it will help others, if get stuck the same way I was.

-S

Hmm, well you could try a pcap on the bridge interface but the fact it's showing output errors implies it's unable to send so you may not see those packets.

You could try reducing the cache time in the bridge advanced settings. Though this is something much shorter than that.

Steve

@stephenw10 this can be marked as solved

Hi Stephen just a Update. Problem has been solved by doing a fresh install then a restore from backup file. Speed on the VLANs is also fixed and no more dropouts.

Actually I'm getting better speeds than I ever did switching to this new hardware from a H81 system. Pays to have proper Server hardware.

Cheers.

Jack.

@TheSmoker Just standard fans with a shroud to ensure air is optimally dragged through the heatsink etc. I dont have a picture of the shroud but its listed on super micros site.

5019.png

@Tryano95

You welcome

now in 2.5:
https://redmine.pfsense.org/issues/9155#note-7

Got it going, in case anyone is interested, follow the outbound NAT rules created in this thread:

https://forum.netgate.com/topic/151649/pfsense-and-meraki-z3/47

It can certainly be as stable, sometimes more so. The hardware presented by a hypervisor to pfSense is very generic and usually well tested. No exotic driver controllers etc!
There are advantages to running as a VM. Take a snapshot before an update (or any change) to reduce the risk to close to zero.

There are disadvantages. Is it secure? It's easy to misconfigure something and end up connecting it outside the firewall.
What happens if you have to reboot the hypervisor? Are you in a chicken and egg situation where the hypervisor needs pfSense to be running?

Those are things to be aware of. Test it and make sure the hypervisor can reboot. There are lots of people running virtualised.

Steve

Driver for this card is implemented in sys/dev/ixl/if_ixl.c and I see several improvements this year.

We have a review of similar AS -1014S-WTRT in the FreeBSD hardware database.