Omada ER605 leaking MAC addresses on WAN interface
Omada ER605 leaking MAC addresses on WAN interface
My ISPs upstream CIsco switch is shutting of my connection because they are detecting multiple MAC addresses sending from my port. This is a brand new installation of the ER605. It is running in controller managed mode. Behind the ER605 is a few other non-Omada TP-Link switches and access points. I would like to upgrade to all Omada managed gear but this problem is going to force me to return the router and abandon the project if I can't find the solution.
The MAC addresses reported by the Cisco don't appear to be on my network. I don't see them listed as clients in the Omada client list or on the Deco client list. They are seamingly random although some have had the same vendor prefix AE:7F:D4:CF:XX:XX. I can't find any devices on my network with similar prefixes. It may be that this is a randomized MAC address. Even if these are randomized addresses, from something like an iPhone, why are they leaking out on the WAN port?
Any help would be appreciated.
Similar reported but unresolved issue: https://community.tp-link.com/en/business/forum/topic/598914
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Thanks for posting in our business forum.
Its-A-Trap wrote
@jake-at-home , Quite possible we are neighbors!
Quick update, with a few small caveats...
- My setup is slightly different than yours in that i have Two Internet connections. I added a XFinity cable modem as a backup when i thought that the issue was on the WaveG Side. I have been experimenting with maintaining both and with having only WaveG connected
- I have not yet set up the testing infrastructure to directly observe the mac address leaking, and am thus relying on observing my port being shut down, so the testing takes quite some time...
I need to do further testing, however at this point i am fairly confident that the issue is at least partially associated with the configuration of Hardware Offload. I am suspicious if there are either potentially multiple initialization code paths that results in different configurations, or if the IPs have some order dependent initialization requirements not being fully respected.
- Previously, My port would be shut off for approximately 11 minutes each time this defensive measure was triggered by the upstream switch. I would encounter this 11 minute gap every 20-30 minutes.
- After Disabling Hardware Offload (With only WaveG Active) my connection was stable for over 2 hours
- After Re-enabling Hardware Offload (with only WaveG Active) my connection continued to remain stable for over 2 hours.
- I then took a risk and re-enabled the second WAN/Lan port for my backup internet connection, after the system was re-provisioned, my system once again exhibited the disconnect behavior. This behavior did however seem to continue even when i disabled hardware offload (Confused on this one, and need to dig in more...)
- I was able to restore long term stability by unplugging my backup internet connection and disabling Hardware offload
I would like to get to a true root cause as I am sure that it will come back and bite me again soon, as if it is an artifact of the different initialization code paths or some other order of operations. I expect that this is not yet resolved. Also, I do not currently have a stable configuration that supports my second WAN.
In order to really make progress, i likely need to invest the time to setup an upstream switch to enable mirroring and capture so i can have a more reliable signal than waiting for my port to get turned off... that may be next weekend...
For both of you, please prepare a diagram of your current network connection.
I would require a traditional way of configuring your network on the Internet--WAN--LAN. If you have anything in between or double-NAT, please remove them before we move on this case.
As this goes on, I need you to reproduce this issue and Wireshark in a controlled environment instead of an unconventional setup. I will not reply to your message if this is not reproduced in a controlled environment as I cannot help you locate the problem.
Will walk you through this, dig out what's wrong and give this problem a conclusion.
A ticket will be created for each of you.
The port mirroring requires you to perform Wireshark capture. The file should capture and contain the leaked MAC address you mentioned or you see in the log.
Things I need:
1. A conventional diagram ruling out any local devices connected to the WAN.
2. Port mirroring and Wireshark from the WAN.
3. Log of your ISP modem or how you find out this MAC address leaked with evidence.
I need to know what you know about your network. Or it is hard to find out the reason why. And we probably need a real-time remote if this does not go well.
Reply to the ticket I created for you with the information mentioned.
- Copy Link
- Report Inappropriate Content
Hi @Its-A-Trap
Thank you so much for taking the time to post the issue on TP-Link community!
To better assist you, I've created a support ticket via your registered email address, and escalated it to our support engineer to look into the issue. The ticket ID is TKID240619566, please check your email box and ensure the support email is well received. Thanks!
Once the issue is addressed or resolved, welcome to update this topic thread with your solution to help others who may encounter the same issue as you did.
Many thanks for your great cooperation and patience!
- Copy Link
- Report Inappropriate Content
Thank you so much for taking the time to post the issue on TP-Link community!
To better assist you, I've created a support ticket via your registered email address, and escalated it to our support engineer to look into the issue. The ticket ID is TKID240619582, please check your email box and ensure the support email is well received. Thanks!
Once the issue is addressed or resolved, welcome to update this topic thread with your solution to help others who may encounter the same issue as you did.
Many thanks for your great cooperation and patience!
- Copy Link
- Report Inappropriate Content
@Its-A-Trap I might have had luck with updating to the latest firmware, ER605(UN)_V2_2.2.5 Build 20240522. I have since decided to go with another vendor, and will be returning my ER605, but about 3 prior to packing it up I installed this updated firmware. I didn't have any leaked packets for that period of time but I will caution that I had seen a period of time longer than this where no packets leaked on the older firmware. It may very well come back given more time. If you haven't tried it already you may want to try updating and see if you see similar and lasting results. Good luck!
- Copy Link
- Report Inappropriate Content
Hi anyone looking into this,
Not sure if this is related. Change TCP settings to 1800s. And monitor if there is a problem anymore. I ran across a case in the past and was recommended to set up all TCP-related settings in firewall to 1800s. Maybe give it a try.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1711
Replies: 15
Voters 0
No one has voted for it yet.