Anyone else seen this? The 877W is a 802.11b/g radio and DSL modem.
Tried open auth, wep and wpa2 - the 877 was seeing the iTach but had a strange message about a unassoicated client "Auth_not_A" (show dot11 associations) - irrespective of the auth type used.
When I tried to associate the iTach to a billion AP it worked first time.
Hi Brad,
This may be due to an interaction bug between the chipset in the router with our wireless chip, but if the router is seeing the unit then likely this is not the problem. Have you attempted to set a static IP rather than a DHCP address or vice versa? I have linked our wireless FAQ below to give you details to check on the wireless router settings. My guess would be that there is a way to get it connected, but some sort of setting is causing the issue.
http://globalcache.zendesk.com/entries/218437-faq-why-isn-t-my-wifi-itach-connecting-to-my-network
~Josh
Thanks for the reply.
I tried for about 4 hours - configuring the itach, testing, resetting, trying again.
Open auth without wep keys in the itach config, with wep keys, configuring wep and trying dhcp and static ip assignment, and wpa2 required me to upgrade my 877 to an software release that supported it. At the the same time I was using a MacBook via the same wireless SSID - so the changes made to the access point still enabled other clients to join.
Did I mention that I configure Cisco kit for a living? ;)
I'm leaning towards some low level issue as you mentioned - the debugging commands on the Cisco side were shedding very little light on the issue, again, that points towards a low level issue. Its irritating, but I can work around it. Once I have finished configuring up iRule and my AV setup I'll spend some more time trying to debug wireless.
There is a possibility that the router you are using has some sort of interaction issue with our WiFi units. We will perform some testing to see if we are able to connect one of our units to this router, and we will let you know when we have the results. If this problem has persisted, we will work with you to make sure that you get up and running one way or another.
Thanks Josh. I'm happy to attempt any things you find out :)
I'm experiencing similar problems, and the site just ate my first reply. So, I'll put this simply...
My home network is covered by a cisco Aironet 1242AG. I am a network engineer by day, as well. Here's the error message retrieved from the AP, when attempting to configure with 26 alphanumeric characters (128-bit WEP): "Possible encryption key mismatch between interface Dot11Radio0 and station 000c.1e02.0733"
This is interesting, and rather discouraging. I just decided to take one step at a time to move this little box over to my wireless network. So, my first step was to set an appropriate IP address for my network. Without changing the wireless settings, I did nothing more than change the IP address and gateway, and set the first DNS server address to 0.0.0.0.
Hit "Save," and wait for the reboot. Then, to my surprise, I reconnected via 169.254.1.70. Yup. A simple IP address change didn't take.
The problem still exists with -04 firmware.
Okay. I've figured out that 128-bit WEP is broken. With a spare 1242, I setup a temporary network for testing. Using identical settings as my primary network (different SSID), I configured the access point for 40-bit WEP. On both the AP and WF2SL, I configured my key as "1234567890." On second thought, I probably should have had at least one alpha character in there. No problems with connecting.
After the successful test, I changed one parameter: the encryption string. On the router, I changed the drop-down box in "Encryption Manager" to 128-bit, and provided a 26-character hex string in the associated box. On the WF2SL configuration page, I simply toggled the encryption setting and replaced "1234567890" with the same hex string as configured on the AP (all four key indexes, both times). Back to the original problem. The AP reports a possible encryption key mismatch and never learns the WF2SL's IP address.
Global Caché, please fix this issue. Right now, your device is worthless to me, and I really would like to avoid running a network cable up to my projector. I'm off to make an attempt at configuring the IP2IR.
It looks as though there is an implementation mismatch between this 128 bit WEP on the router and the unit. We will do some digging on our side as to what is causing the problem. Also, it sounds as though you changed the settings on the router before you changed the settings on the unit. Once the network has changed settings, the unit would be unable to continue its communication with the network. As this would cause the unit to fail to connect, this may be part of what was giving you difficulty.
Josh, thank you for investigating this situation. My router actually has no part in this equation (slip of tongue, above), as the cisco Aironet 1242AG is a stand-alone access point. In addition, the encryption string was properly configured on the WF2SL, though I can understand that you wouldn't want to eliminate that as a possibility.
Much as Brad, designing and configuring datacommunications networks is my profession. With the amount of troubleshooting that I've done thus far, my pay grade would have purchased a dozen of these little boxes. I really just want to use what I have to integrate my cinema components into a single control panel. The IP2IR was a quick and easy implementation, which really raises my hopes for using the GC system.
If it helps, I also tried configuring the WF2SL with a 32-character hexidecimal string composed of the 26-character encryption key, followed by the six-character device ID from the WF2SL's MAC address. At this point, I'm pretty much at the limits of black-box testing. No matter what I configure as a key on the WF2SL, the result is inevitably the same - encryption mismatch. I'll be happy to help, if you want me to down-rev to 700 code or beta a new release.
We are currently working to handle problems such as this. This is seemingly a problem with the WiFi module used in our product, which is a component of the iTach WiFi units. We appreciate the time invested in troubleshooting the problem. Our testing shows that 128 bit WEP encryption implements differently on these 'Linksys by Cisco' type routers than many others which have tested with passing results. Our goal is to find a way to work around the difference in our firmware, but as of yet we do not have a fully functional fix. If you are looking to use the same functionality and avoid the wireless aspect, the IP2SL will work perfectly for you and will avoid the problems with security and the like. We assure you that we do monitor our forums as well as those with posts pertaining to our hardware and we are investing our resources into solidifying the firmware of our units. If you feel your limit has been reached, feel free to return the unit, and thank you for your interest in Global Caché.
I also saw the Auth_not_A status on a Cisco WAP yesterday, and solved it by configuring the radio to allow 802.11b speeds. It was set to require speeds all the way up to 54Mbps, limiting it to 11g clients only. Now it's set to "speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0" which requires 11b speeds and allows 11g speeds. May not have been your problem, but it's an obscure enough status message that I was only getting Google results from Cisco's unhelpful documentation and this thread. :)
Hi,
I have a similar situation with two different iTach devices. I have the Serial to WiFi device and the Contact Closures to WiFi device also.
I have a large Cisco 3502 AP environment using a Cisco 2106 controller. No matter what I do I can't get either to connect at all. I have tried no security, WPA2, locking down my WLAN to b/g only, etc. Both units configure just fine using their adhoc networks, but then after reboot they just both sit there with a solid green light. I have all data rates supported in my config. I also have tested successfully a Foscam B/G camera with WPA2 (not at the same time as your units).
AMXB
<-UUID=GlobalCache_000C1E025C8D>
<-SDKClass=Utility>
<-Make=GlobalCache>
<-Model=iTachWF2SL>
<-Revision=710-1007-05>
<-Pkg_Level=GCPK001>
<-Config-URL=http://169.254.1.70>
<-PCB_PN=025-0030-07>
<-Status=Ready>
Something to try would be to toggle between DHCP and a static address (swap out the one you are configuring the unit with) to see if that makes a difference. We have seen routers which do not properly implement DHCP interactions in 802.11b. Also, try switching the router to a B only mode. If the unit successfully connects, then the implementation of the mixed mode used is not properly handling connection to our unit. Another thing to check, would be if the router is using both a 2.4 and 5GHz radio. In rare cases, the wireless data of a 5GHz network can cause interference for our units, so temporarily disabling that would be a worthwhile diagnostic.