Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
Breen Ouellette wrote: I am still going to install 3.9 on a PC and try an ssh connection which doesn't involve WinXP / PuTTY. I finally got around to it and I still get the error when connecting from a PC installed with OpenBSD 3.9 to my net4801 / vpn1411 running OpenBSD 3.9. So, just in case someone came across this thread and thought that PuTTY was the cause of the problem, it definitely is not, you can thank Hifn for this one. Breeno
Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
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
Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
Didier Wiroth wrote: 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? I knew it was going to happen. :) I will set up a PC with OpenBSD 3.9 Release and follow up with the latest snapshot and try making some connections that don't involve PuTTY. I'll get my results back by tomorrow. Breeno
Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
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
Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
On Thu, Jun 01, 2006 at 02:32:22PM -0600, Breen Ouellette wrote: Didier Wiroth wrote: 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? I knew it was going to happen. :) I will set up a PC with OpenBSD 3.9 Release and follow up with the latest snapshot and try making some connections that don't involve PuTTY. I'll get my results back by tomorrow. i am not seeing any hifn interrupts ( systat vmstat ) while sshed from a windows host (xp/98) using putty (2006-06-02:r6271 or 2005-11-03:r6444) and the 'AES (SSH-2 only)' encryption policy. spuriously, i *am* getting hifn interrupts when i ssh from the win98 host using a 2002-06-05 development snapshot of putty. 3des, however, the hifn is clearly taking interrupts regardless of putty revision can't duplicate corrupted MAC in any of the above, however -- jared [ openbsd 3.9-current GENERIC ( may 1 ) // i386 ]
Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
Didier Wiroth wrote: Sorry ;-) I've reposted a new message a few minutes later ... May I ask you a question, do you use a custom kernel on your soekris box? - Original Message - From: Breen Ouellette Date: Thursday, June 1, 2006 22:43 Subject: Re: vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem]) To: misc@openbsd.org No, I do not use a custom kernel, and I haven't tried a custom kernel for at least five years (I caved in to the undeniable truth that Theo knows far better than I do on matters pertaining to OpenBSD). I've got a 2.5 Seagate hard drive (got sick of CF read limitations), I do a full install every release, and I try to stick to the base install as closely as possible (the only package I add is apg). Now I am just plain confused! I am still going to install 3.9 on a PC and try an ssh connection which doesn't involve WinXP / PuTTY. Breeno PS - Just in case someone figures I have a heat problem due to the hard disk: I run open top. CPU is 55 degC and HD is 34 degC. I am even modifying my case this week to add a chipset heatsink on the CPU and an 80mm Vantec Stealth to cool the case. I'll run my tests again when these mods are complete.
vpn1411 problem related to software error? (was Re: [Fwd: 'Corrupted MAC on input' points to vpn1411 problem])
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
