Messages

For those, who are interested, but not following the GitHub issue:

I installed the patched kernel, rebooted, changed MTU to 9000 and performed a ping test again. Initially, results looked great, ping was working with a payload size of 8192 bytes. But after some more experiments, the OPNsense crashed and rebooted. Since the box was rock solid before, I assume that the crash is related to the large MTU.

Therefore, for the time being, I reverted the MTU to 1500 bytes.

Yes, that is great news. I will give the patched kernel a try in the next couple of days.

I am running OPNsense Business 25.4. I assume that the patched kernel version (which obviously refers to 25.1) should not create any hiccups because of different OPNsense versions, right?

Thanks for your definitive validation of the hardware capabilities @patient0. Since I only have access to one device, which is in active use as a firewall, I can't do such experiments.

I opened an issue with OPNsense (although the driver obviously is part of FreeBSD): https://github.com/opnsense/src/issues/251

Thanks for the quick answer. I did some research, and it seems that the AMD Ryzen V1500B is used in a couple of NAS devices from Synology and QNAP, which support 10GBit interfaces with jumbo frames of at least 9000 bytes. I could not find a test with an explicit test of the jumbo frame functionality (i.e. using a ping with appropriate packet sizes), but some people were using jumbo frames with 9000 bytes. At least with Synology, I trust that if one can configure 9000 bytes jumbo frames, then this will also work.

So to me, it currently looks like a driver issue. You have a good point with the possibility, that chaining multiple buffers could be a solution if the hardware supports it. I try to do some comparisons between the current Linux and FreeBSD code. If I understand it correctly, the FreeBSD code was ported over from Linux, so both versions should be comparable to some extent.

I know this is a pretty old topic, but I'd like to follow up on that topic. I have a DEC2752 firewall since last year, and I was experiencing the same issues with enabling jumbo frames on the 10GBit AMD network ports. I did some investigation on the internet, but could not find a solution. Then I started looking into the source code of the driver, and I believe that's were the cuplprit is to be found:

https://cgit.freebsd.org/src/tree/sys/dev/axgbe/xgbe-drv.c?id=f341e9bad3eb7438fe3ac5cff2e58df50f1a28e4#n129

Code Select Expand

int
xgbe_calc_rx_buf_size(struct ifnet *netdev, unsigned int mtu)
{
unsigned int rx_buf_size;

if (mtu > XGMAC_JUMBO_PACKET_MTU)
return (-EINVAL);

rx_buf_size = mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN;
rx_buf_size = min(max(rx_buf_size, XGBE_RX_MIN_BUF_SIZE), PAGE_SIZE);
rx_buf_size = (rx_buf_size + XGBE_RX_BUF_ALIGN - 1) &
    ~(XGBE_RX_BUF_ALIGN - 1);

return (rx_buf_size);
}

From my understanding, this function is used to calculate the buffer size for the receive buffer. The following line will actually limit the size of the receive buffer to the systems page size (which probably is 4k):

Code Select Expand

rx_buf_size = min(max(rx_buf_size, XGBE_RX_MIN_BUF_SIZE), PAGE_SIZE);

Now my question is, how to proceed from here? Should I open an issue with FreeBSD? Or would maybe someone Opnsense developer feel knowledgeable enough if that can be easily fixed. I am not a driver developer, and I suspect that it is not enough to remove the min(..., PAGE_SIZE), since I imagine that a continguous set of pages would need to be allocated for the hardware to transfer the data via DATA to the correct address.

Thanks for all your replies :) And thanks for creating a GitHub for adding a check and/or clarifying in the documentation.

Hi,

I have upgraded to the 25.4 business edition recently. One of the new features is the ability to perform a multi-selection for the source and destinations in the filter rules. I found that the logic is not working when the selection is inverted via the checkboxes "Source / Invert" or "Destination / Invert". At least, it is not working to my expectations.

For example, I have defined two network aliases a1 and a2. When I select both of them as the destination in a "allow" firewall rule, and also turn on "Destination / Invert", I would expect that traffic to both network aliases a1 and a2 will be blocked (assuming there is no other rule allowing the traffic). But this is not the case, only the traffic to one of the two networks seems to be blocked.

As a workaround, I simply created a new network group a3 containing both a1 and a2, and used that single group a3 instead of the multiple selection a1 and a2. This works as expected.

I think I remember having read that there was a limitation at a different place with inverting a selection or a range, but I cannot remember.

Is this behaviour of inverting a multiple selection a bug? Or is it working differently from my expectations?