Slate Plus GL-A1300 WAN connection problem

Technical Support for Routers
1

Hi.
I recently purchased an AC1300 as a backup for my main
router. But I can’t seem to connect it directly to the Internet provider (Ethernet cable).
Almost all default settings (Admin Panel v4.1.0)
When connecting the WAN port through the LAN port of the main
router is Ok. The local IP address is determined. Access to Internet is Ok.
When connecting the WAN port directly to the Internet provider,
instead of the main router, it cannot get an IP address
In the logs only -

Sat Dec  3 17:58:52 2022 daemon.notice netifd: Network device 'eth1' link is up
Sat Dec  3 17:58:52 2022 daemon.notice netifd: Interface 'wan' has link connectivity
Sat Dec  3 17:58:52 2022 daemon.notice netifd: Interface 'wan' is setting up now
Sat Dec  3 17:58:52 2022 kern.info kernel: [  923.771968] ess_edma c080000.edma eth1: Link is Up - 1Gbps/Full - flow control off
Sat Dec  3 17:58:52 2022 daemon.notice netifd: wan (25533): udhcpc: started, v1.33.2
Sat Dec  3 17:58:52 2022 daemon.notice netifd: wan (25533): udhcpc: sending discover
Sat Dec  3 17:58:56 2022 daemon.notice netifd: wan (25533): udhcpc: sending discover
Sat Dec  3 17:58:59 2022 daemon.notice netifd: wan (25533): udhcpc: sending discover

And if you log in via SSH and give the command
udhcpc -i eth1
external IP address is determined

What could be the problem?
Thanks

2

Some providers lock the (single external) IP to the first device that connects to the modem on startup. Try disconnecting both routers, then restart your modem and plug the A1300 in to see if you get an address. Note that you’ll also have to restart the modem to switch back to the other router if that works.

3

So I did too.
My provider works with MAC address of device
I copied MAC address. And uhdcpc -i eth1 determines correct my external IP.
So provider is responsible.
I have a feeling that udhcpc is running without -i eth1 parameter, but I can’t check and fix it

4

Solved a problem.
Provider did not accept DHCP packets requests
If they did not have parameter ‘ether’ with MAC
I had to add line to file ‘network’ section ‘wan’
option clientid ‘01:xx:xx:xx:xx:xx:xx’

1 Like
5

That is a very common case that the ISP locks the MAC address.

I’d like to give a summary.

So when you change to a new router, you need to do one of the following:

  1. Clone your old router’s mac address to the new router. It should just work as in this case. But if you do not want to clone mac, then,
  2. Just reboot your ISP modem. This works sometimes, but not always.
  3. Turn off the ISP modem for sometime, e.g. one hour and turn it on again. It will accept new MAC. This is our case when using Huawei modems.
  4. Just call your ISP and tell them you want to change router, ask them to reset the modem for you. Sometimes you need to do the method 2 and 3 as well.
  5. In very rare cases (e.g. we got a case about Virgin and Talktalk in the UK), you can only use the ISP router. While we don’t know exact how it works but suggest you fight with them to use new routers.
1 Like
6

I cloned MAC address with ADMIN Panel
It wasn’t enough
Here is DHCP query after that

00:21:39.059471 Out MACnew ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from MACnew, length 300, xid 0xe8f3c32e, secs 241, Flags [none]
          Client-Ethernet-Address MACnew
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 8:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP, Classless-Static-Route
            Vendor-Class Option 60, length 12: "udhcp 1.33.2"
            Client-ID Option 61, length 1: hardware-type 96,

And here is DHCP query after adding this line

00:52:03.601468 Out MACnew ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from MACnew, length 300, xid 0xc360aa71, Flags [none]
          Client-Ethernet-Address MACnew
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
--->        Client-ID Option 61, length 7: ether MACnew
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 7:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP
            Vendor-Class Option 60, length 12: "udhcp 1.33.2"

see the difference

Cloning MAC with old ASUS router gives 2 results

7

Yes you are right. Clientid is an different option.

8

How do you find out? Does ISP give some instructions?
Can you share the ISP for reference?

9

The provider did not help me.
But I was wondering why ssh command - ifdown wan; ifup wan
IP was not received, but ssh command - uhdcpc -i eth1 - was received IP.
And then tcpdump + google.com
And I saw that this is a big problem.
These 2 quotes helped -

DHCP Client Option 61 (dhcp-client-identifier)

The default, when the interface "Hostname" is not specified, sends the MAC address as the client ID. 
This can be troublesome when replacing a router.

Some ISP DHCP implementations require the same client ID unless the lease has been released or expired. 
But some routers don't send a client ID or send something other than the MAC. 
So simply spoofing the MAC doesn't work. 
Since OPNsense doesn't have a provision to release the lease this can force a long wait for the lease to expire or contacting the ISP, and probably escalating to technical support, for them to release the lease from their end.

Don't think it is a good practice, on a router that doesn't support DHCP release, to send a default client ID (a CID not explicitly configured). 
Such as is done by setting the "Hostname" for the interface.

A possibly related issue could be that the ISP is relying on a combination of MAC of the DHCP requestor AND the 'Client ID' (DHCP Option 61) for their lease management.

I note that when I WireShark the WAN handshake from a Netgear, it provides the MAC of the WAN port in the option 61 of the DHCP request.

By default, OpenWRT does NOT populate that field.

BTW- You must enter the 'Client ID' in HEX, and the first two characters (i.e first byte) must be '01' (zero one), usually followed by the hex values of the MAC, minus the colons or dashes.
So if the MAC is: AB:CD:EF:01:02:03 The correct Client ID is '01ABCDEF010203'

Client ID is under Network->Interfaces, click 'Edit' on the WAN, then click 'Advanced Settings' sub-tab.
1 Like