[gentoo-user] Re: CIFS mounts started misbehaving
On 2017-03-03, J. Roeleveld wrote: > On March 3, 2017 7:49:27 PM GMT+01:00, Grant Edwards > wrote: >>About a week ago, they started acting oddly. They all mount fine, and >>work as usual as long as you keep using them. AFAICT, if they sit >>idle for "a while" (tens of minutes, maybe an hour), they freeze up. [...] > My guess would be some timeout setting on the server killing the > login. That doesn't seem to be the problem. I've asked around, and others aren't seeing this problem. I've also noticed that sometimes the mounts will start working again without a umount/mount, but I can't figure out what causes it... Normally, when things are working but idle, the TCP connection to 445 shows an SMB echo request/rseponse transaction once per minute. When it fails, the TCP connection evidently got dropped, and the Windows machine repeatedly shuts down new ones: The failure mode looks like this in wireshark: GentooWindows -> SYN -> 445 <-SYN/ACK <- 445 -> ACK -> 445 -> SMB[echo req]-> 445 <- RST <- 445 [that repeats 800 times per second for long periods of time] Then at some point, it starts to work: ->SYN -> 445 <- SYN/ACK <- 445 ->ACK -> 445 -> SMB[proto neg req] -> 445 <- SMB[proto neg rsp] <- 445 -> SMB[ses setup req] -> 445 <- SMB[ses setup rsp] <- 445 ... Sometimes the umount times out and "fails" because the "host is down", and when that happens, it seems like it immediately starts to work again. :/ -- Grant Edwards grant.b.edwardsYow! Wow! Look!! A stray at meatball!! Let's interview gmail.comit!
Re: [gentoo-user] CIFS mounts started misbehaving
On March 3, 2017 7:49:27 PM GMT+01:00, Grant Edwards wrote: >For the past 10-15, I've been mounting a handfull of directories that >reside on a Windows server, and it's always worked find. > >About a week ago, they started acting oddly. They all mount fine, and >work as usual as long as you keep using them. AFAICT, if they sit >idle for "a while" (tens of minutes, maybe an hour), they freeze up. > >After that, trying to access them hangs, and then eventually reports >"host is down". Except the host _isn't_ down. If I do an >unmount/mount it works instantly without complaint and the mounted >directory is fine again -- for a while. > >I don't think I've changed anything relevent on my Gentoo box (the >CIFS client), and it's probably something on the Windows end of >things. > >But, I was hoping somebody might have seen something similar and knows >what to do about it. > >Here's a typical line in /etc/fstab: > >\\winhost\projects /winhost/projects cifs >netbiosname=,workgroup=,username=,password=,uid=,gid=users,noserverino,dir_mode=0777,file_mode=0777,noauto >0 0 > > is the username (same on Gentoo and Windows) > is the Windows workgroup name > is the Windows server password for > >Any ideas? My guess would be some timeout setting on the server killing the login. Maybe there is a keep-alive option in the mount? Otherwise a cronjob that keeps 'touch'ing a file on one or all of the shares would avoid this happening. If the windows admin doesn't like that option, have him undo whatever he changed. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-user] CIFS mounts started misbehaving
For the past 10-15, I've been mounting a handfull of directories that reside on a Windows server, and it's always worked find. About a week ago, they started acting oddly. They all mount fine, and work as usual as long as you keep using them. AFAICT, if they sit idle for "a while" (tens of minutes, maybe an hour), they freeze up. After that, trying to access them hangs, and then eventually reports "host is down". Except the host _isn't_ down. If I do an unmount/mount it works instantly without complaint and the mounted directory is fine again -- for a while. I don't think I've changed anything relevent on my Gentoo box (the CIFS client), and it's probably something on the Windows end of things. But, I was hoping somebody might have seen something similar and knows what to do about it. Here's a typical line in /etc/fstab: \\winhost\projects /winhost/projects cifs netbiosname=,workgroup=,username=,password=,uid=,gid=users,noserverino,dir_mode=0777,file_mode=0777,noauto 0 0 is the username (same on Gentoo and Windows) is the Windows workgroup name is the Windows server password for Any ideas? -- Grant Edwards grant.b.edwardsYow! What a COINCIDENCE! at I'm an authorized "SNOOTS gmail.comOF THE STARS" dealer!!
Re: [gentoo-user] SHA-1 has just been broken
On 03/02/2017 06:26 PM, Andrew Savchenko wrote: On Thu, 2 Mar 2017 03:42:24 -0500 taii...@gmx.com wrote: It is possible to have a reasonably secure system where the hard drive firmware (or any other devices) can't fuck around with the stuff on disk, although I highly doubt that the gentoo infrastructure (and kernel.org, and all the source repos for all the other software) does this Hard drive's firmware is a drive's micro OS, it can manipulate data on the disk as it pleases. The only way to protect privacy of the data is to write it already encrypted, so it still can be mangled and become unusable, but privacy will be kept. But see below about DMA. Of course, as I stated you have to bootstrap the crypto from the motherboard EEPROM chip. One way is to use a blob-free coreboot IOMMU supporting board and bootstrap the crypto/kernel off of the board firmware EEPROM chip to load the initial kernel thus no plaintext touches the disk and thus nothing can mess with it. The IOMMU (theoretically) protects the CPU and memory from rogue devices, such as the hard drive. No. Any DMA capable device can bypass IOMMU. IOMMU was not designed to protect OS from device. That isn't true, it was designed for exactly that and of course for assigning devices to VM's. I get an AMD-Vi IOMMU IO_PAGE_FAULT alert in dmesg whenever a device tries to do something it shouldn't and the remapping hardware blocks it. In linux the kernel/drivers configure which memory locations the devices are allowed to access. In terms of ethics IBM *for now* is a way better company than Intel/AMD, their POWER servers are owner controlled as there isn't any boot guard/secure boot/management engine/platform "security" processor (amd's ME) to stop you from re-writing the firmware as you please. They also have an getting-there-almost-reasonable open source effort (OpenPOWER) Indeed they are. But that boxes are quite expensive and hard to get. Hard to get? You can buy them from IBM's website like any other computer. http://www-03.ibm.com/systems/power/hardware/linux-lc.html If you call them you may get a better price, but a credit card, 5 minutes (and $4.5K) will get you an entry level POWER8 server (although the almost open source firmware "Firestone" model costs around 10K) If you want a Palmetto you can get one for around $3K. They are a good deal vs intel/amd when it comes to performance/price, and of course the security and owner control aspects are absolutely swell. If you insert a graphics card you could use one as a workstation.
Re: [gentoo-user] SSH rekeying straight after authentication
On Monday 27 Feb 2017 16:49:42 Andrew Savchenko wrote: > On Thu, 23 Feb 2017 20:10:05 + Mick wrote: > > I am trying to understand why an ssh server keeps dropping the connection > > when using openssh on Linux straight after a successful authentication, > > but it works fine with Filezilla in MSWindows. > > [...] > > > I am guessing all this respawning probably triggers some DDoS protection > > limit on the server and it disconnects the client. Have you observed > > anything similar and would you know why Linux fails, but MSWindows works > > as it should? > I use HPN for years and connect to hundreds of servers, most of > them are without HPN support. I have no problems so far. But HPN is > unofficial and it may trigger problems. Maybe this is a bug in HPN, > maybe a server's custom protection. > > Try to report this on bugzilla for openssh maintainers. > > Best regards, > Andrew Savchenko Thanks Andrew, but I am not sure if it is an openssh bug or the particular server SSH implementation, which I do not control and the BOFH isn't particular helpful. It may be an SSH implementation interoperability problem. A Linux Mint PC suddenly fails to connect using the latest OpenSSH version (OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016) because the server does not appear to return a list of authentication methods as it should. The Gentoo PCs fail to connect because it seems the client switches from single to multithreaded CTR transaction and the SSH server then becomes over- protective. I've posted in OpenSSH M/L about the Linux Mint behaviour, but had no responses. -- Regards, Mick signature.asc Description: This is a digitally signed message part.