AXT1800 Blocked by ISP

Technical Support for Routers
21

Read my previous messages.

Other routers are working fine. Synology router had the same issue and I was able to bypass the block using the provided script. The question that I was trying to answer is how the detection is happening. Is it Mac Address check, TTL, DHCP Fingerprinting, or something else I am not aware of?

As I explained also before the solution was to put an L2 switch (instead of a direct connection between the socket and the wan port) without modifying anything else and then the Glinet router worked correctly. As admon also mentioned before it may be just faulty handling of the wan port with the Cisco router.

22

Which can be easily checked by switching LAN/WAN on a 1 Gbps LAN port. (Not that easily, because you need luci for it and the GL GUI is "broken" then - but for investigation it would be a good call)

23

Do you know any ISP customer that uses ISP router?

  • check first three bytes of such router MAC
  • check if such router has TR-069 enabled
  • any VLAN tagging used
  • check TTL in HTTP headers (Cache-Control: max-age=????)
  • any PPPoE used?

If your ISP would be using MAC whitelisting, you would not pass with Synology's original MAC, and cloning first three bytes to match ISP router maker would probably not be significant either.

24

I can test that. But i just checked again on Glinet website the AXT1800 ports are all 1G and none of them is 2.5G

25
  • Provider Gateway Prefix: 002a6a Cisco
  • Can you elaborate more about this TR-069
  • Nope there is no VLAN
  • Checked my outgoing packets, all with 64 TTL (I explicitly forced that using iptables)
  • Nope just DHCP config (you must config your own access point to get specific static ip, gateway and dns)
26

Ah, true. I was thinking about the Flint 2, because this issue happens there often.

You could try to run tcpdump to see if there are any handshakes or something.

27

TR-069 is about ISP Remote Management of routers which is another way of ISP recognizing the hardware at remote customer location.

Regarding TTL, you should capture packets (tcpdump, wireshark, ...) while surfing the web using ISP official router where no limitations are imposed. There you could learn or confirm again if anything changed in between. We never know, your previous router could pass the control checkpoint and somehow you encountered no more problems. Now you are trying to do the same with new router but something could change on the network (ISP side) in between.

Regarding DHCP - just to clarify due to your use of word "static" in the context but you might already know this:

A. If you are manually entering static ip, gw and dns on your WAN interface then WAN interface sends no DHCP request and ISP DHCP server has no need to respond to anything.

B. Limitation imposed after DHCP communication takes place makes sense only if your WAN interface is configured to use DHCP in order to get ip addresses assigned by ISP DHCP server. Only then an exchange takes place. Those ip addresses are rather called dynamic and not static.

28

The only thing they will see on a GL device is that it's not an ISP managed router.

TR-069 isn't enabled nor supported.