CPE associated to AP. Working for weeks. This morning suddenly no more IP-level contact (client called)
Everything looked fine. But upon investigation why no more IP traffic, found the ARP list entry for this client has a different last digit than the wireless interface of client. (No bridge involved.)
How come the arp list entry is changed?
Just removed its dynamic arp entry and after 5 secs the list was updated with the proper arp list entry and client back on-line.
Anybody have any clue what might have happened?
a “dumping scratch” that is fixed by a reebout, that no one could explane 
It could be funny to se what the different interfaces mac addres really is. and what the address in arp entry say. It could actualy be a bad guy tying to “play” in your net. Or just something naturally.
The mac entry in the ARP of the AP was changed in the last bit only. It was supposed to be the real mac address of the radio of the client. But like said, one digit changed. Not the same mac as one of the clients ethernet ports nor was there any bridge involved.
By erasing the mac address entry in the ARP withing some second the original CPE’s radio mac was entered again and the CPE was accesible again…
AP runs mac address filter for all clients and on top of that I use encrypted NV2. So how big is the change that some user would change this mac? And for what purpose? The original CPE of the client was still in the registration table of AP and there where no other ‘strange’ mac’s in that list shown…
Anybody with other suggestions?
Only thing I have noticed, is that mac can change in last bits, if more than one interface is connected to a bridge, but not running. If you switch the cable, the bridge might change its mac (if admin mac is not set) to the next interface, that in an Ethernet interface, is 1 bit higer or lower. If you switch back, the cable to original port, the mac address to bridge, might still have the “temp” mac address, if the bit is lower than the first. This seems to exist more if running check is disabled to interface.
A common way to see this behaviour, is in a wds setup in wireless. Its impossible to connect to the mac addres registrated in wireless registration table, and its just possible to connect to the mac address in ip neighbour. (from bridge) That always is the lowest address on the device connected to the bridge. If Ethernet (as usual) have a lower value, you have to mac telnet to the Ethernet mac address. If the Ethernet interface, then is not running, You might have a problem connect in “all ways”. mac address shown in neighboor, is not on an interface running to device, and the device might just not want you to connect. After a boot, its all ok.
Yo don’t tell anything about how your arp table get this “arp request”. If mac filtred to one and one mac addresses, it should not be possible for client to send you another mac for your arp table. Then this have to come from something in your AP. If its just the common arp- who has, is at, and its not filtered, it is possible that somehow 2 devices have the same ip and could change the arp table. Mayby just by one bit, if the wlan card in 2 devices is from same production.
And, if (not likely) someone have changed a mac address? for what purpose? Drinking beer, bored and need something to do.
There are no bridges or wds involved. I know al these effects you prescribe in relation to bridges/wds etc. But that was not the case here. ONly the AP has 2 wlan interfaces in a bridge. But it was the mac of the CPE in the AP’s arp table that was changed.
ARP option is set to ‘enabled’ in all my routers. That always worked fine.
I don’t think someone is actually able to ‘hack’ into my network. Apart from a strong password protection and blocking of LAN adress ranges the wireless is NV2 with encryption.
I think some software bug must have caused it. I have seen it before in a unit. But I can’t reproduce it so I’ll guess I have to live with it… and hope it won’t happen again.