Call for testing: New netmap enabled kernel

[donatom3]

So far 3 days on the new netmap kernel and I haven't had an issue. 3 interfaces two of them are vlans on i350s. Before this I was having a lockup that killed connections to the interfaces that sensei was monitoring that required a complete reboot to get connectivity back.

[mb]

donatom3, that's great to hear. Thanks for sharing your results.

[oneplane]

Any interest in reports on doing this on AWS EC2? I have a few self-bootstrapped OPNSense setups there that work fine. I can just snapshot and try the kernel to see how that turns out.

[mb]

oneplane, definitely. Thanks for raising this.

We want both OPNsense + Suricata and Sensei to be able to work on all cloud providers including AWS. What's your experience up until now?

[Redfish]

mb, reverted to stock kernel and suricata is working as intended.  Please let me know if there's anything I can do to help with your investigations.

[mb]

@redfish, any chances doing a few more tests for me? This might isolate the situation a bit more. You can send the results through a private message.

First download nmbridge application.

# fetch https://updates.sunnyvalley.io/nmbridge/nmbridge
# chmod +x nmbridge

This is a very minimal application which does bridging. It's based on netmap. I'd like to see if this also produces the same result:

With the new kernel, try to see if this command produces the same message. Replace ix0 to suit your interface naming. Do this also for the other network interfaces installed on the host.

# ./nmbridge -i netmap:ix0 -i netmap:ix0^

When you run the application make sure to see packets are flowing and your network connectivity is intact for that specific interface.

[TheGrandWazoo]

Good day,

I have had NO issues with Suricata IPS in a HA environment using VIRTIO interfaces. I have been running HAProxy environments, SBC (VoIP) environments (A plugin I am working on) and regular firewall environments. Thank you very much!!!!
With that being said 19.1.2 is now out and it has an "OS" update associated with it. Does this 19.1.2 update include this patch set? If not, is there a new kernel that we need to perform the 'opnsense-update'?

Thanks again,
Kev

[franco]

Hi Kev,

There is no refreshed netmap rework kernel yet. If you want to keep it lock the kernel package from system: firmware: packages tab and perform the update as usual.

Look for the release notes, we'll announce the netmap rework there...


Cheers,
Franco

[TheGrandWazoo]

Hi Kev,

There is no refreshed netmap rework kernel yet. If you want to keep it lock the kernel package from system: firmware: packages tab and perform the update as usual.

Look for the release notes, we'll announce the netmap rework there...


Cheers,
Franco

Franco,

Thanks for the info. That is what I thought I should do but never hurts to ask. Everything updated without issues.

Thanks again,

Kev

[franco]

There's a new netmap test kernel out there:

# uname -a
FreeBSD sensey.homeoffice.local 11.2-RELEASE-p9-HBSD FreeBSD 11.2-RELEASE-p9-HBSD  4ea457eb7b8(master)  amd64

To upgrade use:

# opnsense-update -fbkr 19.1.4-netmap
# opnsense-shell reboot

To revert back to the 19.1.4 default kernel:

# opnsense-update -bkf

The old test sets for 19.1-netmap will be removed from the mirrors now. Changes in the new version include:

o netmap: fix crash with monitors and VALE ports
o ixl: remove unnecessary limitations related to netmap
o netmap: small cleanup on em, lem, igb, ixgbe
o netmap: fix knote() argument to match the mutex state
o netmap: improvements to the netmap kloop (CSB mode)
o netmap: add notifications on kloop stop
o netmap: upgrade sync-kloop support
o netmap: refactor logging macros and pipes
o vmx(4): add native netmap support
o netmap: fix lock order reversal related to kqueue usage
o netmap: remove redundant call to nm_set_native_flags()
o all fixes of the 19.1.2 and 19.1.4 operating system updates


Cheers,
Franco

[datiscum]

After installing the new netmap-kernel, the Intel network card was no longer found. I ran OPNSense under KVM and passed 2 ports of a hardware Intel card into the VM. The third E1000 is a KVM emulated card. With the new kernel only the virtual card is found. Is there a solution for this ?
Standard kernel: pciconf -l
em0@pci0:3:0:0: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00
em1@pci0:4:0:0: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00

em2@pci0:8:1:0: class=0x020000 card=0x11001af4 chip=0x100e8086 rev=0x03 hdr=0x00

netmap kernel:
em0@pci0:8:1:0: class=0x020000 card=0x11001af4 chip=0x100e8086 rev=0x03 hdr=0x00

Thank you. I'll take care of it,
  Sasha

[franco]

Hi Sasha,

This is very odd as the patches are not supposed to do this.

Is this the case with a normal 19.1.4 as well?


Cheers,
Franco

[datiscum]

Hello,

In 19.1.4 with the default kernel everything is OK

[franco]

Strange, I went through the commits and saw nothing out of the ordinary. Compared to 19.1-netmap kernel was it the same or working there? I know this might sound strange but what happens if you reinstall 19.1.4-netmap?


Cheers,
Franco

[datiscum]

I've done that before, but it's always been the same result.

I don't have much experience with FreeBSD, I usually only use Linux and Windows. I would have liked to use the VirtIO network driver under KVM Q35. This works under the standard kernel only with the i440FX chipset from KVM. If anyone has an idea, I would like to try it out.