On Fri, 22 Nov 2019 at 22:08, [email protected] <[email protected]> wrote: [...] > My test-setup today was: > A real (BSD-)PC with 6.6 and my try to copy resulted in the same error.
so real hardware copying over the same network path to the same destination has the same problem. > Then I went to our outpost and connected this PC on the same switch as > the firewall and copied over 30 times without any error. so a direct connection between source and destination worked OK. > A copy from our controller (6.6) to the second PC failed, too. so copying from the original source over the same network path to a new destination has the same problem. > So in my opinion the problem must be a combination from something „on > the way“ and the 6.6er installation :-( Sounds like it's something specific to this network path. What's on it? > I tried once more to copy from a 6.4 BSD to the firewall and got no > error. Do you have any idea, what could have changed between 6.4 and > 6.5!? 6 months worth of development. > I had a look at the > scp-logfile from a (6.4er) working copy and saw no great differences > between this and the error-logfile :-( On the mindrot-page was a > paragraph about a specific cipher, that caused the problem at his setup. > Do you think, this could be my problem, too? Possibly. I have seen one instance where aes-gcm ciphers failed, I suspect due to a faulty CPU. > Or what could I else do? Some suggestions: a) you could tell us which ciphers you saw for the problematic and working connections. b) you could also install Portable OpenSSH 8.0 on your 6.6 system and test copying to it. That was the version of OpenSSH that shipped with 6.5 (likewise OpenSSH 7.9 that shipped with 6.4). That would narrow it down to whether or not it's OpenSSH or some other part of the system. c) ship a large test file via netcat to a netcat listener over the same network paths and compare sha256sums of source and destination. If you can reproduce a problem without ssh that'll narrow it down. d) compare the ifconfigs for the 6.4 host and the 6.6 host and see if anything is different. > Of course, I could copy my files on another way, like http(s), but it > has a negative smack, because you know, something is now not working, > what was running in a earlier release and over 2 years without a > problem. And you don't know, if this problem causes other failures :-( > > >> /usr/sbin/sshd -ddd -p 50 -E sshd.debug.4.log > > > > If you add "-e" to the command line you'll get more information from > > after when sshd re-execs itself. > > Same output with „-e“ as without :-( > > >> The controller is a virtual machine on ESXi. > > > > This is the first variable I'd try removing if possible. There have > > been other cases of VMWare networking causing problems (although not > > these symptoms): > > https://marc.info/?l=openssh-unix-dev&m=153535111501535&w=2 > > Yes I tried, same problem with a real PC. > > > from the dmesg: > >> em0 at pci2 dev 0 function 0 "Intel 82545EM" rev 0x01: > > > > Alternatively, I'd try switch the network interface to vio from em. > > That's unfortunately not possible, the firewall is like a appliance with > two build-in nics and no room for extensions. The dmesg says it's from the VM controller not the hardware firewalls. I don't think we've seen a dmesg from a firewall. -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
