Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
some APs on my laptop with an AR9285 Wireless card.
dhcp works fine on an open wifi network but receives no response on a
wep network I use. I haven't been able to test it on a third network
for now.
Reverting to 3.2.1 solved the issue which is still there in the latest
git revision as of today.
DHCPDISCOVER requests are still sent but no ACK is received (nothing
in Wireshark).
dhcp failure may be one particular instance of the problem but I
haven't been able to connect with a static ip (my ap doesn't like it)
so this is the
only result I know.
ver_linux output (latest git kernel) :
Linux litbox 3.3.0-rc1-hack-00383-g0a96265 #1 SMP PREEMPT Mon Jan 30
02:22:54 CET 2012 x86_64 Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
GenuineIntel GNU/Linux
Gnu C????????????????? 4.6.2
Gnu make?????????????? 3.82
binutils?????????????? 2.22.0.20111227
util-linux???????????? 2.20.1
mount????????????????? support
module-init-tools????? 4
e2fsprogs????????????? 1.42
jfsutils?????????????? 1.1.15
reiserfsprogs????????? 3.6.21
xfsprogs?????????????? 3.1.7
pcmciautils??????????? 018
PPP??????????????????? 2.4.5
Linux C Library??????? 2.15
Dynamic linker (ldd)?? 2.15
Linux C++ Library????? so.6.0
Procps???????????????? 3.2.8
Net-tools????????????? 1.60
Kbd??????????????????? 1.15.3
Sh-utils?????????????? 8.15
wireless-tools???????? 29
Modules Loaded???????? ipv6 cpufreq_ondemand fuse xts gf128mul
uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev
v4l2_compat_ioctl32 media arc4 ath9k ath9k_common ath9k_hw nouveau
ehci_hcd usbcore i915 snd_hda_codec_hdmi snd_hda_codec_realtek joydev
ath ttm intel_ips mac80211 cfg80211 asus_laptop sparse_keymap rfkill
drm_kms_helper drm snd_hda_intel snd_hda_codec snd_hwdep mxm_wmi
psmouse i2c_algo_bit serio_raw i2c_core pcspkr input_polldev mei
iTCO_wdt usb_common evdev intel_agp iTCO_vendor_support intel_gtt
atl1c wmi video snd_pcm snd_page_alloc snd_timer snd soundcore thermal
battery ac button tun kvm_intel kvm aes_x86_64 aes_generic
acpi_cpufreq mperf processor freq_table ext4 crc16 jbd2 mbcache
dm_crypt dm_mod sd_mod ahci libahci libata scsi_mod
On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <[email protected]> wrote:
> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
> some APs on my laptop with an AR9285 Wireless card.
>
> dhcp works fine on an open wifi network but receives no response on a
> wep network I use. I haven't been able to test it on a third network
> for now.
reverting "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
helps. i need to analyze
if it exposes some real issue which need to be fixed.
> Reverting to 3.2.1 solved the issue which is still there in the latest
> git revision as of today.
>
> DHCPDISCOVER requests are still sent but no ACK is received (nothing
> in Wireshark).
>
> dhcp failure may be one particular instance of the problem but I
> haven't been able to connect with a static ip (my ap doesn't like it)
> so this is the
> only result I know.
>
>
> ver_linux output (latest git kernel) :
>
> Linux litbox 3.3.0-rc1-hack-00383-g0a96265 #1 SMP PREEMPT Mon Jan 30
> 02:22:54 CET 2012 x86_64 Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
> GenuineIntel GNU/Linux
>
> Gnu C????????????????? 4.6.2
> Gnu make?????????????? 3.82
> binutils?????????????? 2.22.0.20111227
> util-linux???????????? 2.20.1
> mount????????????????? support
> module-init-tools????? 4
> e2fsprogs????????????? 1.42
> jfsutils?????????????? 1.1.15
> reiserfsprogs????????? 3.6.21
> xfsprogs?????????????? 3.1.7
> pcmciautils??????????? 018
> PPP??????????????????? 2.4.5
> Linux C Library??????? 2.15
> Dynamic linker (ldd)?? 2.15
> Linux C++ Library????? so.6.0
> Procps???????????????? 3.2.8
> Net-tools????????????? 1.60
> Kbd??????????????????? 1.15.3
> Sh-utils?????????????? 8.15
> wireless-tools???????? 29
> Modules Loaded???????? ipv6 cpufreq_ondemand fuse xts gf128mul
> uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev
> v4l2_compat_ioctl32 media arc4 ath9k ath9k_common ath9k_hw nouveau
> ehci_hcd usbcore i915 snd_hda_codec_hdmi snd_hda_codec_realtek joydev
> ath ttm intel_ips mac80211 cfg80211 asus_laptop sparse_keymap rfkill
> drm_kms_helper drm snd_hda_intel snd_hda_codec snd_hwdep mxm_wmi
> psmouse i2c_algo_bit serio_raw i2c_core pcspkr input_polldev mei
> iTCO_wdt usb_common evdev intel_agp iTCO_vendor_support intel_gtt
> atl1c wmi video snd_pcm snd_page_alloc snd_timer snd soundcore thermal
> battery ac button tun kvm_intel kvm aes_x86_64 aes_generic
> acpi_cpufreq mperf processor freq_table ext4 crc16 jbd2 mbcache
> dm_crypt dm_mod sd_mod ahci libahci libata scsi_mod
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
--
shafi
On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
<[email protected]> wrote:
> On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <[email protected]> wrote:
>> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>> some APs on my laptop with an AR9285 Wireless card.
>>
>> dhcp works fine on an open wifi network but receives no response on a
>> wep network I use. I haven't been able to test it on a third network
>> for now.
>
> ?reverting ?"ath9k_hw: fix interpretation of the rx KeyMiss flag" does
> helps. ?i ?need to analyze
> if it exposes some real issue which need to be fixed.
>
this seems to be a problem in WEP alone, where the key miss is always
set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
decrypt, but fails due to ICV mismatch.
--
shafi
Hi Felix,
On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau <[email protected]> wrote:
> On 2012-02-01 5:27 PM, John W. Linville wrote:
>> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>>> <[email protected]> wrote:
>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <[email protected]> wrote:
>>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>>> >> some APs on my laptop with an AR9285 Wireless card.
>>> >>
>>> >> dhcp works fine on an open wifi network but receives no response on a
>>> >> wep network I use. I haven't been able to test it on a third network
>>> >> for now.
>>> >
>>> > ?reverting ?"ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>>> > helps. ?i ?need to analyze
>>> > if it exposes some real issue which need to be fixed.
>>> >
>>>
>>> this seems to be a problem in WEP alone, where the key miss is always
>>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>>> decrypt, ?but fails due to ICV mismatch.
>>
>> OK...any way to differentiate this case at that point in the code?
>>
>> John
> Please try this patch:
>
> ---
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
> ? ? ? ? ? ? ? ?(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
> ? ? ? ? ? ? ? ? ATH9K_RXERR_KEYMISS));
>
> + ? ? ? /*
> + ? ? ? ?* First 4 slots are reserved for WEP, and for packets using them,
> + ? ? ? ?* ATH9K_RXERR_KEYMISS can be reported even though decryption was
> + ? ? ? ?* successful, since no MAC address based key cache lookup was
> + ? ? ? ?* performed.
> + ? ? ? ?*/
> + ? ? ? if (rx_stats->rs_keyix < 4)
> + ? ? ? ? ? ? ? rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
> +
> ? ? ? ?if (!rx_stats->rs_datalen)
> ? ? ? ? ? ? ? ?return false;
> ? ? ? ? /*
unfortunately as the rx_keyix is always 'INVALID' (as obtained from
the descriptor) this check does not seems to help
--
shafi
It works for me too.
On Thu, Feb 2, 2012 at 1:28 PM, Felix Fietkau <[email protected]> wrote:
> On 2012-02-02 6:37 AM, Mohammed Shafi wrote:
>> Hi Felix,
>>
>> On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau <[email protected]> wrote:
>>> On 2012-02-01 5:27 PM, John W. Linville wrote:
>>>> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>>>>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>>>>> <[email protected]> wrote:
>>>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <[email protected]> wrote:
>>>>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>>>>> >> some APs on my laptop with an AR9285 Wireless card.
>>>>> >>
>>>>> >> dhcp works fine on an open wifi network but receives no response on a
>>>>> >> wep network I use. I haven't been able to test it on a third network
>>>>> >> for now.
>>>>> >
>>>>> > ?reverting ?"ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>>>>> > helps. ?i ?need to analyze
>>>>> > if it exposes some real issue which need to be fixed.
>>>>> >
>>>>>
>>>>> this seems to be a problem in WEP alone, where the key miss is always
>>>>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>>>>> decrypt, ?but fails due to ICV mismatch.
>>>>
>>>> OK...any way to differentiate this case at that point in the code?
>>>>
>>>> John
>>> Please try this patch:
>>>
>>> ---
>>> --- a/drivers/net/wireless/ath/ath9k/recv.c
>>> +++ b/drivers/net/wireless/ath/ath9k/recv.c
>>> @@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
>>> ? ? ? ? ? ? ? ?(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
>>> ? ? ? ? ? ? ? ? ATH9K_RXERR_KEYMISS));
>>>
>>> + ? ? ? /*
>>> + ? ? ? ?* First 4 slots are reserved for WEP, and for packets using them,
>>> + ? ? ? ?* ATH9K_RXERR_KEYMISS can be reported even though decryption was
>>> + ? ? ? ?* successful, since no MAC address based key cache lookup was
>>> + ? ? ? ?* performed.
>>> + ? ? ? ?*/
>>> + ? ? ? if (rx_stats->rs_keyix < 4)
>>> + ? ? ? ? ? ? ? rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
>>> +
>>> ? ? ? ?if (!rx_stats->rs_datalen)
>>> ? ? ? ? ? ? ? ?return false;
>>> ? ? ? ? /*
>>
>>
>> unfortunately as the rx_keyix is always 'INVALID' (as obtained from
>> the descriptor) this check does not seems to help
> You're right. I read up on what the other codebases do here, and I have
> a better patch here:
>
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -823,6 +823,14 @@ static bool ath9k_rx_accept(struct ath_c
> ? ? ? ? ? ? ? ?(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
> ? ? ? ? ? ? ? ? ATH9K_RXERR_KEYMISS));
>
> + ? ? ? /*
> + ? ? ? ?* Key miss events are only relevant for pairwise keys where the
> + ? ? ? ?* descriptor does contain a valid key index. This has been observed
> + ? ? ? ?* mostly with CCMP encryption.
> + ? ? ? ?*/
> + ? ? ? if (rx_stats->rs_keyix == ATH9K_RXKEYIX_INVALID)
> + ? ? ? ? ? ? ? rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
> +
> ? ? ? ?if (!rx_stats->rs_datalen)
> ? ? ? ? ? ? ? ?return false;
> ? ? ? ? /*
>
On 2012-02-01 5:27 PM, John W. Linville wrote:
> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>> <[email protected]> wrote:
>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <[email protected]> wrote:
>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>> >> some APs on my laptop with an AR9285 Wireless card.
>> >>
>> >> dhcp works fine on an open wifi network but receives no response on a
>> >> wep network I use. I haven't been able to test it on a third network
>> >> for now.
>> >
>> > reverting "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>> > helps. i need to analyze
>> > if it exposes some real issue which need to be fixed.
>> >
>>
>> this seems to be a problem in WEP alone, where the key miss is always
>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>> decrypt, but fails due to ICV mismatch.
>
> OK...any way to differentiate this case at that point in the code?
>
> John
Please try this patch:
---
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
ATH9K_RXERR_KEYMISS));
+ /*
+ * First 4 slots are reserved for WEP, and for packets using them,
+ * ATH9K_RXERR_KEYMISS can be reported even though decryption was
+ * successful, since no MAC address based key cache lookup was
+ * performed.
+ */
+ if (rx_stats->rs_keyix < 4)
+ rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
+
if (!rx_stats->rs_datalen)
return false;
/*
On 2012-02-02 6:37 AM, Mohammed Shafi wrote:
> Hi Felix,
>
> On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau <[email protected]> wrote:
>> On 2012-02-01 5:27 PM, John W. Linville wrote:
>>> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>>>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>>>> <[email protected]> wrote:
>>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <[email protected]> wrote:
>>>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>>>> >> some APs on my laptop with an AR9285 Wireless card.
>>>> >>
>>>> >> dhcp works fine on an open wifi network but receives no response on a
>>>> >> wep network I use. I haven't been able to test it on a third network
>>>> >> for now.
>>>> >
>>>> > reverting "ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>>>> > helps. i need to analyze
>>>> > if it exposes some real issue which need to be fixed.
>>>> >
>>>>
>>>> this seems to be a problem in WEP alone, where the key miss is always
>>>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>>>> decrypt, but fails due to ICV mismatch.
>>>
>>> OK...any way to differentiate this case at that point in the code?
>>>
>>> John
>> Please try this patch:
>>
>> ---
>> --- a/drivers/net/wireless/ath/ath9k/recv.c
>> +++ b/drivers/net/wireless/ath/ath9k/recv.c
>> @@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
>> (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
>> ATH9K_RXERR_KEYMISS));
>>
>> + /*
>> + * First 4 slots are reserved for WEP, and for packets using them,
>> + * ATH9K_RXERR_KEYMISS can be reported even though decryption was
>> + * successful, since no MAC address based key cache lookup was
>> + * performed.
>> + */
>> + if (rx_stats->rs_keyix < 4)
>> + rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
>> +
>> if (!rx_stats->rs_datalen)
>> return false;
>> /*
>
>
> unfortunately as the rx_keyix is always 'INVALID' (as obtained from
> the descriptor) this check does not seems to help
You're right. I read up on what the other codebases do here, and I have
a better patch here:
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -823,6 +823,14 @@ static bool ath9k_rx_accept(struct ath_c
(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
ATH9K_RXERR_KEYMISS));
+ /*
+ * Key miss events are only relevant for pairwise keys where the
+ * descriptor does contain a valid key index. This has been observed
+ * mostly with CCMP encryption.
+ */
+ if (rx_stats->rs_keyix == ATH9K_RXKEYIX_INVALID)
+ rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
+
if (!rx_stats->rs_datalen)
return false;
/*
On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
> <[email protected]> wrote:
> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <[email protected]> wrote:
> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
> >> some APs on my laptop with an AR9285 Wireless card.
> >>
> >> dhcp works fine on an open wifi network but receives no response on a
> >> wep network I use. I haven't been able to test it on a third network
> >> for now.
> >
> > ?reverting ?"ath9k_hw: fix interpretation of the rx KeyMiss flag" does
> > helps. ?i ?need to analyze
> > if it exposes some real issue which need to be fixed.
> >
>
> this seems to be a problem in WEP alone, where the key miss is always
> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
> decrypt, but fails due to ICV mismatch.
OK...any way to differentiate this case at that point in the code?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Thu, Feb 2, 2012 at 5:58 PM, Felix Fietkau <[email protected]> wrote:
> On 2012-02-02 6:37 AM, Mohammed Shafi wrote:
>> Hi Felix,
>>
>> On Wed, Feb 1, 2012 at 10:34 PM, Felix Fietkau <[email protected]> wrote:
>>> On 2012-02-01 5:27 PM, John W. Linville wrote:
>>>> On Wed, Feb 01, 2012 at 04:44:08PM +0530, Mohammed Shafi wrote:
>>>>> On Tue, Jan 31, 2012 at 11:28 AM, Mohammed Shafi
>>>>> <[email protected]> wrote:
>>>>> > On Tue, Jan 31, 2012 at 1:13 AM, Laurent Bonnans <[email protected]> wrote:
>>>>> >> Since the update from linux 3.2.1 to 3.2.2, dhcp stopped working on
>>>>> >> some APs on my laptop with an AR9285 Wireless card.
>>>>> >>
>>>>> >> dhcp works fine on an open wifi network but receives no response on a
>>>>> >> wep network I use. I haven't been able to test it on a third network
>>>>> >> for now.
>>>>> >
>>>>> > ?reverting ?"ath9k_hw: fix interpretation of the rx KeyMiss flag" does
>>>>> > helps. ?i ?need to analyze
>>>>> > if it exposes some real issue which need to be fixed.
>>>>> >
>>>>>
>>>>> this seems to be a problem in WEP alone, where the key miss is always
>>>>> set for this case and RX_FLAG_DECRYPTED is not set. mac80211 trys to
>>>>> decrypt, ?but fails due to ICV mismatch.
>>>>
>>>> OK...any way to differentiate this case at that point in the code?
>>>>
>>>> John
>>> Please try this patch:
>>>
>>> ---
>>> --- a/drivers/net/wireless/ath/ath9k/recv.c
>>> +++ b/drivers/net/wireless/ath/ath9k/recv.c
>>> @@ -823,6 +823,15 @@ static bool ath9k_rx_accept(struct ath_c
>>> ? ? ? ? ? ? ? ?(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
>>> ? ? ? ? ? ? ? ? ATH9K_RXERR_KEYMISS));
>>>
>>> + ? ? ? /*
>>> + ? ? ? ?* First 4 slots are reserved for WEP, and for packets using them,
>>> + ? ? ? ?* ATH9K_RXERR_KEYMISS can be reported even though decryption was
>>> + ? ? ? ?* successful, since no MAC address based key cache lookup was
>>> + ? ? ? ?* performed.
>>> + ? ? ? ?*/
>>> + ? ? ? if (rx_stats->rs_keyix < 4)
>>> + ? ? ? ? ? ? ? rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
>>> +
>>> ? ? ? ?if (!rx_stats->rs_datalen)
>>> ? ? ? ? ? ? ? ?return false;
>>> ? ? ? ? /*
>>
>>
>> unfortunately as the rx_keyix is always 'INVALID' (as obtained from
>> the descriptor) this check does not seems to help
> You're right. I read up on what the other codebases do here, and I have
> a better patch here:
>
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -823,6 +823,14 @@ static bool ath9k_rx_accept(struct ath_c
> ? ? ? ? ? ? ? ?(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
> ? ? ? ? ? ? ? ? ATH9K_RXERR_KEYMISS));
>
> + ? ? ? /*
> + ? ? ? ?* Key miss events are only relevant for pairwise keys where the
> + ? ? ? ?* descriptor does contain a valid key index. This has been observed
> + ? ? ? ?* mostly with CCMP encryption.
> + ? ? ? ?*/
> + ? ? ? if (rx_stats->rs_keyix == ATH9K_RXKEYIX_INVALID)
> + ? ? ? ? ? ? ? rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
> +
> ? ? ? ?if (!rx_stats->rs_datalen)
> ? ? ? ? ? ? ? ?return false;
> ? ? ? ? /*
>
this works for me (WEP key configured).
--
shafi