Public bug reported:
These days a typical flash drive has much larger capacity than a typical
OS iso image. It's a shame to waste all the extra space just to load a
single OS image. It would be nice to add an option to copy the OS image
to a specific partition of the flash drive instead. I've
Just to note - in OpenLDAP 2.5, which is currently being released, we've
added symbol versioning to libldap and liblber, so mixing of libraries
should no longer be a problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I think we can close this out, we were able to reproduce the issue
without kvm. Sorry for the false alarm.
** Changed in: qemu (Ubuntu)
Status: Incomplete => Invalid
** Changed in: openldap (Ubuntu)
Status: Confirmed => Invalid
** Changed in: openldap (Ubuntu)
Status:
Will try to come up with a minimal reproducer. Currently it takes
several hours to run the complete test, and a few hours before the SEGV
occurs. But the stack trace is always identical when it happens. In
multiple runs, it always succeeds on the host and always fails in the
VM.
--
You received
** Package changed: ubuntu => kvm (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1749247
Title:
Spurious SEGV running inside kvm
To manage notifications about this bug go to:
Public bug reported:
Running a continuous stream of operations against OpenLDAP slapd
eventually causes a SEGV in liblber, in a segment of code that cannot
fail:
gdb /opt/symas/lib64/slapd CoreDump
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
As I noted in our ITS#8025, this has nothing to do with upstream
OpenLDAP. It may be specific to the particular way you built OpenLDAP in
your distro, or it may be due to pam_ldap itself, but neither of these
are in the purview of the OpenLDAP Project. Certainly there is nothing
in vanilla
Try replacing pam-ldap/nss-ldap with nslcd and/or nssov and see if the
problem persists. I'd bet it doesn't. See here
https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/84
for reasons why you should have abandoned pam-ldap/nss-ldap years ago.
--
You received this bug
As I noted in our ITS#8025, this has nothing to do with upstream
OpenLDAP. It may be specific to the particular way you built OpenLDAP in
your distro, or it may be due to pam_ldap itself, but neither of these
are in the purview of the OpenLDAP Project. Certainly there is nothing
in vanilla
Try replacing pam-ldap/nss-ldap with nslcd and/or nssov and see if the
problem persists. I'd bet it doesn't. See here
https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/84
for reasons why you should have abandoned pam-ldap/nss-ldap years ago.
--
You received this bug
I just now discovered this was finally fixed. It only took 5 years for
someone to reinvent my patch... https://mail.gnome.org/archives
/networkmanager-list/2008-September/msg00042.html
Hopefully upstream will take this soon. Thanks for your work integrating
this much-needed feature.
--
You
I just now discovered this was finally fixed. It only took 5 years for
someone to reinvent my patch... https://mail.gnome.org/archives
/networkmanager-list/2008-September/msg00042.html
Hopefully upstream will take this soon. Thanks for your work integrating
this much-needed feature.
--
You
nslcd /nss-pam-ldapd would be the best choice, the code is quite mature
since the basic LDAP functionality is ported from the old PADL code and
well proven. It's also quite compact, it does just LDAP and nothing
else. SSSD is unproven, and quite overloaded featurewise. For
security/authentication
Public bug reported:
X server crashes and leaves a core file when fglrx is installed. The
crash is immedidate upon bootup, and leaves the console showing a text
screen with the last several lines of service startup messages. Trying
to toggle to a different virtual terminal gets no response.
Forcing use of nscd is a non-starter at many sites. Aside from cache
staleness issues, and nscd's well known instability, there's also the
issue that nscd doesn't intercept get*ent enumerations so things will
still crash depending on which nsswitch functions an app calls.
It would make sense to
This additional patch fixes the crash in bug#1013798.
** Attachment added: Addition to the patch in comment#73
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/423252/+attachment/3328846/+files/dif.txt
--
You received this bug notification because you are a member of Ubuntu
Server Team,
Oops. The attachment in comment#166 includes the patch in #73, it is not
incremental.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libnss-ldap in Ubuntu.
https://bugs.launchpad.net/bugs/423252
Title:
NSS using LDAP+SSL breaks
Forcing use of nscd is a non-starter at many sites. Aside from cache
staleness issues, and nscd's well known instability, there's also the
issue that nscd doesn't intercept get*ent enumerations so things will
still crash depending on which nsswitch functions an app calls.
It would make sense to
This additional patch fixes the crash in bug#1013798.
** Attachment added: Addition to the patch in comment#73
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/423252/+attachment/3328846/+files/dif.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Oops. The attachment in comment#166 includes the patch in #73, it is not
incremental.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/423252
Title:
NSS using LDAP+SSL breaks setuid applications like
Just echoing comment #33. My nm-applet was over *1.3GB* after only 7
days of uptime.
Very Unhappy Camper here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/780602
Title:
nm-applet leaks memory
3 sets of LDAP client libraries? That sounds like a terrible solution.
Fwiw, I wrote a version of OpenLDAP's TLS support that could use any/all
of OpenSSL, GnuTLS, and MozillaNSS simultaneously, and never released
it, because it seemed that would be too confusing if separate apps had
different
My point being, if you want to accommodate multiple TLS libraries
simultaneously with only a single libldap, that code is still available
in the OpenLDAP git repo. The relevant changes are between
a225b02f17fe79f6680d5d31db37320981e24774..4dff3e6807fb3451405373c2b85e02ccf27b882f
--
You received
3 sets of LDAP client libraries? That sounds like a terrible solution.
Fwiw, I wrote a version of OpenLDAP's TLS support that could use any/all
of OpenSSL, GnuTLS, and MozillaNSS simultaneously, and never released
it, because it seemed that would be too confusing if separate apps had
different
My point being, if you want to accommodate multiple TLS libraries
simultaneously with only a single libldap, that code is still available
in the OpenLDAP git repo. The relevant changes are between
a225b02f17fe79f6680d5d31db37320981e24774..4dff3e6807fb3451405373c2b85e02ccf27b882f
--
You received
** Bug watch added: Debian Bug tracker #663195
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663195
** Also affects: pidgin (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663195
Importance: Unknown
Status: Unknown
--
You received this bug notification because
** Bug watch added: Pidgin Trac #11623
http://developer.pidgin.im/ticket/11623
** Also affects: pidgin via
http://developer.pidgin.im/ticket/11623
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Bug watch added: Debian Bug tracker #575461
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575461
** Also affects: pidgin-otr (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575461
Importance: Unknown
Status: Unknown
--
You received this bug notification
Take a look at my rewrite of the pidgin-otr plugin, which only uses
libpurple. It uses libpurple's native conversation menu support instead
of creating 2-3 menus/buttons.
Be sure to read the README, since changing from using pidgin APIs to
libpurple has required a lot of other things to change.
Oops. Forgot to paste the URL.
https://gitorious.org/purple-otr
This is also my solution for bug#236780 ...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/292311
Title:
pidgin-otr produces 3
Ah, makes sense.
Also re: my previous comment, this was only a problem for a private
message IRC conversation. For regular IM chats the signoff message is
sent without trouble. Looking at the code, the reason is that libotr
tries to lookup the buddy associated with a conversation, so it can then
I've just ported this over. The new plugin uses only the basic libpurple
API, so the single purple-otr plugin works equally in both Pidgin and
Finch. Details are available here
http://lists.cypherpunks.ca/pipermail/otr-dev/2011-December/001237.html
--
You received this bug notification because
I've noticed this problem as well. It looks to me like the OTR plugin
isn't actually sending a signoff message to the peer when you end a
session. Haven't tracked down why just yet.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Tell me what you need to see in a canned slapd+nssov
configuration/script. Happy to provide that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/576137
Title:
nss-pam-ldapd should not depend on
Seems like exactly the same as bug #90812. And the workaround shown
there https://bugs.launchpad.net/openldap/+bug/90812/comments/31 still
works. If this is something we should be handling upstream, please
submit an ITS. For the moment it doesn't seem like it. The discussion of
libltdl implies
Seems like exactly the same as bug #90812. And the workaround shown
there https://bugs.launchpad.net/openldap/+bug/90812/comments/31 still
works. If this is something we should be handling upstream, please
submit an ITS. For the moment it doesn't seem like it. The discussion of
libltdl implies
(In reply to comment #70)
What is the status on this bug after 7 years?
From what I understand (correct me if I am wrong) the solution is to install
either nscd or libnss-ldapd. While both of these seem to work, they are not
acceptable solutions because it affects the rest of the system.
Petr: it was a nice thought, but I've only ever used AES and the problem
still occurred.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/414560
Title:
ath9k disassociates/reassociates a lot
--
For completeness' sake, another bug tracker with the same issue
https://bugs.g10code.com/gnupg/issue1181
** Bug watch added: GnuPG Bugs #1181
https://bugs.g10code.com/gnupg/issue1181
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
For completeness' sake, another bug tracker with the same issue
https://bugs.g10code.com/gnupg/issue1181
** Bug watch added: GnuPG Bugs #1181
https://bugs.g10code.com/gnupg/issue1181
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
://www.broadcom.com/support/802.11/linux_sta.php
linux-wlan-client-support-l...@broadcom.com
but received no acknowledgement. Which I believe is the usual result from
reporting driver bugs to vendors...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun
Yes, I'm using a compiled-in DSDT now but it's a PITA to have to
recompile it with every kernel update. (Echoing a previous request - if
this is going to be the standard solution then you guys need to
provide a kernel package that contains a kernel build tree with .o files
ready to be linked, so
re: Filing bugs against the kernel - that's only reasonable when there
is in fact a kernel bug. There are plenty of ACPI bugs that cannot be
labeled as kernel bugs, or fixed by other kernel patches. E.g. the new
AMD-based Lenovo Thinkpads are *missing* the PSS tables, because Lenovo
simply
That's unfortunate, I didn't realize libpam-ldapd was so incomplete. You
can still use nssov for full pam support.
Your best option for an immediate fix is still the libgcrypt patch I
posted. Without that basically all Karmic and Lucid nss-ldap+SSL
installations are dead in the water. As a longer
http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-
modules/nssov/README?rev=1.11
It's an overlay for OpenLDAP slapd which implements all of the nss and
pam calls, replacing Arthur deJong's nslcd.
--
NSS using LDAP+SSL breaks setuid applications like su and sudo
That's unfortunate, I didn't realize libpam-ldapd was so incomplete. You
can still use nssov for full pam support.
Your best option for an immediate fix is still the libgcrypt patch I
posted. Without that basically all Karmic and Lucid nss-ldap+SSL
installations are dead in the water. As a longer
http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-
modules/nssov/README?rev=1.11
It's an overlay for OpenLDAP slapd which implements all of the nss and
pam calls, replacing Arthur deJong's nslcd.
--
NSS using LDAP+SSL breaks setuid applications like su and sudo
By the way, if you apply the wpasupplicant patch I referenced in
bug#549269 you can then do manual scans with wpa_cli without interfering
with network-manager. (The feature is already in upstream wpasupplicant
0.7.x so upgrading that would work too.) With easy mechanisms for manual
scanning,
** Tags added: apport-collected
** Description changed:
When wpa_supplicant is spawned by DBUS it doesn't open any other control
interfaces, so you can no longer use wpa_cli to talk to it. Please consider
adding something like the patch here to re-enable wpa_cli support.
I read all of the diffs between 1.4.1 and 1.4.4 but didn't find any
likely suspects. However, tracing the library initialization in gdb, I
found the specific problem.
Ordinarily gnutls will initialize the gcrypt library, if no app has done
so already. In the gnutls initialization, it specifically
Probably the best fix: don't call global_init when setting the thread
callbacks.
** Attachment added: potential libgcrypt fix
http://launchpadlibrarian.net/45701569/dif1.txt
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug
Potential gnutls fix: do gcrypt initialization as long it isn't already
finished. probably a bad idea.
** Attachment added: potential gnutls fix
http://launchpadlibrarian.net/45701794/dif2.txt
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You
Rune: just google for nscd problems, it has a long history of stability
issues. But on top of the issues caused by poor implementation, it also
has problems due to an inherently inadequate design. Some of these
issues are outlined in my LDAPCon presentation linked above. All of this
is well
I read all of the diffs between 1.4.1 and 1.4.4 but didn't find any
likely suspects. However, tracing the library initialization in gdb, I
found the specific problem.
Ordinarily gnutls will initialize the gcrypt library, if no app has done
so already. In the gnutls initialization, it specifically
Probably the best fix: don't call global_init when setting the thread
callbacks.
** Attachment added: potential libgcrypt fix
http://launchpadlibrarian.net/45701569/dif1.txt
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You received this bug
Potential gnutls fix: do gcrypt initialization as long it isn't already
finished. probably a bad idea.
** Attachment added: potential gnutls fix
http://launchpadlibrarian.net/45701794/dif2.txt
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
https://bugs.launchpad.net/bugs/423252
You
Rune: just google for nscd problems, it has a long history of stability
issues. But on top of the issues caused by poor implementation, it also
has problems due to an inherently inadequate design. Some of these
issues are outlined in my LDAPCon presentation linked above. All of this
is well
I'd be happy to write a patch for the documentation. And given all of
the problems with the design (and implementation) of libnss-ldap, I'd
say any analysis will show that libnss-ldapd is still the path of lowest
risk and greatest stability. (In particular, when used with OpenLDAP
nssov.)
--
NSS
Right, given the timing for the Lucid release it's probably way too
late. I can't comment on your experience with nslcd as I have never used
its code or read it in depth. The stub library and nssov have been
pretty well tested internally in Symas; since the stub library is almost
entirely
Looking at the gcrypt code, it seems this bug should be reported against
that; this whole secmem implementation (1) requires a program to be
started as root (setuid) and (2) always drops the root priv when it has
initialized its secure memory. These behaviors would certainly interfere
with any
I'd be happy to write a patch for the documentation. And given all of
the problems with the design (and implementation) of libnss-ldap, I'd
say any analysis will show that libnss-ldapd is still the path of lowest
risk and greatest stability. (In particular, when used with OpenLDAP
nssov.)
--
NSS
Right, given the timing for the Lucid release it's probably way too
late. I can't comment on your experience with nslcd as I have never used
its code or read it in depth. The stub library and nssov have been
pretty well tested internally in Symas; since the stub library is almost
entirely
Looking at the gcrypt code, it seems this bug should be reported against
that; this whole secmem implementation (1) requires a program to be
started as root (setuid) and (2) always drops the root priv when it has
initialized its secure memory. These behaviors would certainly interfere
with any
Great find, Andreas. So gnutls is calling gcrypt's secure memory
functions. And yet, the gnutls docs say these functions are not used by
default, and certainly OpenLDAP does not configure gnutls to use them.
Something else in the stack must be setting that behavior.
--
NSS using LDAP on Karmic
Regardless of what the root cause turns out to be, you guys really need
to switch to libnss-ldapd, which will reliably isolate the user apps
from whatever junk is going on inside libldap / gnutls / whatever. (And
if you're not using the latest version, which also handles pam_ldap,
then you need to
You can find detailed design docs at its home page
http://arthurdejong.org/nss-pam-ldapd/
You can also find my LDAPCon2009 presentation on the subject here
http://www.symas.com/ldapcon2009/papers/hyc1.shtml
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
Great find, Andreas. So gnutls is calling gcrypt's secure memory
functions. And yet, the gnutls docs say these functions are not used by
default, and certainly OpenLDAP does not configure gnutls to use them.
Something else in the stack must be setting that behavior.
--
NSS using LDAP on Karmic
Regardless of what the root cause turns out to be, you guys really need
to switch to libnss-ldapd, which will reliably isolate the user apps
from whatever junk is going on inside libldap / gnutls / whatever. (And
if you're not using the latest version, which also handles pam_ldap,
then you need to
You can find detailed design docs at its home page
http://arthurdejong.org/nss-pam-ldapd/
You can also find my LDAPCon2009 presentation on the subject here
http://www.symas.com/ldapcon2009/papers/hyc1.shtml
--
NSS using LDAP on Karmic breaks 'su' and 'sudo'
One more request - if you're not going to integrate the custom DSDT
patch, please provide a .deb package for your kernel build tree with all
.o files intact. Then we can insert our own DSDT.hex and rebuild without
having to spend hours recompiling the entire kernel. This is getting to
be a real
On a slightly related note - I have a number of status update daemons on
my network that send status updates using UDP broadcast. They generally
only broadcast each update packet once. (UPS monitoring, a few other
misc things.) With NetworkManager doing its periodic scans, these UDP
broadcast
I just updated to the current Lucid beta on a new Dell Precision M4400
laptop with Broadcom BCM4322 wifi, and network-manager-0.8, the problem
is even worse now.
Mar 26 18:03:04 violino NetworkManager: debug [1269651784.005430]
periodic_update(): Roamed from BSSID 00:12:17:26:56:10 (HighlandSun)
Public bug reported:
When wpa_supplicant is spawned by DBUS it doesn't open any other control
interfaces, so you can no longer use wpa_cli to talk to it. Please consider
adding something like the patch here to re-enable wpa_cli support.
http://w1.fi/bugz/show_bug.cgi?id=335
(Note - this feature
Also note - without a working wpa_cli it's a lot harder to diagnose
problems such as https://bugs.launchpad.net/bugs/291760 ...
--
WPA supplicant control interface fix
https://bugs.launchpad.net/bugs/549269
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I just got a Thinkpad Edge yesterday and installed 10.04 beta1 x64 on
it. Out of the box the driver was only seeing 1 unencrypted network. I
grabbed the latest realtek driver and then was able to see the other
networks (my own is WPA/Enterprise). After I deleted the original driver
(from
I have a number of machines that all have different problems which require
custom DSDTs. With the latest kernels none of these machines work any more. 1)
An Asus A8V-Deluxe Socket 939 motherboard with Opteron 185 CPU. Asus stopped
providing updated BIOS images for this machine years ago, and it
Ok, so after the patch was removed from 2.6.25 in February 2008, it was
fixed and reposted in July 2008 http://lkml.org/lkml/2008/7/21/338 but
there were no further followups. What happened?
--
[karmic] 2.6.31 kernel does not load custom DSDT
https://bugs.launchpad.net/bugs/395239
You received
I'm hitting the same problem now, having just updated to Lucid Alpha 2
from Karmic. Unfortunately, my libdrm-radeon1 is already at the correct
version and the problem persists. objdump -T confirms that
/usr/lib/libdrm_radeon.so.1 exports radeon_cs_create but I'm still
getting this error. Quite
Never mind me I found an old libdrm in /lib. Deleting that fixed the
issue.
--
xserver-xorg-video-radeon has insufficient (even missing) dependency on
libdrm-radeon1
https://bugs.launchpad.net/bugs/507618
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Fixed in CVS slapd/bconfig.c 1.402
--
[karmic] slapd hangs at 100% cpu and is unkillable
https://bugs.launchpad.net/bugs/485026
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in ubuntu.
--
Ubuntu-server-bugs mailing list
Fixed in CVS slapd/bconfig.c 1.402
--
[karmic] slapd hangs at 100% cpu and is unkillable
https://bugs.launchpad.net/bugs/485026
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
I got sick of NetworkManager taking away control here, so I wrote this
patch
http://hostap.epitest.fi/bugz/show_bug.cgi?id=335
It restores access to the wpa_supplicant using the normal control
interface, even with the DBUS interface active. This allows tools like
wpa_cli and python wpa_ctrl to
@Kunal,
Yes, scanning is required to find a network to connect to, when you initially
have no connection at all. My point is that once you're successfully associated
to a network, automatic/background scanning should stop. You don't need
scanning to happen any more unless the environment
There are a number of bug reports for NM already. You can start with
this
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/291760
and the subsequent Gnome bug report
https://bugzilla.gnome.org/show_bug.cgi?id=580185
I provided a patch to remove the offending background scanning behavior
in
** Also affects: linux via
https://bugzilla.gnome.org/show_bug.cgi?id=580185
Importance: Unknown
Status: Unknown
--
network-manager roams to (none) ((none)) - background scanning
https://bugs.launchpad.net/bugs/291760
You received this bug notification because you are a member of
That was explained in one of the previous discussions. The ath9k is an
a/b/g/n interface and has a lot more channels to scan, and it's the
extra time required to scan these additional channels that causes the
association to time out. Or that's the theory anyway; the ath9k driver
seems to still
Public bug reported:
I filed this bug and a patch upstream already but the patch has been
ignored. It's getting pretty annoying having to fix this manually all
the time.
The VT100 command sequences CSI ? 47l (switch to primary screen) and CSI
? 47h (switch to alternate screen) are supposed to be
** Attachment added: Trivial fix
http://launchpadlibrarian.net/33779026/dif
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/33779027/Dependencies.txt
** Bug watch added: GNOME Bug Tracker #591648
https://bugzilla.gnome.org/show_bug.cgi?id=591648
** Also affects:
With the backports I see no more than 3% packet loss while I was
transfering 7,5GB of data with the speed of 21mbps.
When the 3% packet loss happens I see on my syslog this message:
wpa_supplicant[1297]: CTRL-EVEN-SCAN-RESULTS
That's caused by NetworkManager's background scanning. If you run
Where's the changelog, was there even any related change in that kernel
update?
I've switched to 2.6.32-rc3 built directly from kernel.org source. The
ath9k driver appears to work a lot better there, but the kernel crashes
on me. I'm guessing the crashes are related to the ATI r600 KMS support
That's right. I've also tried ath9k drivers from wireless-testing up to
2009-09-23. There hasn't been anything newer for ath9k that I'm aware
of.
Possibly there are two bugs at work in this bug report. The
NetworkManager background scanning issue also had an extremely bad
effect on the ath9k
I've been running without NetworkManager and just with manually
configured wpa_supplicant; the disconnects and performance issue still
remain. But NetworkManager aggravates the situation, which is why I now
disable it. (I described the other issue with NetworkManager in bug
439723)
--
ath9k
Actually I was referring to Bug #414560
However now that you mention it, I've seen the symptoms described here
as well. My guess is these are caused by the same bug.
--
ath9k - nm-applet don't connect to any network after 2 hours (+-)
https://bugs.launchpad.net/bugs/439723
You received this
Note - I've killed NetworkManager and the issue still remains. This is
an ath9k driver bug, not a NetworkManager bug.
Sep 30 23:15:11 violino kernel: [329813.143845] wlan0: no probe response from
AP 00:12:17:26:56:10 - disassociating
Sep 30 23:15:17 violino kernel: [329818.803730] wlan0:
Even with current wireless-testing the same problems remain, they just
occur less frequently now.
Sep 30 22:39:52 violino kernel: [327694.163945] wlan0: authenticate with AP
00:12:17:26:56:10
Sep 30 22:39:53 violino kernel: [327694.360741] wlan0: authenticate with AP
00:12:17:26:56:10
Sep 30
Running a current wireless-testing, it appears that commit c93f7c14
fixes a lot of the random disconnects for me. But I still get hangs
under sustained transfers, with the DMA failed to stop message in the
kernel log.
--
ath9k disassociates/reassociates a lot
Another possible solution would be just to add a mechanism to
NetworkManager (and the applet) to explicitly inform it of the existence
of a connected interface. I'm using adb from the Android SDK to start a
ppp session with my G1 phone, and ppp0 comes online with no trouble but
NetworkManager
Another me too on Jaunty but with 2.6.31-rc9. Switching to current
wireless-testing driver is even worse. Stability on ath9k has gone done
continuously since 2.6.31. I don't have any 2.6.30 builds but the last
kernel that worked half-decently for me with this wifi driver was
2.6.29.
--
ath9k
Public bug reported:
Binary package hint: ubuntu-docs
On this page
https://help.ubuntu.com/8.10/serverguide/C/openldap-server.html
In the steps for adding schema - we do not recommend editing or
referencing the slapd.d ldif files. These are after all internal files
of a slapd backend, they are
Ryan, of course you still have to edit the dn/cn, that's step 4. I
didn't say to drop step 4, only to perform it on the output of slapcat
instead of directly editing a slapd internal file.
--
OpenLDAP doc page, schema config
https://bugs.launchpad.net/bugs/416520
You received this bug
1 - 100 of 156 matches
Mail list logo
