Firmware 7.0.1 build 3414 incorrectly identifes connected clients

Hi all,

I updated my Balance 30 to firmware version 7.0.1 build 3414, which seemed very good at the time because my maximum throughput went from around 100 Mbps to over 140Mbps. That was great, but now I am noticing that all clients that are connected via wireless bridges are either incorrectly identified, or they aren’t in the list at all. Here is a screen shot:

The “ENS200EXT at 2003” entries make it look like there are three client bridge devices, but in reality there is only one: The MAC for all three IP addresses is in fact that device, but the router is making it look like the same MAC has been assigned three different IP addresses. What’s actually happening is that devices that are connected to the wired LAN behind the wireless bridge have those IP addresses.

Nothing in our third building (also connected via wireless bridge) shows up in the list at all, and yet they got IP address from somewhere. It makes it really hard to see what’s going on. This looks like a bug to me, but could I be missing something?

I would very much appreciate some help with this.

Thanks,
-Mark

I suspect something happens on the bridge. Please do me favor below.

  1. Please confirm the actual MAC address for 192.168.0.18, 192.168.0.28, and 192.168.0.34.
  2. Login to Balance 30.
  3. Enter this URL - http://LAN_IP_of_Balance_router/cgi-bin/MANGA/support.cgi.
  4. Navigate to Network Capture > Start. Recommend to do this at Non-peak hours. Our device does have the limited buffer.
  5. Perform ping test from 3 IP addresses in step 1 to Balance 30’s LAN IP.
  6. Navigate to Network Capture > Stop > Download.
  7. Please confirm the MAC address for the 3 IP Addresses from the Pcap file. If the MAC address for the 3 IP Addresses is same. Please check on the bridge.

corrupted post

I was able to accomplish a subset of what you asked. I have no easy way to know which IP addresses go with any given device, so rather than trying to manually determine the IP address of every device in that building, I just connected to the network in that building with my laptop.

When I did that, the router showed the IP address that my laptop got handed via DHCP as if it was the wireless bridge. I then started the network capture per your instructions and then pinged the IP of my laptop using the router’s ping function. I stopped the capture and downloaded the file, but it was compressed in a format that is not native to Windows.

I went so far as to download an app that could open a .tgz file, but then found that there was a .tar file within the .tgz. I managed to extract that file as well and found a .pcap file within, but I don’t have anything that can make any sense out of that file, so I don’t know how to go any farther.

With that said, what is the goal here? If we were just trying to prove that the true and correct identity of the IP addresses are hidden behind the wireless bridge, then I believe we have already done that. But please, please let me know where to go from here.

Thanks,
-Mark

I’ve also noticed that the Client List is rubbish regarding wireless clients since upgrading to 7.0.1 on my MK3 SOHO, especially ones connected through range extenders.

My experience with range extenders varies by manufacturer. A lot of extenders dont work in a bridge mode and instead have their own DHCP pool, making connected clients invisible. Others mask the MAC address and still pull an IP address from the main router but all the devices show their MAC as the MAC of the extender.

I understand what you’re saying, but the only thing that changed about my network configuration was that I updated the firmware on the Balance 30. Everything else is as it has been, It worked as expected until just now, so I almost have to believe it is because of 7.0.1.

For what its worth, all of the wireless network hardware, both the access points and the client bridges are EnGenius, and they have always worked very well together. And with the Peplink router, for that matter.

If there is a good chance that Peplink will respond with a fix, then I’ll try to hang in here for a while with this firmware version so that I can help, but if not, I’m going to have to find some way to get back to a stable version, because it’s pretty much impossible to monitor and administer a network of any size without being able to tell who/what is actually connected.

I’ve seen the same unpredictable behavior with consumer-grade Wi-Fi extenders, but to be clear, I am not using range extenders, as such. I’m connecting wired LANs to my commercial-grade outdoor access point with commercial-grade outdoor wireless client bridges. EnGenius certainly has their issues, but the particular hardware mix that I have now has been reliable.

And again, this has all worked great for some years now, so it is not a case of inherent malfunction. Clearly, the router firmware has a lot to do with how well it all works together, because nothing else has changed for a good while now.

@MrMark and @mjburns

The client list only displaying the MAC address learned from the network. Base on the screenshot given initially, we suspect that bridge device (00:02:6F:F8:7D:E2) is responding the network that IP address 192.168.0.18, 192.168.0.28 and 192.168…0.40 is belongs to the device.

Steps given by @TK_Liew is to capturing the network packets and confirming the MAC address. Seem you have difficulties to read on the captured results, please open a support ticket here and submit the captured results for support team to review.

The wireless bridges do have a “Client Router” mode, which would presumably hand out IP addresses to clients, and potentially hide them from the Balance 30, but they are not and never have been configured like that - they are in “Client Bridge” mode, and once again, these are the same wireless bridges and the same configuration that has been faithfully passing the client MAC addresses until I updated to firmware version 7.0.1 build 3414.

I just submitted a ticket with the pcap file.

Thank you,
-Mark

Did you guys get my upload? Any thoughts?

Yes, we received the support ticket (#774679), will follow up from there on.

For what it’s worth, I rebooted with firmware 5.3.12 build 1303, and it behaves properly, so there can be no doubt that the problem is related to the new firmware. But now I’m using old firmware, so there are other issues with it, not the least of which is that the throughput is much worse than with 7.0.1 build 3414, so I hope you guys can make the newer one handle client identification as well as the old one.

From the packet captured logs, we found that the bridge is responding the ARP upon other IP address . We will followup with you using support ticket as we should not share the MAC address info publicly.

Understood. Thanks.