The patch "prism54: set carrier flags correctly" makes my
prism54 device in AP mode come up without a carrier, which
in causes IPv6 to not add a link-local address, which in
turn causes radvd (configured to announce routes on that
device) to refuse to start, breaking IPv6 for the entire
network.
I didn't check whether a carrier is detected once a client
associates, but in any case it seems to me that a device
in AP mode should always indicate a carrier.
Dan Williams wrote:
> On Tue, 2008-04-22 at 06:42 +0200, Patrick McHardy wrote:
>> The patch "prism54: set carrier flags correctly" makes my
>> prism54 device in AP mode come up without a carrier, which
>> in causes IPv6 to not add a link-local address, which in
>> turn causes radvd (configured to announce routes on that
>> device) to refuse to start, breaking IPv6 for the entire
>> network.
>>
>> I didn't check whether a carrier is detected once a client
>> associates, but in any case it seems to me that a device
>> in AP mode should always indicate a carrier.
>
> Should always indicate a carrier _when it's configured and up_. If you
> just go 'iwconfig eth1 mode master' it shouldn't, but if you do:
>
> ifconfig eth1 up
> iwconfig eth1 mode master essid foobar
>
> then it should.
Yes, it was up and running of course. No carrier though.
On Tue, Apr 22, 2008 at 7:56 AM, Patrick McHardy <[email protected]> wrote:
>
> Dan Williams wrote:
>
> > On Tue, 2008-04-22 at 06:42 +0200, Patrick McHardy wrote:
> >
> > > The patch "prism54: set carrier flags correctly" makes my
> > > prism54 device in AP mode come up without a carrier, which
> > > in causes IPv6 to not add a link-local address, which in
> > > turn causes radvd (configured to announce routes on that
> > > device) to refuse to start, breaking IPv6 for the entire
> > > network.
> > >
> > > I didn't check whether a carrier is detected once a client
> > > associates, but in any case it seems to me that a device
> > > in AP mode should always indicate a carrier.
> > >
> >
> > Should always indicate a carrier _when it's configured and up_. If you
> > just go 'iwconfig eth1 mode master' it shouldn't, but if you do:
> >
> > ifconfig eth1 up
> > iwconfig eth1 mode master essid foobar
> >
> > then it should.
> >
>
> Yes, it was up and running of course. No carrier though.
Good catch. The carrier is set upon a firmware trigger so it is
possible that when in AP mode we don't hit the trigger in firmware. I
left open the possibility for this happening and go figure it happens.
Even if we had docs this probably wouldn't be documented :) I'll try
to cook up an exception patch now.
Luis
Patrick McHardy wrote:
> Luis R. Rodriguez wrote:
>>> Good catch. The carrier is set upon a firmware trigger so it is
>>> possible that when in AP mode we don't hit the trigger in firmware. I
>>> left open the possibility for this happening and go figure it happens.
>>> Even if we had docs this probably wouldn't be documented :) I'll try
>>> to cook up an exception patch now.
>>
>> Let me know if this fixes it.
>> [...]
>
> This will probably fix the error I'm seeing, but if I'm not
> mistaken the mode can be changed while the device is UP and
> this case is not handled by your patch.
I've verified that is fixes the bug if the device is already
configured for AP mode when set UP.
It appears to also be working correctly when configuring
the device for master mode after bringing it up, but I
don't understand why.
On Tue, 2008-04-22 at 06:42 +0200, Patrick McHardy wrote:
> The patch "prism54: set carrier flags correctly" makes my
> prism54 device in AP mode come up without a carrier, which
> in causes IPv6 to not add a link-local address, which in
> turn causes radvd (configured to announce routes on that
> device) to refuse to start, breaking IPv6 for the entire
> network.
>
> I didn't check whether a carrier is detected once a client
> associates, but in any case it seems to me that a device
> in AP mode should always indicate a carrier.
Should always indicate a carrier _when it's configured and up_. If you
just go 'iwconfig eth1 mode master' it shouldn't, but if you do:
ifconfig eth1 up
iwconfig eth1 mode master essid foobar
then it should.
Dan
On Tue, Apr 22, 2008 at 10:50:27AM -0700, Luis R. Rodriguez wrote:
> On Tue, Apr 22, 2008 at 7:56 AM, Patrick McHardy <[email protected]> wrote:
> >
> > Dan Williams wrote:
> >
> > > On Tue, 2008-04-22 at 06:42 +0200, Patrick McHardy wrote:
> > >
> > > > The patch "prism54: set carrier flags correctly" makes my
> > > > prism54 device in AP mode come up without a carrier, which
> > > > in causes IPv6 to not add a link-local address, which in
> > > > turn causes radvd (configured to announce routes on that
> > > > device) to refuse to start, breaking IPv6 for the entire
> > > > network.
> > > >
> > > > I didn't check whether a carrier is detected once a client
> > > > associates, but in any case it seems to me that a device
> > > > in AP mode should always indicate a carrier.
> > > >
> > >
> > > Should always indicate a carrier _when it's configured and up_. If you
> > > just go 'iwconfig eth1 mode master' it shouldn't, but if you do:
> > >
> > > ifconfig eth1 up
> > > iwconfig eth1 mode master essid foobar
> > >
> > > then it should.
> > >
> >
> > Yes, it was up and running of course. No carrier though.
>
> Good catch. The carrier is set upon a firmware trigger so it is
> possible that when in AP mode we don't hit the trigger in firmware. I
> left open the possibility for this happening and go figure it happens.
> Even if we had docs this probably wouldn't be documented :) I'll try
> to cook up an exception patch now.
Let me know if this fixes it.
Signed-off-by: Luis R. Rodriguez <[email protected]>
diff --git a/drivers/net/wireless/prism54/islpci_dev.c b/drivers/net/wireless/prism54/islpci_dev.c
index 04c2638..9196825 100644
--- a/drivers/net/wireless/prism54/islpci_dev.c
+++ b/drivers/net/wireless/prism54/islpci_dev.c
@@ -388,8 +388,15 @@ islpci_open(struct net_device *ndev)
netif_start_queue(ndev);
- /* Turn off carrier unless we know we have associated */
- netif_carrier_off(ndev);
+ /* Turn off carrier if in STA or Ad-hoc mode. It will be turned on
+ * once the firmware receives a trap of being associated
+ * (GEN_OID_LINKSTATE). In other modes (AP or WDS or monitor) we
+ * should just leave the carrier on as its expected the firmware
+ * won't send us a trigger. */
+ if (priv->iw_mode == IW_MODE_INFRA || priv->iw_mode == IW_MODE_ADHOC)
+ netif_carrier_off(ndev);
+ else
+ netif_carrier_on(ndev);
return 0;
}
Luis R. Rodriguez wrote:
>> Good catch. The carrier is set upon a firmware trigger so it is
>> possible that when in AP mode we don't hit the trigger in firmware. I
>> left open the possibility for this happening and go figure it happens.
>> Even if we had docs this probably wouldn't be documented :) I'll try
>> to cook up an exception patch now.
>
> Let me know if this fixes it.
>
> Signed-off-by: Luis R. Rodriguez <[email protected]>
>
> diff --git a/drivers/net/wireless/prism54/islpci_dev.c b/drivers/net/wireless/prism54/islpci_dev.c
> index 04c2638..9196825 100644
> --- a/drivers/net/wireless/prism54/islpci_dev.c
> +++ b/drivers/net/wireless/prism54/islpci_dev.c
> @@ -388,8 +388,15 @@ islpci_open(struct net_device *ndev)
>
> netif_start_queue(ndev);
>
> - /* Turn off carrier unless we know we have associated */
> - netif_carrier_off(ndev);
> + /* Turn off carrier if in STA or Ad-hoc mode. It will be turned on
> + * once the firmware receives a trap of being associated
> + * (GEN_OID_LINKSTATE). In other modes (AP or WDS or monitor) we
> + * should just leave the carrier on as its expected the firmware
> + * won't send us a trigger. */
> + if (priv->iw_mode == IW_MODE_INFRA || priv->iw_mode == IW_MODE_ADHOC)
> + netif_carrier_off(ndev);
> + else
> + netif_carrier_on(ndev);
>
> return 0;
> }
>
This will probably fix the error I'm seeing, but if I'm not
mistaken the mode can be changed while the device is UP and
this case is not handled by your patch.
Patrick McHardy wrote:
> Patrick McHardy wrote:
>> Luis R. Rodriguez wrote:
>>>> Good catch. The carrier is set upon a firmware trigger so it is
>>>> possible that when in AP mode we don't hit the trigger in firmware. I
>>>> left open the possibility for this happening and go figure it happens.
>>>> Even if we had docs this probably wouldn't be documented :) I'll try
>>>> to cook up an exception patch now.
>>>
>>> Let me know if this fixes it.
>>> [...]
>>
>> This will probably fix the error I'm seeing, but if I'm not
>> mistaken the mode can be changed while the device is UP and
>> this case is not handled by your patch.
>
> I've verified that is fixes the bug if the device is already
> configured for AP mode when set UP.
>
> It appears to also be working correctly when configuring
> the device for master mode after bringing it up, but I
> don't understand why.
Just to make sure this doesn't get lost, this fix hasn't made it to
Linus' tree yet and appears to be still needed.