Corrupted MAC on input

core

Hi everyone,

while pfSense is working greatly (thanks for this piece of software by the way!), I experience another problem with ssh connections. If I try to scp a file to the pfSense box, the connection is severed with the message

Received disconnect from [pfSense IP]: 2: Corrupted MAC on input.

This happens only if the file size is a few MBytes. I can split larger files, copy the chunks over and reassemble them, but that's a bit cumbersome :-) As the default ssh connection works I tried to pipe some data through here, but the problem also shows up. The network adapter is an Intel PRO/1000 MT Dual Port Server Adapter. Are there any known compatibility problems with this one?

I would have suspected a hardware failure of the NIC, but the curious thing is that all connections passing over the pfSense box are working just fine. Maybe a problem with the OpenSSL version that pfSense is using? I tried different hashing options, but this did not change a thing.

Maybe related to this is that the update function is not working, if I specify the URL to the package on the console. The download everytime fails with a wrong md5 checksum, which is different for each try.

Any hints on this one? Help is greatly appreciated.

Best regards
Chris

Perry

With an issue like this, the things i would do
Update bios to latest and greatest
Reinstall pfSense with the latest and greatest version ( 1.2rc2 atm )
Then try with a default install to confirm that the problem still occur .

core

Thanks for your reply, Perry. Both machine and NIC are brand new with no new BIOS versions available yet. I'm running RC1 right now, so RC2 would be definitely worth a try.

However, I moved the interfaces from the Intel NIC (on a riser card) to the onboard NIC – and everything works like a charm. Must be a hardware problem then, the Intel NIC itself is listed as supported.

Perry

Shared IRQ could also cause strange things, so check that too and disable what you can in bios.

http://forum.pfsense.org/index.php/topic,1623.0.html

core

Thanks for the pointer. I'm going to check that this evening (allthough it seems that the interrupts for the NICs are all unique), go for a RC2 update and let you know what happens.

core

Hardware Checksum Offloading was the culprit. I had tried the option in the webinterface before, but did not check its effects. At least for my Intel card, the switch does nothing. Only a

ifconfig em0/1 -txcsum -rxcsum

solves the problem (or so it seems after 30 minutes of testing). Deactivating the offloading does not seem to pose a too heavy load on the system, so I think I'll go with the Intel adapter without offloading instead of the onboard NIC.

What is the recommended way for pfSense to execute this command at startup? I've modified /etc/inc/pfsense-utils.inc and included the part

if($config['system']['disablechecksumoffloading'])
{
mwexec("/sbin/ifconfig {$interface} -txcsum 2>/dev/null");
mwexec("/sbin/ifconfig {$interface} -rxcsum 2>/dev/null");
return;
}

which does the trick for me after a restart. Probably other adapters do not activate this option automatically, but with the Intel deactivating explicitly is necessary.

I hope no one takes offence at my dilettantish fix :-D

sullrich

Did you set $config['system']['disablechecksumoffloading'] in config.xml?

Ie:

core

yes, I did (using the web interface): <disablechecksumoffloading>yes</disablechecksumoffloading>

For my system it seems that the options doesn't have to be explicitly activated (as the original code does), but deactivated (what the code did not). At least this was my observation, ymmv of course :)