Hmm ... sorry ... here was my problem. Today I used a custom kernel config file (created with dmassage). The corrupted MAC on input appeared after using the custom kernel.
Dmassage used only the following crypto entry: # crypto support hifn* at pci? # Hi/fn 7751 crypto card After re-adding "all" the Hi/fn cards, the corrupted MAC on input disappeared: (by default, these entries are in GENERIC) # crypto support hifn* at pci? # Hi/fn 7751 crypto card lofn* at pci? # Hi/fn 6500 crypto card nofn* at pci? # Hi/fn 7814/7851/7854 crypto card ----- Original Message ----- From: Didier Wiroth Date: Thursday, June 1, 2006 21:20 Subject: Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem]) To: Breen Ouellette Cc: misc@openbsd.org > Hello, > > Hmm .... I get the "corrupted mac" error again on current, while > connecting to the net4801 with windows + putty. > > Connecting with openbsd ssh client does not produce the error, I > only get it with latest > windows and putty client .... > > Is anyone else able to test: > a) with a windows client + putty > b) to a connect via ssh to a soekris 4801 running current + mini > pci soekris vpn 1401 > c) do you get the corrupted mac on input errors? > > thx a lot > didier > > ----- Original Message ----- > From: Breen Ouellette > Date: Wednesday, May 31, 2006 23:17 > Subject: vpn1411 problem related to software error? (was Re: > [Fwd: 'Corrupted MAC on input' points to vpn1411 problem]) > To: misc@openbsd.org > > > Didier Wiroth wrote: > > > I run the test for almost 20 minutes, there was no problem > anymore!> > Regards > > > Didier > > > > > Thank you for your report. > > > > Here's where I stick my head out farther than I probably should > > and hope > > it doesn't get taken off. > > > > I checked the hifn code to see if it had changed since 3.9 > > Release. It > > hasn't. I took a look at the list of includes and noticed that > > several > > files have changed since 3.9 Release. Not being skilled enough > > to know > > if this is the right train of thought, I have to ask: is it > > possible > > that something was changed before 3.9 Release which broke hifn, > > and was > > later (lately) adjusted back to a state which works with hifn? > > If so, if > > the cause is not identified now is there a possibility that hifn > > could > > be broken again in the future? > > > > The reason I ask is that hifn has a somewhat muddy history of > > breakage > > which has often been blamed on hardware. Is the hardware junk or > > is the > > problem hard to nail down? Or is this a combination of both - is > > the > > previous evidence of junk hardware + hifn problems resulting in > > a knee > > jerk reaction of blaming the hardware by default? > > > > Also relevant for mere users like myself (ie not qualified to > > fix this > > problem), should we just downgrade to an earlier release or > > upgrade to > > current, or is this the sort of thing that would get patched if > > a > > problem was indeed identified? > > > > Thanks. > > > > Breeno
