Have to reboot Modem after Rebooting E7350 router

Installing and Using OpenWrt
1

I recently got a Linksys E7350, and I've loaded it with OpenWRT. I'm running into a strange issue.

Every time after I reboot the router, it fails to connect to the modem on the WAN connection. I can't get it to connect by unplugging and re-plugging the Ethernet cable in, or by running ifup on the router, or disabling and re-enabling the WAN interfaces in LuCI.

The only way I have found to fix this is to then manually reboot the modem.
This was not happening with my previous router (A Netgear R7800), and I can't seem to find much else about people with this issue. The best I've found is a few posts suggesting that the router might be sending the LAN MAC Address during boot, and the modem then refuses to allow other MAC Addresses.

My question is twofold.

  1. Does that sound right?
  2. How can I fix this?

For reference, I am running OpenWRT 25.12.4

2

I forgot to mention, I'm running OpenWRT 25.12.4. I've updated the OP.

3

Sounds like no DHCP request from your Linksys after boot. Which is strange. Pls, provide system log, starting at boot, up to state without WAN connection. Just do 'logread > /tmp/log.txt' and provide file (use </> for it).

4

@reinerotto I have the log. Before I upload it, is there anything I should be censoring from it? Like client MAC addresses or something?

5

You might anon first part of the MACs. Final digits to remain, to differentiate.

6

@reinerotto The log is too big to fit in a post on the forum (its around 2-3 times the max character limit), so I have placed it in a GitHub gist instead: https://gist.github.com/marsfan/d390170be7d5573bfe5231d62f903bc9

There's two files. no-wan.log is from boot to me dumping a log without a WAN connection.
after-modem-reboot.log is after I rebooted the modem by unplugging and plugging it back in.

I've redacted MAC Addresses (excluding last bit), IPv6 addresses, non-local IPv4 addresses, hostnames, and ssh key stuff.

7

I think, the issue is here:

Fri May 15 23:31:51 2026 kern.err kernel: [    2.349047] mtk_soc_eth 1e100000.ethernet: generated random MAC address XX:XX:XX:XX:XX:00
Fri May 15 23:31:51 2026 kern.err kernel: [    2.357276] mtk_soc_eth 1e100000.ethernet: generated random MAC address XX:XX:XX:XX:XX:00

Modem switches to some type of bridged mode, according to after-modem-reboot.log . And remembers the WAN-MAC. When you reboot openwrt, MAC is changed, And modem or ISP ignore dhcp from this other MAC. You should verify this, by disabling MAC randomizing for WAN. BTW, how do you do this ?

Addendum: Hm, it might be a speciality of your MT7621 device. You might try to set a fixed MAC addrs for WAN in /etc/config/network. Something like

config interface 'wan'
option ifname 'eth0'

config device 'wan_eth0'
option name 'eth0'
option macaddr 'xx:xx:xx:xx:xx:xx'

8

Sorry, I'm a little confused. So what you are saying is that the WAN on the router is changing its MAC address on reboot, and the modem is ignoring this since it has "memorized" the previous MAC address?

Weird, I thought HW had fixed MAC addresses. I'll have to do some testing.

I'm going to have to do some digging, as I don't see an obvious setting in LuCI for this. Only a way to manually set the MA

9

Doing some Googling, this might be related, though its about br-lan.

10

Simpler is it, just to check the MACs after several reboots and compare.

goggling such issues might provide obsolete info, because of sw updates.

I.e. reboot, login via ssh, 'ifconfig eth0'

You are correct, usually MACs are fixed. But looks like, not for your device. I can not find MAC initialization in the sources for your device, mt7621_linksys_e7350.dts. Leaving it to 0, most likely. Thus, dyn init via randomize on boot. Feel free to file a bug, referencing this thread.

Randomized MACs usually for wireless, only, to avoid tracking.

11

Thanks. I'll look into it and likely file a bug based on what I find.

12

Ok. Its definitely randomizing the WAN mac address on each boot. I'll file a bug for that. Thanks for the help.

13

Great. I suspect, maintainer could not find details how to figure out real MACs on your device. Thus, it might take a while until fixed. If, ever. Assigning a fixed MAC yourself should be good work around.

14

MAC address is read from Config partition