[gentoo-user] Re: CIFS mounts started misbehaving

[Grant Edwards]

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

[J. Roeleveld]

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

[Grant Edwards]

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

[taii...@gmx.com]

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

[Mick]

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.