My setup: Capsman running on an rb2011 connected to a cAP AC
RB2011
eth5->cAP AC
eth5->Vlan
Vlan->Bridge_Vlan
cAP AC
eth1->RB2011
eth1->Vlan
Vlan->Bridge_Vlan
Did some troubleshooting based on this guys advice and another’s recommendation to change Discovery to Ether1. In the end only setting Discovery on the Bridge_Vlan itself and nowhere else solved the potential looping issue for me. I hope this can help someone else out.
In our experience, that problem is caused by damaged ethernets. The ethernet maybe working or not, but the symptom is always the same, it links either it has a cable pluged or not (I mean that the link led is turned on even if the ethernet does not have a cable pluged).
Of course you also have to consider a real loop as a possibility
This many people not a coincidence. Happened to me too.
In my case it was caused by MAC conflicts caused by Virtual WLAN interfaces, that are created sequentially.
So if you have 2-3 routers that have been purchased together, their MAC address are very close, so creating 4-5 Virtual adapters on each will cause them to overlap.
Check them out.
My solution:
Instead: Byte 2+3 are free to be changed.
I set bit 1 of the 1st byte like You do:
4C:5E:0C:81:CF:8E becomes 4E:5E:0C:81:CF:8E
THEN, when I add more virtuals, I change bytes 2+3. Since we are using locally administered macs, nothing is stopping us from changing them.
Since i am not changing the last 3 bytes, they are guaranteed to be unique:
Example:
4E:00:01:81:CF:8E
4E:00:02:81:CF:8E
4E:00:03:81:CF:8E
4E:00:04:81:CF:8E
Problem shown below:
Router 1:
[pit@HTP Reception] > int pr
Flags: D - dynamic, X - disabled, R - running, S - slave
0 R ether1 ether 1500 1600 4076 4C:5E:0C:81:CF:8E
1 wlan2 wlan 1500 1600 2290 4C:5E:0C:11:10:83
2 S wlan2-100 wlan 1500 1600 2290 4E:5E:0C:11:10:83
3 S wlan2-101 wlan 1500 1600 2290 4E:5E:0C:11:10:84
Router 2:
[pit@BB7 LaererV] > int pr
Flags: D - dynamic, X - disabled, R - running, S - slave
0 R ether1 ether 1500 1600 4076 4C:5E:0C:82:8D:00
1 wlan2 wlan 1500 1600 2290 4C:5E:0C:11:10:7F
2 S wlan2-100 wlan 1500 1600 2290 4E:5E:0C:11:10:7F
3 S wlan2-101 wlan 1500 1600 2290 4E:5E:0C:11:10:80
4 S wlan2-102 wlan 1500 1600 2290 4E:5E:0C:11:10:81
5 S wlan2-103 wlan 1500 1600 2290 4E:5E:0C:11:10:82
6 S wlan2-104 wlan 1500 1600 2290 4E:5E:0C:11:10:83
7 S wlan2-105 wlan 1500 1600 2290 4E:5E:0C:11:10:84
8 wlan5 wlan 1500 1600 2290 4C:5E:0C:82:8D:01
Well, receiving a packet with same mac address is definitely a loop. The issue here is how to analyze the loop apart from the obvious checking mac addresses of the interfaces.
In my opinion this is related whenever you have bridge interfaces created, be it STP, RSTP or none. The learning of the mac-addresses from the bridge might be causing the issue.
But we need a better tool to understand and analyze properly the issue.
Is there someone in the network spoofing mac addresses?
Does Neighbor Discovery receive invalid packets?
Does Detect Internet causes issues?
Is the bridge interface itself generating invalid packets?
Probably is admin Mac address that causes the loop.
Try to set one instead of auto mac, for example I set ether1 Mac as admin Mac on AP and wlan1 on station
I decided to update my hAP ac Lite to 6.43.7 today.
It is running for more than 12 hours now and I haven’t noticed any message in the log about this issue. I don’t have a remote syslog to save all logs, but it looks like the issue is solved. Also, looking at versions change log Mikrotik has made some substantial changes to the bridge.
Anyway, will keep you posted if the issue appears again after this update.
Great advice I have changed my virtual wlans so they are more distinctly different from the WLANs.
If have an AP with two WLANS is it okay to change them too, so they are clearly distinct from each other ???
I noticed that my vlans all have the same mac address, but the vlan attached for the ISP does not. Assuming all vlans on a bridge get assigned same mac address?
You can change MAC addresses where ever you want. Just keep them distinct. The important thing is to have different MAC addresses for VAPs … if VAP has same MAC address as AP, it just won’t work (although it might seem to be fine from configuration point of view).
.
VLANs share MAC address of a physical port. In a switch/bridge configuration, switched ports don’t need MAC address at all, because MAC address is only needed as base of L3 operation. Hence when multiple ether ports are bridge in RB, all ports will seem to be using bridge’s MAC address (whichever that might be). Combined with first sentence in this paragraph … you have all LAN VLANs using MAC of the bridge. I assume WNA port is not member of the bridge, hence it uses its own MAC address.
I configured WAN to run over VLAN (actually it’s untagged, but it’s ingressing on a port with PVID set) over ethernet port which is member of unified bridge … so in my case WAN uses same MAC address as LAN. VLAN tagging keeps L2 separation.
Thanks, I did change my WLAN mac addresses as well and then lost all wifi connectivity on those WLANS, so I only changed the VWLAN ones. 
original post was created “Sat Feb 11, 2017”. that’s almost two years ago today and nobody seems certain about this issue. it’s not isolated. any hotshots?
Hello all, I have come across this problem myself, what happens is its the clients end, you normally see a MAC Provided address and what interface or in this case if your using the Wireless its going to say bridge. You will have to track down the client down with their MAC address and get there IP Address. If you have Access Point radios, you can start there and look at the MAC address in the Tools and Networks. Typically they will be listed there with there IP address the AP shows and there MAC. The clients end radio device is whats wrong, what the problem was in most cases the radio device (wireless device) the client had went bad, typically after a bad storm and they got hit by lighting and screwed up the equipment. Other times its because the client would plug the incoming internet port into a LAN port instead of the internet ether port.
Happens fairly often for me, seem to be something to do with Capsman, and only my one AP does it the other AP’s seem ok. Rebooting my RB2011 seems to fix it but only for a few hours.
ether10: bridge port received packet with own address as source address (4c:5e:0c:00:00:00), probably loop
I’ve got the same problem.
STP definitively BLOCKs the Loop in my infrastructure.
The message “bridge port received packet with own address as source address” disappears as soon as I disable neighbor discovery.
So I suspect that either Neighbor discovery is broken, or that STP-Blocked Ports still transport MNDP-Packets.
Is bridge’s MAC same as any member ports MAC (including ethernet and wifi ports)? If yes, try to change bridge MAC to some unique number (add 2 to second digit of MAC … if MAC starts as 4c:5e:0c, change it to 4e:5e:0c).
Already done.
All MACs are unique
i had changed the bridge admin mac address, but the problem still exist.
routerboard: yes
model: 2011UiAS
serial-number: xxxxxxxx
firmware-type: ar9344
factory-firmware: 3.41
current-firmware: 6.42.1
upgrade-firmware: 6.42.1
holy f**ckamolly. this issue has been around for ALMOST THREE YEARS NOW! whatever happened to all those supposed MikroTIk hotshots out there??? what with all the MTCNA, MTCRE and and sorts of bllsht certs you got but can’t find a fix for this loop problem???
firstly - no certification (does not matter if cisco or mikrotik or anything else) guarantee that person is bright and creative. It just means that (s)he was able to pass the test. Nothing else.
secondly - troubles with suspected loops can’t be easily fixed remotely. It would take ages to ask question, wait, think, ask another question etc.. Unless it is obvious and common trouble, easiest and fastest way is to hire skilled person who will run around for few hours with sniffer and by the end of the day, it will be fixed.
Then you read things like
I suspect that…
Excuse me but WHAT?? Someone with issue suspect? tap the network, sniff the data, confirm/reject suspicion. You don’t need MTCNA to come up with this. Its common sense.