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
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
...@bugs.debian.org, T.A. van Roermund t...@van-roermund.nl
On Sun, 14 Sep 2014 00:52:55 +0200 Balint Reczey
bal...@balintreczey.hu wrote:
Control: tags -1 moreinfo
Hi,
On Wed, 23 Oct 2013 18:06:03 +0200 T.A. van Roermund
t...@van-roermund.nl wrote:
On 22-10-2013 20:02, T.A. van Roermund wrote:
In the mean
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.archlinux.org
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
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
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
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:
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:
cut
Signature Algorithm:
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 |
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
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, email
12 matches
Mail list logo
