Just bought a Compaq Mini 110C for my wife. After initial setup, and by providing the relevant encryption key, it successfully connected to my new WAP4410N no problem. Wireless Connection Control for the SSID is Disabled.
The AP has been configured with three SSID's, one each for 802.11b, -g, & -n devices, with different Security Modes and Encryption Keys applied to suit. This is working well, and with Wireless Connection Control now Enabled, and the device physical addresses entered to the AP table, all my Wireless-G computers, iPod touch's etc are still able to gain access to the network via the correct SSID as one would expect.
However, when I add in the MAC address for the new Mini 110C to SSID-G, which according to ipconfig /all has a Broadcom 802.11b/g WLAN chip in it, the AP says "MAC 6 [its the sixth device to be added to SSID-G] must be 12 Hex chars (0-9 and A-F) with optional delimiters (: or -) and the second bit not an odd number". Repeated attempts to input the physical address 0C:EE:E6... etc result in rejection. So the new notebook will only connect with Wireless Connection Control disabled.
After much research, some odd things are noted...
1) This MAC Address is the first I have encountered that does not have 00 for its first byte (octet). Possible nothing amiss there though, as I see examples listed on various sites.
2) By inputting the first half of the MAC Address (the six digits 0CEEE6) into the MAC Address Lookup and Search tool at About.com, significantly no matches are found. This should have indicated the manufacturer of this wireless device!
3) FYI, 0005B5 is Broadcom Technologies, 000AF7 is Broadcom Corp., 001018 is broadcom corporation & 001BE9 is Broadcom Corporation. None remotely like the 110C!
4) According to Wikipedia, a Universally Administered Address is uniquely assigned to a device by its manufacturer, etc etc. Often as a BIA or "burned in address", as in the case of this Compaq PC. A Locally Administered Address is assigned to a device by a network administrator, over-riding the BIA. Universal and Locally administered addresses are distinguished by setting the second least significant bit of the most significant byte of the address. In my case the most significant byte is 0C (hex) = 00001100 (binary). Second least significant bit is 0, so it is a OUI or Organizationally Unique Identifier. It is also EVEN, and therefore should be acceptable to being typed in to the WAP4410N Wireless Control table! So why does it bomb?
Now I know how to spoof the MAC address for this network adapter by tweaking the registry or using SMAC v2.0 and so on, and I am confident that in minutes I could make this computer connect successfully to the AP with MAC filtering switched back on.
But... I do not like things I do not understand, and anyway what would a PC novice do in a situation like this when trying to access a similar protected network?
So, can anyone offer an explanation as to what is happening with my WAP4410N (going to order a 2nd tomorrow!) and this wee computer? And if I do end up having to spoof to fool it, what MAC Address should I go for?
I have now established that the first characters of the Mini 110c's MAC Addresss 00:0E:E6 indicate this Organizationally Unique Identifier has been assigned to Hon Hai Precision Ind Co Ltd in Shanghai which at least confirms that it should be a valid OUI. But it still does not explain the WAP4410N's reluctance to accept it into its Wireless Connection Control table. Anybody got an explanation?
My problem is resolved, but not before a lot of time and effort was spent on it. So that others may learn from this, here is what I did...
I first used the Evaluation Mode of SMAC v2.0 to generate a new [random] Broadcom Technologies MAC Address 00:0A:F7:C3:AE:76, but then quickly discovered there is a charge to purchase the software to actually implement what for me is a "one-off" MAC fix!
So next I followed detailed instructions from the website http://www.windowsreference.com/networking/how-to-change-mac-address-in-windows-registry/ to add a new NetworkAddress value 000af7c3ae76 to the appropriate location in registry. As the wifi NIC is first disabled and then re-enabled, if present this value
should be used, otherwise the BIA [burned in address] is used. In my case use of ipconfig /all revealed no change.
More research flags up Technitium TMAC v5.0 R3, hopefully the answer to my prayer? I have now generated several Broadcom 00:0A:F7... addresses and clicked Change Now, with the "Automatically Restart...." and "Make....Persistent" boxes checked. Everything seems to proceed OK, with a pane "MAC Address was changed successfully" opening. Click on OK. But the Wireless Network Connection shows that the MAC Address has NOT BEEN CHANGED! Very, very strange!
MAC Address 0C:EE:E6:90:63:DF (Inactive 00:0A:F7:C3:AE:76)
Significantly the registry now contains a NetworkAddress value identical to what I previously entered manually, which confirms I got it right!
Clicking on Original MAC button and although Technitium has not actually changed the one in use, it appears to have successfully changed it back to...
MAC Address 0C:EE:E6:90:63:DF (Original).
While the new registry entry NetworkAddress is still shown in regedit, there is now a new variable that I am sure was not present when I started this...
OriginalNetworkAddress, value 0C-EE-E6-90-63-DF, which of course is the equipment's burned in address.
By now I am tearing my hair out. An email to Technitium got the following [very fast] reply... "There is issue with changing MAC Address in many wifi NIC
which have new drivers. Some how these drivers are blocking change of MAC address. But, if you set the first byte of the MAC Address to "02" then it works.
The exact problem is still under investigation and a solution when reached will be released in new version of TMAC. This issue applies to only wifi NIC,
while with ethernet NIC its working properly (as per feedback from users)."
It took less than a minute to get the Compaq Mini successfully connected to the Access Point with its new [Unknown Manufacturer] MAC Address, now
02:0A:F7:C3:AE:76. The WAP4410N was also happy to accept this value into its Wireless Connection Control List. When filtering was re-enabled, connection is still maintained. Only "Allowed" equipment, incl the 110c, can get in to my network. Result!
OK, but still not sure why the 0C (hex) first octet was rejected by the AP. Another input from Technitium... "Regarding your question, OriginalNetworkAddress
value is saved by TMAC so that it can show the original MAC when the NIC is disabled. When NIC is enabled, it reads directly the MAC address from it to check status if the MAC address is really changed.
Secondly, the MAC Address you mentioned is not valid as it begins with "0C". It should be "00", "01" or "02". Checkout
http://en.wikipedia.org/wiki/Mac_address#Address_details where u can see a diagrammatic view of the details. Only 2 bits are defined for first octet, so "0C"
gives you 00001100 in binary, in which the 2 bits set are not defined in standards."
Not sure that I agree 100% with this interpretation! OK, so 0C(hex) translates to 00001100(binary) [b8,b7,b6,b5,b4,b3,b2,b1 in order]. From the wiki, b1=0,
so it unicast. b2=0, so it is OUI enforced as would be expected for a BIA.
Now with the spoofed address where the first octet is 02(hex), then we have 00000010(binary). b1=0, so it is still unicast. b2=1, so now it is a Locally
Administered Address and over-rides the BIA. Well, that's my explanation as to why the Technitium recommended fix worked. But why would a manufacturer use an invalid MAC Address? I do not believe it to be invalid!
If any "expert" cares to expand on this topic, I would certainly welcome their comments. Meanwhile the new PC is on a protected network, the object of this exercise.
Following on from my success yesterday, and after further deep thought (!), I decided to re-try altering the netbook's MAC Address from within the OS
supplied Device Manager. This had previously failed when trying to change from 0C:EE:E6:90:63:DF (Compaq's original) to 00:0A:F7:C3:AE:76, a randomly
generated Broadcom Technolgies value. But now with the first octet forced to 02(hex), here is the sequence...
Rt-click on My Computer icon
Select Manage | Device Manager
Open Network Adapters
Select the wifi adapter, in my case it's a Broadcom 802.11b/g WLAN
Double click to open its Properties pane.
Select the Advanced tab.
In the left pane, Property, highlight Locally Administered MAC Address
Click to change from Not Present to Enter Value, in my case 020af7c3ae76, and click OK.
The NIC will re-enable with the new MAC Address, and if this is already in the AP's Wireless Connection Control List, the wireless connection is quickly
Flushed with this success, I then repeated this exercise, going back to the manufacturer's supplied original 0C:EE:E6:90:63:DF, but with just the first octet
0C(hex) changed to 02(hex). After editing the WAP4410N filter table, again this is 100% satisfactory, as would be expected. Many thanks to Shreyas Zare at
technitium.com for providing the key to this. Incidentally frequent use of ipconfig /all confirms that MAC Addresses are successfully changed at each step in
Thanks to a link provided by Shreyas, I now know that Linksysby Cisco user JPSeagull has also posted re an identical "netbook+WAP4410N" scenario at
http://forums.linksysbycisco.com/linksys/board/message?board.id=Access_Points&thread.id=12206. So it's not just me who hit this problem!
Thank you so very much - I ran into this same problem on my new WAP4410Ns. When trying to enter the MACs for 5 new Lenovo Laptops that have Broadcom 802.11G wireless network adapters the WAP reported them as invalid. I tried changing them to 00:.... to no avail. After using your information of setting them to 02:.... was able to change the MACs for the wireless connections and get them working. Again - Thank you very much.
Also you can do this. You can log into the WAP4410N and save the configuration file.
After saving your config file, open the config file up using notepad or any other text editor.
scroll all the way down to where you see the mac entry's put the Pc's mac address into the file and
save the file. After doing this load the new config file into the wap4410n.
Many thanks to KeltechITdept for kind comments. Just pleased my experience helped with your Lenovo Laptops! However, if I interpret next poster Jason's
message correctly, there has been an easier solution all along! I checked out the WAP4410N config file and the MAC Address table for the Wireless Connection
Control feature is dead easy to spot and of course edit as he says. I have a feeling that using Jason's method allows the PC's native Wireless LAN Mac
Address (in my case 0C: etc) to be entered without the need to resort to "spoof" it to 02: etc. Haven't had time to actually try this yet with the Compaq
Netbook as this is now way down my current priority task list! But I reckon it makes sense. Maybe Jason can confirm this to be the case?
Regards to all
Just found that out recently and it works very well. After reconfiguring the config file, just load it back into the wap4410n .
Log into the wap4410 and just verify that the mac address is in the mac field, and test.
I have only tested on one pc, but if it worked for that one mac address it should be the same for other pcs.
Busy learning how to produce an XP SP3 CD with all latest hotfixes, drivers etc slipstreamed just now, and cannot risk getting side-tracked! However my next task is to personalize the Compaq Netbook for my wife (after all it was her Xmas pressie and here we are well into 2010 and all she can do on it is play a few games and surf the web). So I will test your method then by setting its MAC Address back to its factory setting, and editing the WAP4410N config file as you said. I know exactly how to do it, anticipate no issues and will post my result ASAP.
Thanks for your continued support.
Jason Bryant - You are the man.I got 2 of the WAP4410Ns to cover all of my factory. I was trying to get the first WAP to work. After going through all the trouble of changing the MAC on the first laptop I saw your post!!! Wow - just what I needed.!!! I put the data into the config file with notepad, uploaded and Zoinks - it worked - fantastic. I was also able to copy the config and change a few settings so I could just access the second WAP - upload the cfg file - a reboot and I was all set. Thank you very much for your elegant solution to our problem.
Frank - now my face looks like this :)
Finally found a few moments to revert the Compaq Netbook to its factory-set MAC Address, edit the two WAP4410N config files, and as as Jason said within a few minutes everything was as it should have been in the first place! A more elegant solution than my "cheat" method... well done!
I was already aware of the value of the config file, having used the file for WAP4410N-1 to speed up prep of WAP4410N-2, both virtually identical except they
are on different channels. Without conducting detailed tests, seamless roaming for the Netbook seems to be working OK.
I assume Cisco will fix this annoying bug in a future firmware release?