[Solved] WRT3200ACM fresh 23.05.04 install, no DHCP on WAN

Hey everyone, I'm using a WRT3200ACM.

I've used 19.07.3 and 22.03.0 in the past with no problems. A power surge messed up the 22.03.0 install, so I've reflashed that partition with 23.05.04 (no config preserved).

So at this point, I have a fresh 19.07.3 install (I performed a reset on the config) on one partition, and a fresh 23.05.04 (no config preserved) on the other partition.

The problem is, with the 23.05.04 version, the WAN interface doesn't get an address and thus it can't access the Internet. DHCP works fine on the 19.07.3 install.

I'm not sure of the meaning of the config differences between the versions, but it looks like in 19.07.3 the wan interface is on ifname 'eth1.2', whereas in 23.05.4 it's using a separate device called wan that's configured with the same MAC address as the eth1.2 device is using in 19.07.3.

Looking for log messages about dhcp, 19.07.3 has this:

Sat May 16 18:32:39 2020 daemon.notice netifd: wan (2122): udhcpc: sending discover
Sat May 16 18:32:39 2020 daemon.notice netifd: wan (2122): udhcpc: sending select for (address from ISP)
Sat May 16 18:32:39 2020 daemon.notice netifd: wan (2122): udhcpc: lease of 67.183.30.233 obtained, lease time 49226

But on 23.05.4, it says:

Mon Jul 15 22:14:51 2024 daemon.notice netifd: wan (2887): udhcpc: started, v1.36.1
Mon Jul 15 22:14:51 2024 daemon.notice netifd: wan (2887): udhcpc: broadcasting discover
Mon Jul 15 22:14:54 2024 daemon.notice netifd: wan (2887): udhcpc: broadcasting discover
Mon Jul 15 22:14:58 2024 daemon.notice netifd: wan (2887): udhcpc: broadcasting discover

Any ideas about what the problem is here? I'm not sure what else to do here besides walk back through older firmware versions until something works.

You should actually upgrade to 23.05.5. But that's besides the point.

There is a reasonable probability that the MAC address on the wan is not consistent between the two partitions. This means that the upstream sees this as a different device. And, it seems likely that you are on a cable modem based service and/or your ISP 'learns' a single MAC and refuses to issue an IP to a different MAC address until the learned association is cleared.

There are two methods to resolve this:

  1. Clone the WAN MAC address as reported in one partition (i.e. 19.07.3) to the other (23.05.5).

or

  1. Reboot your cable modem, possibly a few times. A good sequence is to unplug both the modem and the router from power and unplug the ethernet cable from the router's wan. Power the cable modem and allow it to fully boot, then unplug it again. Do this 2 more times, and then leave it plugged in. Power up the router next, let it fully boot, and then connect the ethernet cable.

This is one of the possibilities, and rather easy to check (as in compare the output of ip a between both versions, yes it's going to look considerably different anyways, but the MAC addresses are easy to check).

Comparing /etc/config/network from both versions (paste both) would be the next step, yes they will be totally different as well - but the gist is still easy to check.

1 Like

It does sound like a MAC issue. I had already checked that they were using the same MAC address, but I'm sort of confused between devices and interfaces here and how they're working differently between the versions, so maybe I'm not looking in the right place. In any case, I think the MAC address that the ISP is liking under the 19.07.3 firmware is 32:23:03:dc:a3:a0, and here are the config files and "ip a" results.

Here's the /etc/config/network file from the 19.07.3 version:

config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fde6:db03:71b5::/48'

config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

config interface 'wan'
option ifname 'eth1.2'
option proto 'dhcp'

config interface 'wan6'
option ifname 'eth1.2'
option proto 'dhcpv6'

config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 5t'

config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4 6t'

.. and here's ip a from the 19.07.3 version:

root@OpenWrt:/tmp# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 532
link/ether 30:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3223:3ff:fedc:a3a0/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 532
link/ether 32:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3023:3ff:fedc:a3a0/64 scope link
valid_lft forever preferred_lft forever
5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 30:23:03:dc:a3:a2 brd ff:ff:ff:ff:ff:ff
6: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 30:23:03:dc:a3:a1 brd ff:ff:ff:ff:ff:ff
7: mlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 30:23:03:dc:a3:a3 brd ff:ff:ff:ff:ff:ff
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 32:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fde6:db03:71b5::1/60 scope global
valid_lft forever preferred_lft forever
inet6 fe80::3023:3ff:fedc:a3a0/64 scope link
valid_lft forever preferred_lft forever
9: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
link/ether 32:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
10: eth1.2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 30:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
inet (ip from the ISP)/22 brd 67.183.31.255 scope global eth1.2
valid_lft forever preferred_lft forever
inet6 fe80::3223:3ff:fedc:a3a0/64 scope link
valid_lft forever preferred_lft forever

Now here's the /etc/config/network file from 23.05.05 (I switched to .05 instead of .04):

config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'

config globals 'globals'
option ula_prefix 'fd5f:8779:9156::/48'

config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'

config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

config device
option name 'wan'
option macaddr '32:23:03:dc:a3:a0'

config interface 'wan'
option device 'wan'
option proto 'dhcp'

config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'

.. and the ip a from the 23.05.05 version:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP qlen 1024
link/ether 30:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3223:3ff:fedc:a3a0/64 scope link
valid_lft forever preferred_lft forever
3: lan4@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
link/ether 30:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
4: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether 30:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
5: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether 30:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
link/ether 30:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
7: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 32:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3023:3ff:fedc:a3a0/64 scope link
valid_lft forever preferred_lft forever
8: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 30:23:03:dc:a3:a2 brd ff:ff:ff:ff:ff:ff
9: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 30:23:03:dc:a3:a1 brd ff:ff:ff:ff:ff:ff
10: mlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 30:23:03:dc:a3:a3 brd ff:ff:ff:ff:ff:ff
11: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 30:23:03:dc:a3:a0 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fd5f:8779:9156::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::3223:3ff:fedc:a3a0/64 scope link
valid_lft forever preferred_lft forever

The MACs were reversed, put the one from the new version into the 19.x, as the new MAC is what will be there post 19.x. Or just gash the 19.x and flash a snapshot if the radios are important to you.

Thanks for the quick reply and excuse my n00bness, but I'm confused. If I change the MAC address, will I need to somehow induce the ISP to accept the new MAC address? How would I do that?

And which one should I go with? It looks like the 19.07.3 version is using 30:23:03:dc:a3:a0 on the eth1.2@eth1 interface, and the ISP is happy with that.

The 23.05.05 is using 32:23:03:dc:a3:a0. So is that latter one (32:23:03:dc:a3:a0) the one that I want the ISP to start accepting?

Most cable modems can just be bounced to accept a new MAC, YMMV.

At least for cable modem services in the US, a simple bounce is not usually sufficient... a power cycle is typically required (sometimes a few times). Hence my suggested procedure:

bounce == (power down / power up)

Often bounce (on this forum) will refer to an ethernet up/down cycle, which is why it is worth explicitly stating that it is a power bounce.

To me bounce means one thing, whether here, or the decades I spent working in the SW world; power DOWN / power UP. So now you want to argue semantics, why am I not surprised.

No need to be combative here. Ensuring that the language we use is precise and not subject to mis-interpretation due to a person's personal context is really important. I'm not arguing that a power-cycle isn't equivalent to a bounce, but in my context, if someone tells me to bounce a device,'s connection, I'll interpret it as the ethernet port disconnect/reconnect cycle. I'll disrupt power if they call it ask me to "power cycle" the device. There's nothing wrong with your use of bounce for power, but it's not universal, that's all.

Thanks for all the help. It definitely is the mac address. I tried to get the ISP to accept the new mac address by powering off modem+router for 10 minutes, turning the modem on and letting it connect, then turning the router back on. That didn't work, so maybe I'll try it a few times.

As a separate test, I tried swapping the mac addresses on br-lan and wan in the /etc/config/network file to end up with:
br-lan: 32:23:03:dc:a3:a0
wan: 30:23:03:dc:a3:a0

.. and the ISP liked that, so I was finally able to get to the Internet with 23.05.05. Is there any disadvange to just leaving things as I have it here, or would you recommend trying a little harder to get the ISP to accept the new MAC address (like doing what you mentioned, and power cycling the modem a few times instead of just once)?

1 Like

It is always worth using latest stable release, for even seemingly minuscule bug and security fixes.

Both approaches are valid. Just remember this MAC address issue if you ever reset the device to defaults and then have issues with the ISP connection.

If you experience this in the future, you'll have another opportunity to choose to either fix MAC in the device or work with the cable modem to get it to accept the MAC that is presented.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! :slight_smile:

  • do you not think a person is capable of seeking clarification if post content is not understood.
  • do you feel the need to interject yourself into every conversation, I was not responding to you so your context was irrelevant.
  • I did not say to bounce the connection, I said the modem. If I was talking about ethernet connection I would have used something along the lines of resetting blah.
  • do you think everyone needs to reply as you would, and if not you are going to interject, that is rather combative and controlling in my book.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.