NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Schema of a Smart Home: One IP => Multiple MACs
I use an XR700 router with a EX8000 extender. They were expensive and I hope that they would provide my household a few more years of service.
I want to use TP-Link Smart Plugs (Kasa brand) because TP-Link offers great control API's. I need to get confirmations about on/off events and either retry or alert if there is a problem. This plug runs a pump, so it is important for my home automation to have certainty on plug events and status.
In order to use these devices and API's, all I need is a fixed IP address for the plug. Easy, right? Huh!
I have heard others folks here with similar requirements for knowing a device's IP address and they have been struggling for longer than I have with the history: Netgear, along with a few other companies, broke the 1:1 association between the physical interface and a MAC address in order to improve WiFi extender performance. They introduced the Virtual MAC addressing.
The problem is that Netgear has not updated their router logic to accommodate this new 1:M schema and it has remained broken for years. As smart devices and control mechanisms proliferate, Netgear will need to fix only one thing to allow these smart objects flourish within their networks, a second MAC address for one IP address:
I honestly believe that these services will only support dumb homes until this self-inflicted wound has healed. The logic required for this firmware update is not so expensive to produce. NETGEAR, please do it to keep your products and networks on-line and your customers happy!
I notice in DumaOS, that a "client device" can be listed with multiple MAC addresses. So, there must be some logic that supports a 1:M schema at least by "device name" that might be formally defined an extended to the reservation table structure:
12 Replies
Definitive illegal to have one IP address with multiple MAC. The mess is predictable once both MAC addresses appear on the same L2 network. All alerts must ring in case the same IP address appears with different MAC addresses!
The reason why Netgear (and other makers of legacy extenders) implementing what is designated as MAC translation is key of that specific design, because the same MAC address should never appear on what are different interfaces. It was not chosen to make our life hard, it was selected to keep things easier with the implementation. Technically, these extenders are not bridges, but much more streamlined L2 NAT routers - and behave completely independent to the IP addresses.
Those routers resp. their DHCP servers which allow to define multiple MAC addresses on the IP-MAC work on the (wrong!) expectation the same device has always the same IP address - completely misleading, and prone to errors and mishaps.
The obvious reason why the MAC address must be unique is in the ARP protocol. So everything just to get some kind of *fixed" IP addresses? In the times of Bonjour, WS-Discovery, and multicast DNS a complete obsolete approach from the 1970ties when ARPANET (based on 1986 ideas) and IPv4 was designed.
schumaku wrote:Definitive illegal to have one IP address with multiple MAC. The mess is predictable once both MAC addresses appear on the same L2 network. All alerts must ring in case the same IP address appears with different MAC addresses!
One Mac for each IP was a great idea, but wasn't that law broken with the advent of Virtual MAC Addressing?
Of course this is already broken. My router already shows (see my second screen-shot) a device with one IP and two MAC addresses. We are indeed already living in the mess caused by the reality of two MACs per IP.
What does an industry leader, NETGEAR, offer as a solution to this problem that they co-invented?
That mess, specifically, is expressed as a device that can no longer be statically-addressed by MAC or IP.
Do you really suggest clients look for proprietary solutions to get a handle on a device, like a Bonjour name or an Alexa registry? Do I really want to hard code: "Alexa, Turn of the pump" ?!?
Many people have thrown up their hands and simply shut down the Netgear DHCP server because it provides no reliable device tracking. When you bring in secondary devices running DHCP and DNS, that's a whole new level of messiness, complication and unreliability. I think there is a better solution to be offered on the router and I hope someone is smart enough to invent it and implement it on hardware that I've already invested in.
From what you posted, those MAC addreses are different and displayed by the XR router as it sees it.
You don't need fixed or static IP addresses for your smart plugs I have one smart plug and it uses Dynamic IP addressing. Runs fine with there smart plug mobile app.
However, if the smart plug offers any kind of static IP addressing configurations, one could set a static IP address here ON the device that is OUTSIDE of the routers default IP address pool range. Then this static IP address won't change and you'll know what it is and where it's assigned too. Something I do with my XR700 currently.
I have a managed switch and Orbi router in AP mode. Both have static IP configurations on them and works fine.
Again as it's mentioned already, networking specs do NOT allow for same IP addresses to occupy or assign to same MAC addresses. This is to avoid IP addressing conflicts and networking connections from being properly made per device/MAC addresses.
The XR700 is EoL and not sure if NG is going to do any more development on it. I've asked about this and still up in the air. NetDuma has been running some beta testing for there side of the FW since they are the designers of that side of the FW. They don't addresses anything on the NG side from what understand. https://community.netgear.com/t5/Nighthawk-Pro-Gaming-DumaOS-3-0/NOTICE-NETDUMA-Beta-Firmware-for-the-NETGEAR-XR700-Router/td-p/2325277/jump-to/first-unread-message
I'm not sure how much more "messy" things could get when we already have 2 MAC addresses assigned to the same IP address?
For example, the EX8000 shows:
Now, what would break if the router allowed for a reservation table that had the same two MAC's for this single interface? If NETGEAR cannot share this info between the EX8000 and XR700, then just let me type it in myself and leave the responsibility with me with some words of caution. We all know that only one of these MAC's will show up on the link layer at any given moment. And, it's not like there is fencing put around every place users could mess things up on a router!
I used the term statically-addressed which was confusing - apologies. I only seek a dynamic DHCP assignment of an IP via some IP reservation mechanism. There is no static IP option on the Kasa smart plug (I would want to manage addresses centrally, anyway) and I do not want to use a smartphone app to operate plugs manually. Instead, I want to automate an "on" command for a pump when a container is getting full using a Node-Red interface. People like to automate stuff like this and are hitting this issue and building their own dnsmasq or moving to DD-WRT or proprietary mesh rather than leveraging existing standards and asking vendor to fix what they have broken.
Jamie-NH wrote:
Now, what would break if the router allowed for a reservation table that had the same two MAC's for this single interface? If NETGEAR cannot share this info between the EX8000 and XR700, then just let me type it in myself and leave the responsibility with me with some words of caution. We all know that only one of these MAC's will show up on the link layer at any given moment. And, it's not like there is fencing put around every place users could mess things up on a router!
To say it once again: The MAC translation in place on these old extender designs is key for it's operations. Sure, it does prohibit -any- common DHCP server implementation to assign the same IP address what are physically to different networks, on both sides of the extender (the wireless vs. the physical LAN port).
