Hardware checksum offloading interface bug

[jc1976]

i brought this up once before way back but it seems like there's no clear answer and nothing was done, so i'll bring it up again.

under "System/advanced/networking" -> Network interfaces, the top option is Hardware Checksum Offloading.

i use suricata inline and i 'check the box' to disable the feature (my nic is an intel i350-t2v2).

i reboot..

under "system tunables", there's a 'tunable' called "net.inet.tcp.tso" with the description of "Enable TCP Segmentation Offload". by default it is set to '1'. in the documentation it says that this should be set to '0' to disable it.

so, i disable it in the gui, do the reboot, and when i come back up, despite the gui portion listed above labeled as 'disabled', the tunables section has it listed as enabled '1'. so i have to manually set it to '0' and reboot again.

or is this all backwards? freebsd docs say '1' to enable offloading, '0' to disable offloading.

[johnpoz]

@jc1976 so there is a diffence between checksum offloading and actual segmentation offload..

login-to-view

[jc1976]

@johnpoz

I thought of them as both one and the same, so correct me if i'm wrong.
I'll have to dig up the tuning example online, i believe it comes straight from the freebsd tuning documentation.

[johnpoz]

@jc1976 also those things can be enabled/disabled with ifconfig

https://man.freebsd.org/cgi/man.cgi?ifconfig

So those can override what is set in tunables, as lest from a standpoint of disabling them via the checkmarks..

You can just look at your interface with ifconfig to know what is enabled or disabled.

[23.09.1-RELEASE][admin@sg4860.local.lan]/root: ifconfig
igb0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: LAN
        options=4e100bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether 00:08:a2:0c:e6:24
        inet 192.168.9.253 netmask 0xffffff00 broadcast 192.168.9.255

Notice the csum are enabled, but you don't see any TSO or LRO on mine..

So its possible that what you see in your tunables does not come into play..

[jc1976]

@johnpoz

i've never had a problem with it. up until i found that tunable setting i just checked (disable) (which is pretty unorthodox.. back in the old days of engineering, we always had '1' or a 'check' to signify enabled, while '0' or unchecked meant disabled, but i digress..

but once i saw that tunable and read the advice from the bsd tuning docs, i set it to '0' as well.

[SteveITS]

@jc1976 said in Hardware checksum offloading interface bug:

back in the old days of engineering, we always had '1' or a 'check' to signify enabled, while '0' or unchecked meant disabled

Yes...there was a thread about that a few years back I think. In pfSense some of the checkboxes are check to disable but it's inconsistent, even on that page, and I suspect after all this time it would be confusing to veteran pfSense users to flip half of them to unchecked-to-disable in an update.

[stephenw10]

Mmm, unfortunately there are a lot of legacy settings in pfSense that would not be implemented that way if done today. But changing them now is likely to cause more problems than it would solve.

[jc1976]

@stephenw10

i'm familiar with it all enough now so that i can get around it...

as long as they don't start changing things just for the sake of changing things such that things that once worked properly/perfectly are now broken.. feels like thats going on with 2.7.1 & 2.7.2