Package: src:linux
Version: 4.14.7-1
Severity: critical
Tags: patch upstream
Justification: breaks the whole system
Dear Maintainer,
This morning, I updated the Linux kernel from linux-image-4.13.0-1-amd64 to
linux-image-4.14.0-2-amd64.
Afterwards, my Intel Gigabit adapter (details below) did no
I don't know, because until now I have been using the workaround
(i.e. always disable TSO).
I just re-enabled it to see if this error will still occur with the
latest kernel. I'll report again in a week or so whether it is
stable now.
Unfortunately, the bug still occurs. See the log below
int Reczey -
Date: Fri, 31 Oct 2014 09:17:50 +0100
From: Balint Reczey
Subject: Re: linux-image-3.10-3-amd64: Network adapter (Intel 82579V)
hangs during TX, causing reset and undetected data corruption at the
other side
To: 727...@bugs.debian.org, "T.A. van Roermund"
On 22-10-2013 20:02, T.A. van Roermund wrote:
In the mean time I have found a solution to this problem: if I disable TCP
segmentation offload using the command 'ethtool -K eth2 tso off', the problem
does no longer occur.
By the way: I found the solution here:
https://bbs.arc
Package: src:linux
Version: 3.10.11-1
Severity: critical
Justification: causes serious data loss
Dear Maintainer,
Since the upgrade from kernel version 3.2.0-4 to 3.10-3 I get serious data
corruption on the network connection between my server and my desktop PC. The
server has the Intel Corpora
Steve Langasek wrote:
Please try setting 'TLSVerifyClient allow' in your slapd.conf, and let us
know whether that fixes the problem for you.
In my tests, I see that the default client certificate handling for 2.4.7
with GnuTLS does not match what's documented in the slapd.conf manpage; I
think w
Quanah Gibson-Mount wrote:
That would be a problem if "server-timo.van-roermud.nl" is not in
subjectAltName for the certs.
I changed the certificate (self signed), it now looks like this (only
the relevant parts):
Certificate:
Data:
Signature Algorithm: sha1WithRSAEncr
Quanah Gibson-Mount wrote:
Ok. Does your certificate have a proper cn, matching the fqdn of your
server? That's the only other case where I can reproduce the described
behavior, but I don't know if that's a behavior change relative to the
OpenSSL version. (I would have hoped that OpenSSL would
Steve Langasek wrote:
Well, I can reproduce the problem when using this value for TLSCipherSuite.
But why would you set this value, rather than leaving TLSCipherSuite blank
to use the default? I don't see the point of listing *all* the cipher types
if you don't intend to exclude some of them.
Quanah Gibson-Mount wrote:
Have you verified that port 636 is open? I.e., telnet localhost 636
The port is open:
$ telnet localhost 636
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
And:
$ netstat --listening --numeric --program | gre
Quanah Gibson-Mount wrote:
Have you verified whether or not you can connect using LDAPS via the
command line tools? (ldapsearch, ldapwhoami, etc).
Yes I did:
$ ldapsearch -H ldaps://localhost:636/ -X cn=admin
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
The rel
Hi,
I have the same problem. Following your suggestion, I listed all the
cipher suites using "gnutls-cli -l" and tried all of them. Now, slapd
does start, but still Thunderbird cannot connect to the daemon, no
matter which cipher suite was selected.
Regards,
Timo
--
To UNSUBSCRIBE, emai
12 matches
Mail list logo
