I am experiencing similar issues as noted in this bug id: http://bugzilla.mindrot.org/show_bug.cgi?id=510 I am ssh'ing from a dchp'd address to a nat'd address (tried both hostname & ip). after a successful login, I launch an X app. Shortly thereafter I get: "Disconnecting: Corrupted MAC on input." I was not experiencing this problem w/3.7, but I cannot place full blame on 3.8, as it was working for a short while. So you're asking youself, "what's changed?" Well on both the client and server side, nothing.....on the network side....who knows, I have zero control over that. To the best of my knowledge they're using cisco all the way around. Not certain on model type. Below is a brief debug from the client side: hubdbx01:/ # debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 32849 debug1: fd 7 setting O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 Disconnecting: Corrupted MAC on input. debug1: Calling cleanup 0x8051b10(0x0) debug1: Calling cleanup 0x805aa30(0x0) debug1: channel_free: channel 0: client-session, nchannels 2 debug1: channel_free: channel 1: x11, nchannels 1 debug1: Calling cleanup 0x80628b0(0x0) =============================== Thanks, Ryan __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover
On Apr 28 07:32, Ryan Robertson wrote:> I am experiencing similar issues as noted in this bug > id: > http://bugzilla.mindrot.org/show_bug.cgi?id=510 > > I am ssh'ing from a dchp'd address to a nat'd address > (tried both hostname & ip). after a successful login, > I launch an X app. Shortly thereafter I get: > "Disconnecting: Corrupted MAC on input." > I was not experiencing this problem w/3.7, but I > cannot place full blame on 3.8, as it was working for > a short while. So you're asking youself, "what's > changed?" Well on both the client and server side, > nothing.....on the network side....who knows, I have > zero control over that. To the best of my knowledge > they're using cisco all the way around. Not certainSo are you running the Cisco client on your machine? Is you machine by any chance an SMP or hyperthreaded machine? I have made bad experiences with that combination and I have encountered the "Corrupted MAC on input" message a lot when running the Cisco client on an SMP box. It's definitely a bug in the Cisco client and it's weird that Cisco isn't able (or willing?) to fix that. Corinna -- Corinna Vinschen Cygwin Co-Project Leader Red Hat, Inc.
Ryan Robertson wrote:> I am experiencing similar issues as noted in this bug > id: > http://bugzilla.mindrot.org/show_bug.cgi?id=510 > > I am ssh'ing from a dchp'd address to a nat'd address > (tried both hostname & ip). after a successful login, > I launch an X app. Shortly thereafter I get: > "Disconnecting: Corrupted MAC on input."> I was not experiencing this problem w/3.7, but I > cannot place full blame on 3.8, as it was working for > a short while. So you're asking youself, "what's > changed?"Also "does the problem persist if you revert to 3.7 temporarily" and "does it occur with large file transfers with, eg scp or sftp"?> Well on both the client and server side, > nothing.....on the network side....who knows, I have > zero control over that. To the best of my knowledge > they're using cisco all the way around. Not certain > on model type. Below is a brief debug from the > client side:The can be caused by *any* changes to the data at any point between client and server. This includes network device drivers, network interfaces, memory, cabling, routers, switches... At each end, do you get problems doing transfers to localhost? Can you do a transfer with another protocol (netcat can be useful for this) then md5sum source and destination files and compare? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Are you by chance connecting via some kind of VPN software? I've seen VPN clients (and their servers) mung up MAC addresses by setting them to all zeros for the VPN adapter. It may be a setting change on the server to allow pseudo-macs to be assigned. - Larry
I was regularly seeing something similar back in July 2002. Here's the thread I started then, http://www.mindrot.org/pipermail/openssh-unix-dev/2002-July/014899.html I never did get a reasonable answer. I would see this with the server running under HP-UX 11.0 with OpenSSH 3.4p1. I have even seen it a few times since, up to 3.7.1, although it's not nearly as often. I had always suspected it had something to so with HP, since I could ssh into other linux boxes all day long without errors. When I did see it, it didn't seem very random. Doing certain things like starting a tunneled X client would immediately cause it to occur. Other times, the corrupted MAC would occur as soon as the session would start, even before I could get a shell prompt. At one point I started performing my own tests with lower and lower levels of debuging, almost to the point of capturing all the raw packet buffers just prior to encryption. I even inserted extra debug code so I could check every single step of the MAC computation and verification. I just could not explain what I saw, but it looked like a single byte was always getting changed. It was not a random pattern at all. If I recall correctly, I had ruled out the MAC computation itself. Also strangely the encrypted packets were identical. But somehow after decryption the plaintext buffers were different. I hope I'm recalling this correctly, but I think I am. Unfortunately it's so rare now (with the newer versions), that it would be very hard for me to redo those tests again. I can tell you the most frustrating part is that the entire SSH session is shut down on the first mismatched MAC. I always wished the protocol had a minimal amount of retry logic. Deron Meranda
I hope the experience I had with this problem could shed some light to the more knowledgable. I started having the "Corrupted MAC on input" since a few days ago. I do not know what the cause is, but from what I've read in this thread, it could be an ssh problem. I have not changed the configuration on my machine in any way. The only machine I have a problem with is a $ uname -a IRIX64 onyx 6.5 10151453 IP35 http://onyx.hucc.hokudai.ac.jp/cgi-bin/MachineInfo The computer I connect from is a Gentoo Linux, Single P4 3.0GHz HT, running SMP vanilla kenrel 2.6.6. The ssh client identifies itself as SSH-2.0-OpenSSH_3.8p1. The server side, I do not have much control over. The ssh daemon presents the following greeting: SSH-1.99-OpenSSH_3.6.1p2 I get these Corrupted MAC errors very, very often now (I had never seen one until a few days ago). The easiest way to cause them is to start vi and start going up and down in a text file. These errors occur with SSHv2 conections only. If I connect with ssh -1 there is no problem, regardless if I turn on compression to level 9. After reading the comment about a possible problem with compression, I tried running "find /" to see if this will cause a Corrupted MAC, but it worked fine. I seem to have problems only when at input (never on output). The error always interrupts me in the middle of whatever it is I am typing. Speed doesn't seem to be an issue. I copied a 11MB file using scp *from* that server, without a problem: $ scp onyx:mpich.tar.gz dump However, copying the same file *to* the server fails almost immediately: $ scp dump onyx: I also captured a complete ssh session using tcpdump. Replaying it with tcpdump -r shows only 74 frames (the dumped file is 7249 bytes). I could post it if anyone thinks it can help. I captured the failing scp session as well. The quicker of the two captures contains only 30 frames. I would like to know your opinion about what the cause of the problem is. Please make sure you CC: any replies as I am not a subscriber. -- / Georgi Georgiev / BOFH Excuse #343: The ATM board has run out / \ chutz at gg3.net \ of 10 pound notes. We are having a whip \ / +81(90)6266-1163 / round to refill it, care to contribute ? /