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
> 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.
Bu
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 mis
On 23 June 2010 08:46, Michael Meskes 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 Network Manager do,
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, d
On 15 June 2010 18:47, Michael Meskes 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 both systems would
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 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 one had problems wi
On 12 May 2010 13:20, Michael Meskes 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,
Luca
state-funcs
D
> 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
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
11 matches
Mail list logo
