WAP4410N Wireless Connection Control detects invalid MAC Address

Linksys, Netgear, ect. Webbase configurations for Wireless access points.

WAP4410N Wireless Connection Control detects invalid MAC Address

Post by Guest » Tue Sep 21, 2010 9:53 am

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 SSIDs, 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 touchs 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?


Re:WAP4410N Wireless Connection Control detects invalid MAC Address

Post by Guest » Tue Sep 21, 2010 10:37 am

I have now established that the first characters of the Mini 110cs 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 WAP4410Ns reluctance to accept it into its Wireless Connection Control table. Anybody got an explanation?


Re:WAP4410N Wireless Connection Control detects invalid MAC Address

Post by Guest » Tue Sep 21, 2010 11:37 am

Correction... last post MAC Address should read 0C:EE:E6 etc.


Re:WAP4410N Wireless Connection Control detects invalid MAC Address

Post by Guest » Tue Sep 21, 2010 1:17 pm

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 equipments 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, thats 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.


Re:WAP4410N Wireless Connection Control detects invalid MAC Address

Post by Guest » Tue Sep 21, 2010 2:36 pm

Following on from my success yesterday, and after further deep thought (!), I decided to re-try altering the netbooks MAC Address from within the OS

supplied Device Manager. This had previously failed when trying to change from 0C:EE:E6:90:63:DF (Compaqs 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 its 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 APs Wireless Connection Control List, the wireless connection is quickly


Flushed with this success, I then repeated this exercise, going back to the manufacturers 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 its not just me who hit this problem!

Post Reply