jared r r spiegel wrote:
On Mon, May 29, 2006 at 10:01:21PM -0600, Breen Ouellette wrote:
A few months ago, Didier Wiroth posted to this list that his net4801 with
a vpn1411 was giving him 'Corrupted MAC on input' errors. He was looking
for a solution to this problem.

  i think i chimed in on that one.

  since i put may.1st snapshots on my 4801, it has not happened at all.

  this was the same situation for me as before; i started to see the
  'corrupted MAC on input' after one snapshot, and then a few snapshots
  later, it went away entirely.  this last time, it showed up after
a december-ish snapshot (iirc, whatever i had in my last post about it ...), and since may.1 snapshot, it is entirely non-present


Just so you are aware, this problem is not necessarily limited to OpenBSD. A NetBSD user stated on the Soekris tech list that he had seen the error a couple of times, but he no longer has a net4801/vpn1411 combination to test the script against. As well, a FreeBSD user reported the same trouble in a different thread. The problem is that this error is sporadic enough that no one appears to have confirmed the cause so that the responsible party(ies) may be notified. Since many types of hardware error can be responsible for similar behaviour it has been too easy to blame it on a ghost in the system. However, I started out with just a net4801, which I used for more than a year before getting the vpn1411. During that year my box ran flawlessly, so when the errors cropped up after installing the vpn1411 I was in the relatively unique position of knowing that the net4801 was fine, while most people seem to buy the set, experience errors, get told it is a hardware problem (bad RAM, bad NIC, bad network device), and take it at face value. It still could be a hardware problem, but it is not the only possibility and I would like clear evidence before I blame the card.

The fact that I have only seen this reported on BSD systems could be an indication that there is a problem with the Hifn driver _IF_ they all share a common code base. Having a quick look at the source code on the web indicates to me that several sources have been used to create the Hifn driver. Perhaps a developer can enlighten us about whether or not there is a shared code base (or cooperation) between projects.

I have seen my script run for several minutes before glitching out, so if you have the time to run it for a solid 10 minutes using SSH2/AES it will go a long way to confirming that you haven't just been lucky to avoid the error since you began using the May 1st snapshot. I've personally used several SSH2/AES sessions for regular use for more than 30 minutes in the last week without experiencing an error (yet at other times it has failed within a minute of regular use). It seems rather unlikely (although not impossible) that the OpenBSD developers would regress the code to a breakable state and then fix it again, so my money would be on your being lucky the last few weeks and that most people sluff this off as a problem with hardware. In fact, the WebCVS shows that the last change to the Hifn driver was 4 months ago, which would indicate that for the May 1st snapshot to fix this problem the error would have to exist outside of the driver itself, lending more credibility to the hypothesis that you still have a problem but you just haven't experienced it.

Thanks for your post. I hope you take it one step further and run that script (and then report your result to this list)! :)

Breeno

Reply via email to