What's new

Proper way change MAC Clone entry via Telnet?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

PeaceNoWar

Occasional Visitor
Normally I would just manually type in a new MAC address then click Apply in the web UI but I'd really like to emulate those two steps via Telnet instead.

I think I've made good progress in figuring it out.
Here's an example of the commands I'm currently using:
Code:
nvram set wan0_hwaddr_x=12:34:56:78:90:AB
nvram commit
Those command work but I must be missing something because the result differs from manually entering the MAC address & clicking Apply.
The difference being that if I perform the steps manually, then cycle the power on my modem, it always takes around 60 seconds for my Internet connection to be fully restored, but if I run the above commands via Telnet then cycle power on my modem, the time it takes is sometimes around 60 seconds but more often around 140 seconds.

Any thoughts on what I might be missing?

Router: RT-N66U
Firmware: Merlin 378.56_2
 
Normally I would just manually type in a new MAC address then click Apply in the web UI but I'd really like to emulate those two steps via Telnet instead.

I think I've made good progress in figuring it out.
Here's an example of the commands I'm currently using:
Code:
nvram set wan0_hwaddr_x=12:34:56:78:90:AB
nvram commit
Those command work but I must be missing something because the result differs from manually entering the MAC address & clicking Apply.
The difference being that if I perform the steps manually, then cycle the power on my modem, it always takes around 60 seconds for my Internet connection to be fully restored, but if I run the above commands via Telnet then cycle power on my modem, the time it takes is sometimes around 60 seconds but more often around 140 seconds.

Any thoughts on what I might be missing?

Router: RT-N66U
Firmware: Merlin 378.56_2

How about inputting an arbitrary MAC into the GUI (ex. 00:00:00:00:00:00), then search for the arbitrary entry with “nvram show | grep '00:00:00:00:00:00'”?

Then you should find the nvram param you are looking for.
 
Thanks for the suggestion. That's actually how I found the variable wan0_hwaddr_x.
The MAC address is changing properly using that variable.
It's just that the 140-second delay tells me I'm missing something.
If I had to guess, I'd say that nvram commit isn't enough to properly/fully emulate pressing the Apply button. But I don't know.
 
Thanks for the suggestion. That's actually how I found the variable wan0_hwaddr_x.
The MAC address is changing properly using that variable.
It's just that the 140-second delay tells me I'm missing something.
If I had to guess, I'd say that nvram commit isn't enough to properly/fully emulate pressing the Apply button. But I don't know.

Oh. My bad.

There's a "service restart_wireless" command that might be what you want. Beyond that, I cannot offer much more help.
 
Thank you for the service restart_ suggestions.
I tried service restart_wan the other day but there was no improvement in the delay so I moved onto trying other things. I have a feeling it still might be part of a better/more proper way to emulate clicking Apply though. I'm starting to wonder if there is no universal command (or set of commands) for emulating the clicking of the Apply button, because clicking it does different things depending on what page you're on and what changes you made on the page. But I don't know.
I have wireless disabled on my router but I'll make a note of the service restart_wireless command for future reference.

It appears I've found what was causing the delay to usually be 140 seconds instead of 60.
After cycling power on my modem, I would wait 52 seconds then I'd start running the following command (via Telnet), about once per second, to determine exactly when my Internet connection was restored:
nvram get wan0_ipaddr
It appears that running that command was actually, usually, interfering with the router's ability to restore/reestablish my Internet connection. If I simply wait 65 seconds before I start running the command, I no longer encounter the 140-second delay; the delay is 65 seconds every time.

So, that mystery appears to be solved.
I would still like to know (for the sake of knowledge and doing things properly) if there is a more proper way to emulate the clicking of the Apply button after changing the MAC Clone address, or if using nvram commit is actually the best way to do it.

edit: It's back to delaying 140 seconds each time.
Ten times I tested the above theory, alternating back & forth between waiting 52 and 65 seconds. Each time, waiting 52 seconds resulted in a 140 second delay and waiting 65 seconds resulted in a 65 second delay. Now it's back to delaying 140 seconds virtually every time regardless of how long I wait. Bummer. Thought I had it worked out :(
 
Last edited:
I think you are misunderstanding how the NVRAM variables are used.

All "nvram commit" does is make any changes made to variables with "nvram set" permanent. Without it the changes would be lost on reboot. It does not make any immediate changes to the router. It is not the same as clicking the "Apply" button in the web UI. You have to reboot the router or restart a service to get the router to re-read the NVRAM variables.

NVRAM variables that end in "_x" tend to be used by the web UI as temporary variables with the values being copied to the non-"_x" version when you click Apply.

Also, bear in mind that if you change the WAN MAC address it will take a lot longer for the interface to come up the first time than subsequent times with the same MAC.
 
Collin has some good info. Basically every page Apply has two 'actions' associated with it. The first tells the system how to check and record changes to the data. The second initiates the router function to actually make use of the new data. Each of these actions can be changed dynamically depending on what the data is that is being changed. So, the Apply button doesn't do the same thing page to page, or even always do the same thing within a page.

Most of the time it's possible to change the NVRAM variables, commit and reboot....sometimes it may take more than one reboot.

I'm not able to test it right now, but a change in WAN MAC may also cause a change in the local interface MACs (they are usually coupled).

In this case, try adding a 'service restart_wan_if' command after the commit.
 
Last edited:
I think you are misunderstanding how the NVRAM variables are used.
All "nvram commit" does is make any changes made to variables with "nvram set" permanent. Without it the changes would be lost on reboot.
That's what I thought nvram commit did (though I didn't know if that was the full extent of what it did).
It does not make any immediate changes to the router. It is not the same as clicking the "Apply" button in the web UI.
Thanks for the confirmation that clicking Apply does more.
You have to reboot the router or restart a service to get the router to re-read the NVRAM variables.
I certainly don't fully understand how the router works but it does start making use of the new MAC Clone address after using nvram commit, without me having to restart the router. That's why my public IP changes (my ISP issues a new IP when the MAC address of the device connected to the modem changes).
NVRAM variables that end in "_x" tend to be used by the web UI as temporary variables with the values being copied to the non-"_x" version when you click Apply.
The opposite appears to be true in this case. Changing the value of the variable without the _x (wan0_hwaddr) seem to only have a superficial effect while changing the value of the variable with the _x (wan0_hwaddr_x) actually changes the MAC Clone address.
Also, bear in mind that if you change the WAN MAC address it will take a lot longer for the interface to come up the first time than subsequent times with the same MAC.
I'm using a different MAC address each time I set the variable.
 
Just to add:

You probably want to modify wan0_hwaddr and/or wan_hwaddr.

I've just realised that you're rebooting your cable modem after changing the NVRAM variables. In that case you shouldn't need to manually restart any router services because the routers "wanduck" service should detect it and automatically issue a "restart_wan_if 0".
 
Might it easier to just use curl and send the appropriate HTTP commands to emulate GUI interaction?
 
Might it easier to just use curl and send the appropriate HTTP commands to emulate GUI interaction?
The new firmware's login system would prevent that I think.

edit: Just realized you're probably referring to using curl via Telnet. I'm going to look into that now. Thanks!
update: I didn't have much luck with this. It might be possible with culr's --cookie option but I didn't get it working.
 
Last edited:
Here's some info from the router's system log:

Log when it took around 60 seconds for the Internet connection to be reestablished.
Code:
Dec 24 09:18:41 login[13603]: root login on 'pts/0'
Dec 24 09:19:09 WAN Connection: Ethernet link down.
Dec 24 09:19:14 WAN Connection: Ethernet link up.
Dec 24 09:19:14 rc_service: wanduck 218:notify_rc restart_wan_if 0
Dec 24 09:19:14 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 09:19:14 dnsmasq[231]: using nameserver 75.74.216.1#53
Dec 24 09:19:14 dnsmasq[231]: using nameserver 75.74.216.2#53
Dec 24 09:19:14 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 09:19:14 dnsmasq[231]: using nameserver 75.74.216.1#53
Dec 24 09:19:14 dnsmasq[231]: using nameserver 75.74.216.2#53
Dec 24 09:19:14 kernel: Attempt to kill tasklet from interrupt
Dec 24 09:19:14 kernel: br0: port 1(vlan1) entering disabled state
Dec 24 09:19:14 kernel: br0: port 1(vlan1) entering listening state
Dec 24 09:19:14 kernel: br0: port 1(vlan1) entering learning state
Dec 24 09:19:14 kernel: br0: topology change detected, propagating
Dec 24 09:19:14 kernel: br0: port 1(vlan1) entering forwarding state
Dec 24 09:19:16 wan: mac clone: [wan0_hwaddr] == [C6:A9:61:22:46:E9]
Dec 24 09:19:16 kernel: Attempt to kill tasklet from interrupt
Dec 24 09:19:16 kernel: br0: port 1(vlan1) entering disabled state
Dec 24 09:19:16 kernel: br0: port 1(vlan1) entering listening state
Dec 24 09:19:16 kernel: br0: port 1(vlan1) entering learning state
Dec 24 09:19:16 kernel: br0: topology change detected, propagating
Dec 24 09:19:16 kernel: br0: port 1(vlan1) entering forwarding state
Dec 24 09:19:16 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 09:19:22 WAN Connection: ISP's DHCP did not function properly.
Dec 24 09:19:52 rc_service: udhcpc 13619:notify_rc start_firewall
Dec 24 09:19:52 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 09:19:52 dnsmasq[231]: using nameserver 75.74.216.1#53
Dec 24 09:19:52 dnsmasq[231]: using nameserver 75.74.216.2#53
Dec 24 09:19:52 wan: finish adding multi routes
Dec 24 09:19:52 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Dec 24 09:19:52 rc_service: udhcpc 13619:notify_rc stop_upnp
Dec 24 09:19:52 rc_service: waitting "start_firewall" via udhcpc ...
Dec 24 09:19:53 rc_service: udhcpc 13619:notify_rc start_upnp
Dec 24 09:19:53 rc_service: waitting "stop_upnp" via udhcpc ...
Dec 24 09:19:54 dhcp client: bound 107.48.56.12 via 107.48.56.1 during 3600 seconds.
Dec 24 09:19:57 WAN Connection: WAN was restored.

Log when it took around 140 seconds for the Internet connection to be reestablished.
Code:
Dec 24 08:05:57 login[12305]: root login on 'pts/0'
Dec 24 08:06:24 WAN Connection: Ethernet link down.
Dec 24 08:06:29 WAN Connection: Ethernet link up.
Dec 24 08:06:29 rc_service: wanduck 218:notify_rc restart_wan_if 0
Dec 24 08:06:29 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 08:06:29 dnsmasq[231]: using nameserver 75.74.216.1#53
Dec 24 08:06:29 dnsmasq[231]: using nameserver 75.74.216.2#53
Dec 24 08:06:29 kernel: Attempt to kill tasklet from interrupt
Dec 24 08:06:29 kernel: br0: port 1(vlan1) entering disabled state
Dec 24 08:06:29 kernel: br0: port 1(vlan1) entering listening state
Dec 24 08:06:29 kernel: br0: port 1(vlan1) entering learning state
Dec 24 08:06:29 kernel: br0: topology change detected, propagating
Dec 24 08:06:29 kernel: br0: port 1(vlan1) entering forwarding state
Dec 24 08:06:29 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 08:06:29 dnsmasq[231]: using nameserver 75.74.216.1#53
Dec 24 08:06:29 dnsmasq[231]: using nameserver 75.74.216.2#53
Dec 24 08:06:29 wan: mac clone: [wan0_hwaddr] == [26:62:B8:C7:4F:DC]
Dec 24 08:06:29 kernel: Attempt to kill tasklet from interrupt
Dec 24 08:06:29 kernel: br0: port 1(vlan1) entering disabled state
Dec 24 08:06:29 kernel: br0: port 1(vlan1) entering listening state
Dec 24 08:06:29 kernel: br0: port 1(vlan1) entering learning state
Dec 24 08:06:29 kernel: br0: topology change detected, propagating
Dec 24 08:06:29 kernel: br0: port 1(vlan1) entering forwarding state
Dec 24 08:06:29 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 08:06:35 WAN Connection: ISP's DHCP did not function properly.
Dec 24 08:06:40 WAN Connection: Ethernet link up.
Dec 24 08:06:40 rc_service: wanduck 218:notify_rc restart_wan_if 0
Dec 24 08:06:40 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 08:06:40 kernel: Attempt to kill tasklet from interrupt
Dec 24 08:06:40 kernel: br0: port 1(vlan1) entering disabled state
Dec 24 08:06:40 kernel: br0: port 1(vlan1) entering listening state
Dec 24 08:06:40 kernel: br0: port 1(vlan1) entering learning state
Dec 24 08:06:40 kernel: br0: topology change detected, propagating
Dec 24 08:06:40 kernel: br0: port 1(vlan1) entering forwarding state
Dec 24 08:06:42 wan: mac clone: [wan0_hwaddr] == [26:62:B8:C7:4F:DC]
Dec 24 08:06:42 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 08:06:45 rc_service: udhcpc 12323:notify_rc start_firewall
Dec 24 08:06:45 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 08:06:45 dnsmasq[231]: using nameserver 192.168.100.1#53
Dec 24 08:06:45 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Dec 24 08:06:45 wan: finish adding multi routes
Dec 24 08:06:48 WAN Connection: WAN was restored.
Dec 24 08:08:15 rc_service: udhcpc 12323:notify_rc stop_upnp
Dec 24 08:08:15 rc_service: udhcpc 12323:notify_rc start_upnp
Dec 24 08:08:15 rc_service: waitting "stop_upnp" via udhcpc ...
Dec 24 08:08:17 dhcp client: bound 192.168.100.10 via 192.168.100.1 during 20 seconds.
Dec 24 08:08:35 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 08:08:35 dnsmasq[231]: using nameserver 192.168.100.1#53
Dec 24 08:08:36 rc_service: udhcpc 12396:notify_rc start_firewall
Dec 24 08:08:36 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 08:08:36 dnsmasq[231]: using nameserver 75.74.216.1#53
Dec 24 08:08:36 dnsmasq[231]: using nameserver 75.74.216.2#53
Dec 24 08:08:36 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Dec 24 08:08:36 wan: finish adding multi routes
Dec 24 08:08:36 rc_service: udhcpc 12396:notify_rc stop_upnp
Dec 24 08:08:36 rc_service: udhcpc 12396:notify_rc start_upnp
Dec 24 08:08:36 rc_service: waitting "stop_upnp" via udhcpc ...
Dec 24 08:08:37 dhcp client: bound 107.48.56.12 via 107.48.56.1 during 3600 seconds.

Log when I manually clicked the Apply button.
Code:
Dec 24 10:52:10 rc_service: httpd 1306:notify_rc restart_wan_if 0
Dec 24 10:52:10 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 10:52:10 dnsmasq[231]: using nameserver 75.74.216.1#53
Dec 24 10:52:10 dnsmasq[231]: using nameserver 75.74.216.2#53
Dec 24 10:52:10 kernel: Attempt to kill tasklet from interrupt
Dec 24 10:52:10 kernel: br0: port 1(vlan1) entering disabled state
Dec 24 10:52:10 kernel: br0: port 1(vlan1) entering listening state
Dec 24 10:52:10 kernel: br0: port 1(vlan1) entering learning state
Dec 24 10:52:10 kernel: br0: topology change detected, propagating
Dec 24 10:52:10 kernel: br0: port 1(vlan1) entering forwarding state
Dec 24 10:52:10 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 10:52:10 dnsmasq[231]: using nameserver 75.74.216.1#53
Dec 24 10:52:10 dnsmasq[231]: using nameserver 75.74.216.2#53
Dec 24 10:52:10 wan: mac clone: [wan0_hwaddr] == [56:C6:BE:E1:58:85]
Dec 24 10:52:10 kernel: Attempt to kill tasklet from interrupt
Dec 24 10:52:10 kernel: br0: port 1(vlan1) entering disabled state
Dec 24 10:52:10 kernel: br0: port 1(vlan1) entering listening state
Dec 24 10:52:10 kernel: br0: port 1(vlan1) entering learning state
Dec 24 10:52:10 kernel: br0: topology change detected, propagating
Dec 24 10:52:10 kernel: br0: port 1(vlan1) entering forwarding state
Dec 24 10:52:10 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 10:52:26 WAN Connection: ISP's DHCP did not function properly.
Dec 24 10:52:42 rc_service: udhcpc 1585:notify_rc start_firewall
Dec 24 10:52:42 dnsmasq[231]: read /etc/hosts - 5 addresses
Dec 24 10:52:42 dnsmasq[231]: using nameserver 192.168.100.1#53
Dec 24 10:52:42 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Dec 24 10:52:42 wan: finish adding multi routes
Dec 24 10:52:46 WAN Connection: WAN was restored.
 
Well, I didn't figure out how exactly to emulate clicking the Apply button on the WAN page (after changing the MAC Clone address). I tried various combinations of restarting the services listed in the log in my previous post (along with running nvram commit) but never got the same results I got from manually clicking the Apply button.

However, I did manage to find a procedure that works well for changing my MAC Clone address (and subsequently my public IP address) via Telnet.

As mentioned above, I was having issues with variation in the amount of time it would take for my public IP to change. More often than not, it was taking around 140 seconds, instead of around 60 seconds as it should (as it always did when I would manually click the Apply button).
My best guess is that it was largely luck that I was achieving a 60-second delay at all when using the Telnet method mentioned above. It seems it was a timing issue. If the timing between running nvram commit and cycling power on the modem was just right, I'd get around a 60-second delay, otherwise around 140 seconds. I suspect another factor was what sort of activity the router/and or modem were engaged in at that particular moment.

The key to getting approximately a 60-second delay every time turned out to be stopping and restarting the wan service in the following order:

- stop the wan service (service stop_wan)
- cycle power on the modem
- change the value of the MAC address variable (eg, nvram set wan0_hwaddr_x=12:34:56:78:90:AB)
- commit the change (nvram commit)
- wait 55 seconds (for modem to start up)
- start the wan service (service start_wan)

That process has worked flawlessly for me. I don't know how well it'll work for you though.
I'm using a Motorola SB6120 cable modem (and, as mentioned above, my router is an ASUS RT-N66U and my firmware is Merlin 378.56_2).

Note: As of writing this, I don't actually manually cycle the power on my modem anymore. I don't manually do anything actually. I now have a script that opens Telnet, logs me in and enters a single chain of commands that generates a random MAC and performs the steps listed above.
Below is the chain of commands I'm currently using. I'm new to Linux, and the command options are a bit limited on the router's version of Linux, so don't expect a thing of beauty. Use at your own peril, though you'll probably have no problems if you have the same hardware & firmware as me.
Code:
tImEs=$(date +%s);tImEp=0;pRvIP=$(nvram get wan0_ipaddr);cUrIP=$pRvIP;until [[ "$RdMaC" != "" && "$(nvram show|grep -i -q "$RdMaC";echo $?)" != "0" ]];do RdMaC=$(echo $(cat /dev/urandom| head -c 22)|md5sum|sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\)\(..\).*$/\1:\2:\3:\4:\5:\6/'|sed s/./$(expr substr 02468ACE $(grep -m1 -a -o '[1-8]' /dev/urandom|head -n1) 1)/2|tr 'a-z' 'A-Z' );usleep 100000;done;wget -b -q -O- http://192.168.100.1/reset.htm &> /dev/null;sleep 6;service stop_wan;clear;sleep 2;nvram set wan0_hwaddr_x=$RdMaC;nvram commit;clear;echo wait...;sleep 45;service start_wan;clear;echo -n wait...;until [[ "$cUrIP" != "$pRvIP" && "$cUrIP" != "0.0.0.0" && $(echo $cUrIP|grep -q "192.168.1";echo $?) != "0" ]] || [ $tImEp -gt 210 ];do cUrIP="$(nvram get wan0_ipaddr)";tImEp=$(( $(date +%s)-$tImEs ));sleep 1;echo -n .;done;clear;echo Previous IP: $pRvIP;echo Current IP: $cUrIP;echo Seconds waited: $tImEp;if [ $tImEp -gt 210 ];then echo -FAILED-;else echo -Success-;fi;unset tImEs tImEp cUrIP pRvIP RdMaC
 
a single chain of commands that generates a random MAC ...



A random, fully automatic MAC, with openssl:
Code:
AUTOMAC=$(m=$(/usr/sbin/openssl rand -hex 6|/usr/bin/tr [a-z] [A-Z]) && /bin/echo ${m:0:2}:${m:2:2}:${m:4:2}:${m:6:2}:${m:8:2}:${m:10:2})
echo $AUTOMAC
 
Last edited:
Well, poo.
Looks like this isn't over yet.
It turns out that, a little while after I change the MAC (about 14 minutes every time), my connection mysteriously goes down then comes back up about a minute or two later.
Because it happens 14 minutes after I change the MAC and only lasts a short time, it took nearly a week of daily MAC changes before I even noticed it was happening.

Here's a log of it taking place if anyone is interested:
Code:
Jan  5 13:43:19 rc_service: service 7112:notify_rc stop_wan
Jan  5 13:43:19 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:43:19 dnsmasq[231]: using nameserver 75.74.216.1#53
Jan  5 13:43:19 dnsmasq[231]: using nameserver 75.74.216.2#53
Jan  5 13:43:19 kernel: Attempt to kill tasklet from interrupt
Jan  5 13:43:19 kernel: br0: port 1(vlan1) entering disabled state
Jan  5 13:43:19 kernel: br0: port 1(vlan1) entering listening state
Jan  5 13:43:19 kernel: br0: topology change detected, propagating
Jan  5 13:43:19 kernel: br0: port 1(vlan1) entering forwarding state
Jan  5 13:43:19 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:43:19 dnsmasq[231]: using nameserver 75.74.216.1#53
Jan  5 13:43:19 dnsmasq[231]: using nameserver 75.74.216.2#53
Jan  5 13:43:21 WAN Connection: ISP's DHCP did not function properly.
Jan  5 13:43:31 WAN Connection: Ethernet link down.
Jan  5 13:43:41 WAN Connection: Ethernet link up.
Jan  5 13:43:41 rc_service: wanduck 218:notify_rc restart_wan_if 0
Jan  5 13:43:41 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:43:41 dnsmasq[231]: using nameserver 75.74.216.1#53
Jan  5 13:43:41 dnsmasq[231]: using nameserver 75.74.216.2#53
Jan  5 13:43:41 kernel: Attempt to kill tasklet from interrupt
Jan  5 13:43:41 kernel: br0: port 1(vlan1) entering disabled state
Jan  5 13:43:41 kernel: br0: port 1(vlan1) entering listening state
Jan  5 13:43:41 kernel: br0: port 1(vlan1) entering learning state
Jan  5 13:43:41 kernel: br0: topology change detected, propagating
Jan  5 13:43:41 kernel: br0: port 1(vlan1) entering forwarding state
Jan  5 13:43:43 wan: mac clone: [wan0_hwaddr] == [5C:C2:EC:C2:71:F2]
Jan  5 13:43:43 kernel: Attempt to kill tasklet from interrupt
Jan  5 13:43:43 kernel: br0: port 1(vlan1) entering disabled state
Jan  5 13:43:43 kernel: br0: port 1(vlan1) entering listening state
Jan  5 13:43:43 kernel: br0: port 1(vlan1) entering learning state
Jan  5 13:43:43 kernel: br0: topology change detected, propagating
Jan  5 13:43:43 kernel: br0: port 1(vlan1) entering forwarding state
Jan  5 13:43:49 WAN Connection: ISP's DHCP did not function properly.
Jan  5 13:44:09 rc_service: service 7131:notify_rc start_wan
Jan  5 13:44:09 wan: mac clone: [wan0_hwaddr] == [5C:C2:EC:C2:71:F2]
Jan  5 13:44:09 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:44:15 rc_service: udhcpc 7199:notify_rc start_firewall
Jan  5 13:44:15 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:44:15 dnsmasq[231]: using nameserver 75.74.216.1#53
Jan  5 13:44:15 dnsmasq[231]: using nameserver 75.74.216.2#53
Jan  5 13:44:15 wan: finish adding multi routes
Jan  5 13:44:15 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jan  5 13:44:15 rc_service: udhcpc 7199:notify_rc stop_upnp
Jan  5 13:44:15 rc_service: waitting "start_firewall" via udhcpc ...
Jan  5 13:44:16 rc_service: udhcpc 7199:notify_rc start_upnp
Jan  5 13:44:16 rc_service: waitting "stop_upnp" via udhcpc ...
Jan  5 13:44:18 dhcp client: bound 107.48.56.139 via 107.48.56.1 during 3600 seconds.
Jan  5 13:44:19 WAN Connection: WAN was restored.
Jan  5 13:44:21 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:44:21 dnsmasq[231]: using nameserver 75.74.216.1#53
Jan  5 13:44:21 dnsmasq[231]: using nameserver 75.74.216.2#53
Jan  5 13:44:21 rc_service: udhcpc 7255:notify_rc start_firewall
Jan  5 13:44:21 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jan  5 13:44:21 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:44:21 dnsmasq[231]: using nameserver 75.74.216.1#53
Jan  5 13:44:21 dnsmasq[231]: using nameserver 75.74.216.2#53
Jan  5 13:44:21 wan: finish adding multi routes
Jan  5 13:44:21 rc_service: udhcpc 7255:notify_rc stop_upnp
Jan  5 13:44:21 rc_service: udhcpc 7255:notify_rc start_upnp
Jan  5 13:44:21 rc_service: waitting "stop_upnp" via udhcpc ...
Jan  5 13:44:22 dhcp client: bound 107.48.56.139 via 107.48.56.1 during 3595 seconds.
Jan  5 13:58:34 WAN Connection: Ethernet link down.
Jan  5 13:58:49 WAN Connection: Ethernet link up.
Jan  5 13:58:49 rc_service: wanduck 218:notify_rc restart_wan_if 0
Jan  5 13:58:49 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:58:49 dnsmasq[231]: using nameserver 75.74.216.1#53
Jan  5 13:58:49 dnsmasq[231]: using nameserver 75.74.216.2#53
Jan  5 13:58:49 kernel: Attempt to kill tasklet from interrupt
Jan  5 13:58:49 kernel: br0: port 1(vlan1) entering disabled state
Jan  5 13:58:49 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:58:49 dnsmasq[231]: using nameserver 75.74.216.1#53
Jan  5 13:58:49 dnsmasq[231]: using nameserver 75.74.216.2#53
Jan  5 13:58:49 wan: mac clone: [wan0_hwaddr] == [5C:C2:EC:C2:71:F2]
Jan  5 13:58:49 kernel: br0: port 1(vlan1) entering listening state
Jan  5 13:58:49 kernel: br0: port 1(vlan1) entering learning state
Jan  5 13:58:49 kernel: br0: topology change detected, propagating
Jan  5 13:58:49 kernel: br0: port 1(vlan1) entering forwarding state
Jan  5 13:58:50 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:58:54 rc_service: udhcpc 7339:notify_rc start_firewall
Jan  5 13:58:54 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 13:58:54 dnsmasq[231]: using nameserver 192.168.100.1#53
Jan  5 13:58:54 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jan  5 13:58:54 wan: finish adding multi routes
Jan  5 13:58:55 WAN Connection: WAN was restored.
Jan  5 14:00:25 rc_service: udhcpc 7339:notify_rc stop_upnp
Jan  5 14:00:25 rc_service: udhcpc 7339:notify_rc start_upnp
Jan  5 14:00:25 rc_service: waitting "stop_upnp" via udhcpc ...
Jan  5 14:00:26 dhcp client: bound 192.168.100.10 via 192.168.100.1 during 20 seconds.
Jan  5 14:00:44 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 14:00:44 dnsmasq[231]: using nameserver 192.168.100.1#53
Jan  5 14:00:45 rc_service: udhcpc 7389:notify_rc start_firewall
Jan  5 14:00:45 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jan  5 14:00:45 dnsmasq[231]: read /etc/hosts - 5 addresses
Jan  5 14:00:45 dnsmasq[231]: using nameserver 71.10.216.1#53
Jan  5 14:00:45 dnsmasq[231]: using nameserver 71.10.216.2#53
Jan  5 14:00:45 wan: finish adding multi routes
Jan  5 14:00:45 rc_service: udhcpc 7389:notify_rc stop_upnp
Jan  5 14:00:45 rc_service: udhcpc 7389:notify_rc start_upnp
Jan  5 14:00:45 rc_service: waitting "stop_upnp" via udhcpc ...
Jan  5 14:00:46 dhcp client: bound 107.48.56.139 via 107.48.56.1 during 2611 seconds.
at 13:43:19 I start the MAC/IP change process
at 13:44:22 the process completes
at 13:58:34 the connection mysteriously goes down
at 14:00:46 the connection is back up

I'm really curious about what exactly is happening and why it takes 14 minutes for it to happen every time.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top