This is the result of my quest to find the reason why I couldn't roam
with any mac80211 driver (tested with iwl3945 and b43).
When you use dhclient for dhcp, the (very old) default dhclient-script
brings the interface down and then up again after it receives a DHCPNAK
(and on some other occasions). With the ieee80211 stack, this never
caused any problems.
However, with mac80211, after the interface has been brought down and
then up again, the "RUNNING" flag in ifconfig disappears and no data is
being transmitted. Due to dhclient's weird behaviour, this makes any
mac80211 driver unusable with dhclient and the (very old) default script.
I had no difficulty fixing this problem (once I found it), simply remove
the word 'down' from all ifconfig-lines in dhclient-script.
My question is, should this be considered a bug in mac80211?
IMO, when an interface is brought down and then up again, one of the
following things should happen:
1) Everything works as before
2) Nothing works, but the card disassociates from the network.
The current behaviour (card stays associated, but no data is transmitted
any more) is unintuitive and costed me much time.
John W. Linville schrieb:
>> 1) Everything works as before
>> 2) Nothing works, but the card disassociates from the network.
>
> #2 would be my vote.
Fine by me, as long as I don't spend 6 months again trying to make my
wireless work :)
>> The current behaviour (card stays associated, but no data is transmitted
>> any more) is unintuitive and costed me much time.
>
> Seems like a bug to me. Would you mind opening a bug at
> bugzilla.kernel.org?
Good, opened a report:
http://bugzilla.kernel.org/show_bug.cgi?id=10372
On Sat, Mar 29, 2008 at 07:32:51PM +0100, Thomas B=E4chler wrote:
> My question is, should this be considered a bug in mac80211?
> IMO, when an interface is brought down and then up again, one of the=20
> following things should happen:
> 1) Everything works as before
> 2) Nothing works, but the card disassociates from the network.
#2 would be my vote.
> The current behaviour (card stays associated, but no data is transmit=
ted=20
> any more) is unintuitive and costed me much time.
Seems like a bug to me. Would you mind opening a bug at
bugzilla.kernel.org?
Thanks!
John
--=20
John W. Linville
[email protected]
On Tuesday 01 April 2008 15:27:06 Tomas Winkler wrote:
> On 4/1/08, bruno randolf <[email protected]> wrote:
> > On Tuesday 01 April 2008 04:02:25 John W. Linville wrote:
> > > On Sat, Mar 29, 2008 at 07:32:51PM +0100, Thomas B=E4chler wrote:
> > > > My question is, should this be considered a bug in mac80211?
> > > > IMO, when an interface is brought down and then up again, one o=
f the
> > > > following things should happen:
> > > > 1) Everything works as before
> > > > 2) Nothing works, but the card disassociates from the network.
> > >
> > > #2 would be my vote.
> >
> > why is that? would it be so difficult to provide #1?
>
> Driver should not take policy decision. It should be user controled
> applincation such as NM or ifup script of whatever to decide if to
> reconnect or not.
>
> > from a usability point of view #1 would be clearly better. whatever=
the
> > state was before, when i bring the interface up it want it to work
> > (associate, join IBSS) and be able to transmit data.
>
> For usuablity point of view you should configure your applicantion or
> script to do reconnection, but it should not be driver call to do
> that.
> There are security issues with this that just get more and more
> compilcated.. In application level you have more options to discover =
your
> environment and handle user preferences. and take the correct call
allright - that seems to be the way to go. thanks for the explanation. =
i guess=20
i'm a little bit behind, still thinking in in terms of iwconfig ;)
bruno
On Tuesday 01 April 2008 04:02:25 John W. Linville wrote:
> On Sat, Mar 29, 2008 at 07:32:51PM +0100, Thomas B=E4chler wrote:
> > My question is, should this be considered a bug in mac80211?
> > IMO, when an interface is brought down and then up again, one of th=
e
> > following things should happen:
> > 1) Everything works as before
> > 2) Nothing works, but the card disassociates from the network.
>
> #2 would be my vote.
why is that? would it be so difficult to provide #1?
from a usability point of view #1 would be clearly better. whatever the=
state=20
was before, when i bring the interface up it want it to work (associate=
, join=20
IBSS) and be able to transmit data.
bruno
On 4/1/08, bruno randolf <[email protected]> wrote:
> On Tuesday 01 April 2008 04:02:25 John W. Linville wrote:
> > On Sat, Mar 29, 2008 at 07:32:51PM +0100, Thomas B=E4chler wrote:
> > > My question is, should this be considered a bug in mac80211?
> > > IMO, when an interface is brought down and then up again, one of =
the
> > > following things should happen:
> > > 1) Everything works as before
> > > 2) Nothing works, but the card disassociates from the network.
> >
> > #2 would be my vote.
>
> why is that? would it be so difficult to provide #1?
Driver should not take policy decision. It should be user controled app=
lincation
such as NM or ifup script of whatever to decide if to reconnect or not.
>
> from a usability point of view #1 would be clearly better. whatever t=
he state
> was before, when i bring the interface up it want it to work (associa=
te, join
> IBSS) and be able to transmit data.
=46or usuablity point of view you should configure your applicantion or
script to do reconnection, but it should not be driver call to do
that.
There are security issues with this that just get more and more compilc=
ated.
In application level you have more options to discover your
environment and handle user preferences. and take the correct call
Tomas
> bruno
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wirel=
ess" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>