cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1099
Views
0
Helpful
6
Replies

WAP121 Problems with WEP On 1.0.6 Firmware

Paul Parkins
Level 1
Level 1

We have been using WAP121 devices in our customer installs for some time. We appear to be experiencing problems on newer installs where the customer is using WEP (for whatever reasons, changing away from WEP to resolve the problem is not a solution available to us). Wireless clients seem unable to associate with the WAP121 if WEP is used.

 

As these problems have only started recently, we considered the firmware version in the WAPs. The WAPs we are purchasing now have firmware 1.0.6 in them. We have found that if we downgrade to 1.0.3 then we can happily use WEP

6 Replies 6

ktonev
Cisco Employee
Cisco Employee

Hi Paul,

Thanks for bringing this up - I'd like to gather some more information regarding this issue.

Does your customer experience this only on a specific platform (Android, iOS, Windows) or all devices are having issues?

Have you collected any log messages to see the exact error messages?

Thanks,
Kris

Hi,

The devices in question are our own embedded devices, so none of the operating systems you specify apply. These are the only devices on the network other than the Windows PC which the devices connect to which is wired and so does not use wireless security. 

 

I have not collected any logs, though I have proposed we should attempt to do this. Would you expect anything logged from the WAP121 regarding a client's difficulty to associate? I am not so sure.

 

Since I have a WAP121 available to me, I will attempt to duplicate the issue with v1.06 in our office and examine the WAP's logfile

 

Hi.

I have now set up the same system in my office and I can repeat the issues. There are no logs on the embedded device that would be any use. From it's debug output I can see it is associating with the access point then attempting DHCP which never appears to be successfull.

 

Similarly on the WAP121 there does not appear to be anything useful in its' log, we just see these two entries (on both versions of firmware)

Dec 31 1999 12:02:38 info hostapd[1084] wlan0: IEEE 802.11 STA 00:1e:c0:35:12:4f associated with BSSID 00:a6:ca:fb:9f:f4
Dec 31 1999 12:02:38 info hostapd[1084] wlan0: IEEE 802.11 Assoc request from 00:1e:c0:35:12:4f BSSID 00:a6:ca:fb:9f:f4 SSID PPCISCO

 

I can confirm the my WEP based device was ok with WAP firmware  v1.0.3.4 but it was not ok with v1.0.6.5. Then when I downgraded back to v1.0.3.4, it was once again ok.

 

I tried Wiresharking the comm's on the wired port on the access point and it I can see a DHCP Discover from the device, and a DHCP Offer from the dhcp server. However I don't think the client sees this as it never progresses onto DHCP Request, and instead periodically repeats the DHCP discover.

 

For an independant test I tried my Android phone. It behaves the same as the client and when the WAP is using 1.0.6.5 it canot gain an ip address.

 

I also tried a few other firmware versions. 1.0.6.2 does not work. 1.0.5.3 does work.

My conclusions are that when using WEP with firmware versions 1.0.6, comm's traffic is not bidirectional and only goes from wireless to wired devices, and not wired to wireless.

It's nearly 3 months since I raised this. Is anybody at Cisco considering it or able to confirm the issue and whether it will be addresses?

Hi Paul,

Since the issue you are experiencing is between your own embedded devices and the WAP121 I'd suggest to open a case with TAC so an engineer can investigate the issue and possibly raise a feature request.

Thanks,
Kris

Hi,

 

Whilst the customer facing problem is based on our own embedded devices, I explained that I was able to reproduce the problem using my Android phone (Samsung S6). This implies to me that it is not a problem with our embedded devices.

 

Also, as I was able to list several successive Cisco firmware version where everything was ok, up until a certain firmware version, surely this points to some change in the Cisco firmware causing the issue?

 

Using the information I have provided, it should be a relatively simple matter for Cisco to attempt to reproduce the issue.

 

Regards

 

Paul