Slate 7 (GL-BE3600) showing up in Ubiquiti Network as a DD-WRT Router

We are trying to simulate the Slate 7 (GL-BE3600) connecting to other networks to see what a Public network Administrator will see the device to be. The first network we try (Ubiquiti) it shows up as a “DD-WRT Router”. If I was a network administrator and I saw DD-WRT Router on my list of clients I would ban it. I have tried every setting (and changed the MAC addresses on every setting change) but somehow the Ubiquiti Gateway still recognises it as a DD-WRT Router. I have asked tech support and they have no idea how this is possible. Does anyone know how this is happening or how to change it? (Firmware is 4.8.1)

It does not happen when connected to 2.4ghz or via Ethernet WAN. But I am surprised that I am getting different results with each different connection type:

5gHz WAN = DD-WRT Router

2.4gHz WAN = MAC ADDRESS (Randomized)

Wired WAN = Device Name

Hi

We noticed that you have already reached out to us by email regarding this issue.
Please continue working with our support team through the ticket system so we can assist you more effectively.

This post will remain open in case other users wish to share additional suggestions.

Hi Will, the team don’t know why the Slate 7 is doing this and they have advised me to post on the forum to see if we could get some community help…

Yes. Currently, there is not much information available. We are still discussing this internally, but there has not been much progress yet.

This thread will remain open to see if other users encounter similar situations and can provide any clues that might help.

I think the issue is the device signature Ubiquiti is using, not something GL should fix. This is all their doing, nothing GL should really need to do to fix Ubiquiti’s error imo.

Hi Packetmonkey, that is what we thought too, but we also tested the GL-AXT1800 and it doesn't do it. It shows up correctly as an “Unknown Device”.

Different versions of firmware on the same physical device can be detected with different fingerprinting, though. Differences in hardware, SDKs, kernel settings, protocol libraries, they can all impact how a fingerprinter detects them. But it is not the responsibility of the vendor to control how others detect their devices. You need to work with Ubiquiti to provide them all of the pertinent details of the device so they can tune their product. I just don’t understand expecting GL to do anything about this “issue.” I am not trying to be argumentative, it is just a fact.

Travel routers are supposed to be inconspicuous! Considering other GL-iNet devices operate this way, I am simply trying to find a way to make their most expensive travel router operate the same way as the rest in their lineup. Getting Ubiquiti or Cisco to change their networks defeats the point. Please do not reply unless you can help. If anyone has any useful insight it would be greatly appreciated.

I am helping you understand what the issue actually is. Just because you don’t agree doesn’t make me less correct. There is no “requirement” that a travel router be “inconspicuous” as you say. GL does make some attempts to be benign, but if you really want it to be more hidden then make sure NO ports are exposed externally and the router does not respond to or send ICMP traffic. If the only thing a connecting device externally can see is the traffic that is generated behind the router it won’t have much to go on.

I am done now, though, so please feel free to keep tilting at your windmill. I wish you the best of luck.