Sleeping 5 seconds before bringing up the interfaces improves
reliability a lot (At times I was still getting wpa_supplicant not
connecting because the interface was down).
Cheers,
Luca
state-funcs
Description: Binary data
On Wed, Jun 23, 2010 at 04:17:06PM +0200, Luca Niccoli wrote:
The line isn't forcing wicd on anyone, it's just needed to make wicd
work after toggling wifi.
People can use network manager or plain old wpa_supplicant and it will
work just well (they don't need any poking)
Ah, it seems I
Ah, it seems I misunderstood. I thought every solution would need poking and
you just chose wicd among the alternatives. If this line is only needed for
wicd users I'm perfectly fine with it.
To be perfectly fair, I'm sure only that wicd needs poking and
wpa_supplicant on its own doesn't.
But
On Mon, Jun 21, 2010 at 11:29:21AM +0200, Luca Niccoli wrote:
use both systems would lead to any kind of trouble), and I don't know
if it makes sense. Is it really a common use case to update
acpi-support while still using a very old kernel?
Don't know but I can see your reasoning.
Mmm, does
On 23 June 2010 08:46, Michael Meskes mes...@debian.org wrote:
Exactly. We would need at least a Recommend here.
Why? using wicd doesn't enhance acpi-support, nor it is necessary in any way.
If the problem is the error message, the amended version attached avoids it.
(wpa_supplicant and
On 15 June 2010 18:47, Michael Meskes mes...@debian.org wrote:
Is it possible to keep the old stuff as a fall back solution? Would that make
sense at all?
I think it would be hard to do (the main problem is that rfkill
devices are not uniquely linked to wireless interfaces, so trying to
use
On Wed, May 19, 2010 at 01:27:19AM +0200, Luca Niccoli wrote:
This is a revised version, the previous one had problems with rfkill_input.
Unfortunately none of my wireless cards supports rfkill on linux
2.6.26, so I wasn't able to test it there; but I checked the
/sys/class/rfkill interface
On 13 May 2010 01:40, Luca Niccoli lultimou...@gmail.com wrote:
This is my first attempt.
It's supposed to be a drop-in replacement for
/usr/share/acpi-support/state-funcs
I still have to try it with lenny's kernel, though (will try before next week)
This is a revised version, the previous
On 12 May 2010 13:20, Michael Meskes mes...@debian.org wrote:
Sure, feel free to send patches.
This is my first attempt.
It's supposed to be a drop-in replacement for
/usr/share/acpi-support/state-funcs
I still have to try it with lenny's kernel, though (will try before next week)
Cheers,
Package: acpi-support
Version: 0.136-3
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
/usr/share/acpi-support/state-funcs begins with
IFACE_NAMES=`cut -d: -f1 -s /proc/net/wireless`
and then uses strings in $IFACE_NAMES to know wich interfaces are to be
turned off and on.
But if
Overall the systems looks overly error prone and complicated; I think it
would be useful if we could drop the support of pre-lenny kernels (and
madwifi too, since it's been RMed).
Sounds reasonable to me.
This should let us move to a rfkill-centric approach, instead of a device
centric one.
11 matches
Mail list logo
