What's new

Your ISP's DHCP does not function correctly

  • 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!

Exelent

New Around Here
Sorry, I know there are already plenty of such posts, but I haven't find a solution in any of them.
My Router Asus GT-AC2900 with official firmware was working for about a week after I bought it. Then the problem "Your ISP's DHCP does not function correctly" occured.
1. I did a factory reset three times. Both on ASUS and modem, tried to boot them in different sequences
2. If I connect to modem ISP's huawei router, it is able to obtain a DHCP lease.
3. I tried to clone ISP's router mac to asus. Tried to obtain the lease on huawei and the connect ASUS. Tried different MAC.
4. If I connect ASUS to Huawei LAN port, ASUS is able to obtain the DHCP lease from it.
5. I tried different DHCP frequency modes. Disabled firewall, Qos, all router features, didn't help. At least features that I am aware of.
6. ISP says that they see my routers DHCPDISCOVERY request. They respond with DHCPOFFER but the packet is lost somewhere.

Questions:
1.Does anybody managed to deal with the same issue?
2. What is the best way to track where packet is lost? How can I log all incoming packets. Packets, that are dropped by iptables, that are recieved by the socket, that are recieved by dhcp daemon. Everything that could help.

Here are last part of my log file: (full version in the attachments)
Code:
Oct 16 16:32:27 acsd: selected channel spec: 0x1006 (6)
Oct 16 16:32:27 acsd: Adjusted channel spec: 0x1006 (6)
Oct 16 16:32:27 acsd: selected channel spec: 0x1006 (6)
Oct 16 16:32:27 acsd: acs_set_chspec: 0x1006 (6) for reason APCS_CSTIMER
Oct 16 16:37:25 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth6: Disassoc F0:18:98:47:E4:35, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Oct 16 16:47:29 acsd: selected channel spec: 0x100b (11)
Oct 16 16:47:29 acsd: Adjusted channel spec: 0x100b (11)
Oct 16 16:47:29 acsd: selected channel spec: 0x100b (11)
Oct 16 16:47:29 acsd: acs_set_chspec: 0x100b (11) for reason APCS_CSTIMER
Oct 16 17:00:45 disk_monitor: Got SIGALRM...
Oct 16 17:02:31 acsd: selected channel spec: 0x1008 (8)
Oct 16 17:02:31 acsd: Adjusted channel spec: 0x1008 (8)
Oct 16 17:02:31 acsd: selected channel spec: 0x1008 (8)
Oct 16 17:02:31 acsd: acs_set_chspec: 0x1008 (8) for reason APCS_CSTIMER
Oct 16 17:17:33 acsd: selected channel spec: 0x100a (10)
Oct 16 17:17:33 acsd: Adjusted channel spec: 0x100a (10)
Oct 16 17:17:33 acsd: selected channel spec: 0x100a (10)
Oct 16 17:17:33 acsd: acs_set_chspec: 0x100a (10) for reason APCS_CSTIMER
Oct 16 17:32:35 acsd: selected channel spec: 0x100a (10)
Oct 16 17:32:35 acsd: Adjusted channel spec: 0x100a (10)
Oct 16 17:32:35 acsd: selected channel spec: 0x100a (10)
Oct 16 17:47:16 kernel: eth0 (Int switch port: 3) (Logical Port: 3) Link DOWN.
Oct 16 17:47:16 kernel: ===> Activate Deep Green Mode
Oct 16 17:47:17 WAN Connection: ISP's DHCP did not function properly.
Oct 16 17:47:17 DualWAN: skip single wan wan_led_control - WANRED off
Oct 16 17:47:17 nat: apply redirect rules
Oct 16 17:47:22 WAN Connection: Ethernet link down.
Oct 16 17:47:37 acsd: selected channel spec: 0x1007 (7)
Oct 16 17:47:37 acsd: Adjusted channel spec: 0x1007 (7)
Oct 16 17:47:37 acsd: selected channel spec: 0x1007 (7)
Oct 16 17:47:37 acsd: acs_set_chspec: 0x1007 (7) for reason APCS_CSTIMER
Oct 16 17:51:39 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth6: Auth F0:18:98:47:E4:35, status: Successful (0)
Oct 16 17:51:39 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth6: Assoc F0:18:98:47:E4:35, status: Successful (0)
Oct 16 17:52:05 dropbear[20862]: Password auth succeeded for 'admin' from 192.168.50.107:59117
Oct 16 17:53:20 kernel: eth0 (Int switch port: 3) (Logical Port: 3) Link UP 1000 mbps full duplex
Oct 16 17:53:20 kernel: <=== Deactivate Deep Green Mode
Oct 16 17:53:24 WAN Connection: Ethernet link up.
Oct 16 17:53:24 rc_service: wanduck 1135:notify_rc restart_wan_if 0
Oct 16 17:53:26 wan: mac clone: [wan0_hwaddr] == [f0:18:98:47:e4:35]
Oct 16 17:53:26 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 16 17:53:26 wan: finish adding multi routes
Oct 16 17:53:26 dhcp client: bound 192.168.0.102/255.255.255.0 via 192.168.0.1 for 86400 seconds.
Oct 16 17:53:29 WAN Connection: WAN was restored.
Oct 16 17:53:29 ntp: start NTP update
Oct 16 18:02:40 acsd: selected channel spec: 0x1005 (5)
Oct 16 18:02:40 acsd: Adjusted channel spec: 0x1005 (5)
Oct 16 18:02:40 acsd: selected channel spec: 0x1005 (5)
Oct 16 18:02:40 acsd: acs_set_chspec: 0x1005 (5) for reason APCS_CSTIMER
Oct 16 18:07:05 rc_service: httpd 1220:notify_rc restart_firewall
Oct 16 18:07:05 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 16 18:08:34 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:6c:06:d6:1e:d0:8b:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=60742 DF OPT (94040000) PROTO=2 MARK=0x8000000 
Oct 16 18:09:01 kernel: eth0 (Int switch port: 3) (Logical Port: 3) Link DOWN.
Oct 16 18:09:01 kernel: ===> Activate Deep Green Mode
Oct 16 18:09:03 WAN Connection: ISP's DHCP did not function properly.
Oct 16 18:09:03 DualWAN: skip single wan wan_led_control - WANRED off
Oct 16 18:09:03 nat: apply redirect rules
Oct 16 18:09:07 kernel: eth0 (Int switch port: 3) (Logical Port: 3) Link UP 1000 mbps full duplex
Oct 16 18:09:07 kernel: <=== Deactivate Deep Green Mode
Oct 16 18:09:07 kernel: DROP IN=eth0 OUT=eth0 MAC=f0:18:98:47:e4:35:74:4a:a4:24:74:9b:08:00 SRC=31.209.137.10 DST=10.63.10.208 LEN=86 TOS=0x00 PREC=0x00 TTL=248 ID=63053 DF PROTO=TCP SPT=15674 DPT=61181 SEQ=3181639083 ACK=2869703433 WINDOW=126 RES=0x00 ACK PSH URGP=0 OPT (0101080A6474D8714B10EF9A) MARK=0x8000000 
Oct 16 18:09:08 WAN Connection: Ethernet link up.
Oct 16 18:09:08 rc_service: wanduck 1135:notify_rc restart_wan_if 0
Oct 16 18:09:10 wan: mac clone: [wan0_hwaddr] == [f0:18:98:47:e4:35]
Oct 16 18:10:49 rc_service: httpd 1220:notify_rc restart_wan_if 0
Oct 16 18:11:03 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=9798 OPT (94040000) PROTO=2 MARK=0x8000000 
Oct 16 18:11:04 rc_service: httpd 1220:notify_rc restart_wan_if 0
Oct 16 18:11:06 wan: mac clone: [wan0_hwaddr] == [f0:18:98:47:e4:35]
Oct 16 18:12:04 dropbear[25597]: Password auth succeeded for 'admin' from 192.168.50.107:51081
Oct 16 18:13:00 rc_service: httpd 1220:notify_rc restart_time;restart_upnp;restart_usb_idle;restart_bhblock;
Oct 16 18:13:00 kernel: klogd started: BusyBox v1.24.1 (2020-08-08 03:17:54 CST)
Oct 16 18:13:00 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 16 18:13:00 hour monitor: daemon is starting
Oct 16 18:13:00 hour monitor: daemon terminates
Oct 16 18:13:09 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=10792 OPT (94040000) PROTO=2 MARK=0x8000000 
Oct 16 18:13:26 dropbear[25954]: Bad password attempt for 'admin' from 192.168.50.107:52022
Oct 16 18:13:35 dropbear[25954]: Password auth succeeded for 'admin' from 192.168.50.107:52022
Oct 16 18:13:35 PTCSRV: [SSH] login succeeded from 192.168.50.107 after 1 attempts
Oct 16 18:15:14 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=11901 OPT (94040000) PROTO=2 MARK=0x8000000 
Oct 16 18:15:36 rc_service: httpd 1220:notify_rc restart_wan_if 0
Oct 16 18:15:38 wan: mac clone: [wan0_hwaddr] == [f0:18:98:47:e4:35]
Oct 16 18:17:19 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=13003 OPT (94040000) PROTO=2 MARK=0x8000000 
Oct 16 18:17:42 acsd: selected channel spec: 0x1002 (2)
Oct 16 18:17:42 acsd: Adjusted channel spec: 0x1002 (2)
Oct 16 18:17:42 acsd: selected channel spec: 0x1002 (2)
Oct 16 18:17:42 acsd: acs_set_chspec: 0x1002 (2) for reason APCS_CSTIMER
Oct 16 18:19:23 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=14019 OPT (94040000) PROTO=2 MARK=0x8000000 
Oct 16 18:21:28 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=15049 OPT (94040000) PROTO=2 MARK=0x8000000 
Oct 16 18:21:46 rc_service: httpd 1220:notify_rc restart_wan_if 0
Oct 16 18:21:48 wan: mac clone: [wan0_hwaddr] == [6c:06:d6:1e:d0:8b]
Oct 16 18:21:48 pppoe-relay[26467]: recv (receivePacket): Network is down
Oct 16 18:21:48 pppoe-relay[26467]: recv (receivePacket): Network is down
Oct 16 18:23:33 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=16300 OPT (94040000) PROTO=2 MARK=0x8000000 
Oct 16 18:25:38 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=17283 OPT (94040000) PROTO=2 MARK=0x8000000 
Oct 16 18:27:43 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=18353 OPT (94040000) PROTO=2 MARK=0x8000000

I would appreciate any help
 

Attachments

  • syslog.txt
    280.7 KB · Views: 222
im not positive but I believe in the beta changelog for 386 they mention an issue with ISP dhcp failing due to trend micro being enabled. maybe try turning that off if the issue is severe, but i do believe going forward that issue will be addressed.
 
Thanks for the tip. Will try.
So far looks like the problem is really in ISP or it's modem. I installed tcpdump on Asus router and I can't see any DCHPOFFER request. Will keep updating
 
Like 4 years ago when i had fibre connection before i got ddosed and my isp terminated contract with me because of me beeing victim of ddos (funny logic they wont give u new ip adress rather terminate contract when ur not to blame for some1 illegal actions) i remember they used technique that ip adress was tied with my router mac adress so everytime i wanted to change router i had to call them and give my new router mac to them so they can change it in their systems. That seems like the case here.
 
Like 4 years ago when i had fibre connection before i got ddosed and my isp terminated contract with me because of me beeing victim of ddos (funny logic they wont give u new ip adress rather terminate contract when ur not to blame for some1 illegal actions) i remember they used technique that ip adress was tied with my router mac adress so everytime i wanted to change router i had to call them and give my new router mac to them so they can change it in their systems. That seems like the case here.

This issue is unrelated.
 
This issue is unrelated.

not necessarily. It could be totally related. If his ISP ties his ip to his routers mac he would get that exact message. Sometimes you get tech support that doesn't know what they are doing. If I was him I would call and complain again and ask for a supervisor because his gut hunch that it has to do with his isp or their modem is probably right.

I remember years ago during my dsl days about once a month I would have to call verizon to change my password lol. They would try to get me to go through the motions to get internet working thinking I was nuts and I would say before you do anything go look at the log book and then give me a new password with your auto generator. (after they would deny they do that) They would come back nervous and immediately give me a new password and presto. To this day I still think someone hacked them to change my password like clockwork every 30 days lmao.

only time I got isp dhcp not working correctly message is when I was plugging the wrong cable into the lan port. Spent an hour trying to fix it before realizing. Might seem obvious but double check.
 
@Zonkd Just curious; are you saying you have the same problem? Do you also see the same "Deep Green Mode" messages in the log?
 
@Zonkd Just curious; are you saying you have the same problem? Do you also see the same "Deep Green Mode" messages in the log?

I use to see those deep green messages in the log all the time when powering my ac86u. Think its normal? I have occasionally seen an isp dhcp not funcitoning message in log, but never noticed any issue. Maybe it took a couple seconds longer to register after a reboot so that message appears.

I also used a vpn on the router and couldn't put the wan dns to automatic or I would get no internet status on the router gui even though internet was working correctly, or occasionally wouldn't get internet at all. Probably totally unrelated but worth a shot to not use your isp's dns or have dns it set to automatic in the wan settings if using an openvpn client on the router.
 
@Zonkd Just curious; are you saying you have the same problem? Do you also see the same "Deep Green Mode" messages in the log?

I still get the error "Your ISP's DHCP does not function correctly" intermittently on my AC86U. Usually happens when I'm asleep or not home to fix it. Never recall seeing any Deep Green Mode messages in the logs but I didn't analyse them in-depth like @Exelent has. Now I just cron a script to restart WAN int when internet drops.
 
Sorry, I know there are already plenty of such posts, but I haven't find a solution in any of them.
My Router Asus GT-AC2900 with official firmware was working for about a week after I bought it. Then the problem "Your ISP's DHCP does not function correctly" occured.
1. I did a factory reset three times. Both on ASUS and modem, tried to boot them in different sequences
2. If I connect to modem ISP's huawei router, it is able to obtain a DHCP lease.
3. I tried to clone ISP's router mac to asus. Tried to obtain the lease on huawei and the connect ASUS. Tried different MAC.
4. If I connect ASUS to Huawei LAN port, ASUS is able to obtain the DHCP lease from it.
5. I tried different DHCP frequency modes. Disabled firewall, Qos, all router features, didn't help. At least features that I am aware of.
6. ISP says that they see my routers DHCPDISCOVERY request. They respond with DHCPOFFER but the packet is lost somewhere.

Questions:
1.Does anybody managed to deal with the same issue?
2. What is the best way to track where packet is lost? How can I log all incoming packets. Packets, that are dropped by iptables, that are recieved by the socket, that are recieved by dhcp daemon. Everything that could help.

Here are last part of my log file: (full version in the attachments)
Code:
Oct 16 16:32:27 acsd: selected channel spec: 0x1006 (6)
Oct 16 16:32:27 acsd: Adjusted channel spec: 0x1006 (6)
Oct 16 16:32:27 acsd: selected channel spec: 0x1006 (6)
Oct 16 16:32:27 acsd: acs_set_chspec: 0x1006 (6) for reason APCS_CSTIMER
Oct 16 16:37:25 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth6: Disassoc F0:18:98:47:E4:35, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Oct 16 16:47:29 acsd: selected channel spec: 0x100b (11)
Oct 16 16:47:29 acsd: Adjusted channel spec: 0x100b (11)
Oct 16 16:47:29 acsd: selected channel spec: 0x100b (11)
Oct 16 16:47:29 acsd: acs_set_chspec: 0x100b (11) for reason APCS_CSTIMER
Oct 16 17:00:45 disk_monitor: Got SIGALRM...
Oct 16 17:02:31 acsd: selected channel spec: 0x1008 (8)
Oct 16 17:02:31 acsd: Adjusted channel spec: 0x1008 (8)
Oct 16 17:02:31 acsd: selected channel spec: 0x1008 (8)
Oct 16 17:02:31 acsd: acs_set_chspec: 0x1008 (8) for reason APCS_CSTIMER
Oct 16 17:17:33 acsd: selected channel spec: 0x100a (10)
Oct 16 17:17:33 acsd: Adjusted channel spec: 0x100a (10)
Oct 16 17:17:33 acsd: selected channel spec: 0x100a (10)
Oct 16 17:17:33 acsd: acs_set_chspec: 0x100a (10) for reason APCS_CSTIMER
Oct 16 17:32:35 acsd: selected channel spec: 0x100a (10)
Oct 16 17:32:35 acsd: Adjusted channel spec: 0x100a (10)
Oct 16 17:32:35 acsd: selected channel spec: 0x100a (10)
Oct 16 17:47:16 kernel: eth0 (Int switch port: 3) (Logical Port: 3) Link DOWN.
Oct 16 17:47:16 kernel: ===> Activate Deep Green Mode
Oct 16 17:47:17 WAN Connection: ISP's DHCP did not function properly.
Oct 16 17:47:17 DualWAN: skip single wan wan_led_control - WANRED off
Oct 16 17:47:17 nat: apply redirect rules
Oct 16 17:47:22 WAN Connection: Ethernet link down.
Oct 16 17:47:37 acsd: selected channel spec: 0x1007 (7)
Oct 16 17:47:37 acsd: Adjusted channel spec: 0x1007 (7)
Oct 16 17:47:37 acsd: selected channel spec: 0x1007 (7)
Oct 16 17:47:37 acsd: acs_set_chspec: 0x1007 (7) for reason APCS_CSTIMER
Oct 16 17:51:39 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth6: Auth F0:18:98:47:E4:35, status: Successful (0)
Oct 16 17:51:39 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth6: Assoc F0:18:98:47:E4:35, status: Successful (0)
Oct 16 17:52:05 dropbear[20862]: Password auth succeeded for 'admin' from 192.168.50.107:59117
Oct 16 17:53:20 kernel: eth0 (Int switch port: 3) (Logical Port: 3) Link UP 1000 mbps full duplex
Oct 16 17:53:20 kernel: <=== Deactivate Deep Green Mode
Oct 16 17:53:24 WAN Connection: Ethernet link up.
Oct 16 17:53:24 rc_service: wanduck 1135:notify_rc restart_wan_if 0
Oct 16 17:53:26 wan: mac clone: [wan0_hwaddr] == [f0:18:98:47:e4:35]
Oct 16 17:53:26 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 16 17:53:26 wan: finish adding multi routes
Oct 16 17:53:26 dhcp client: bound 192.168.0.102/255.255.255.0 via 192.168.0.1 for 86400 seconds.
Oct 16 17:53:29 WAN Connection: WAN was restored.
Oct 16 17:53:29 ntp: start NTP update
Oct 16 18:02:40 acsd: selected channel spec: 0x1005 (5)
Oct 16 18:02:40 acsd: Adjusted channel spec: 0x1005 (5)
Oct 16 18:02:40 acsd: selected channel spec: 0x1005 (5)
Oct 16 18:02:40 acsd: acs_set_chspec: 0x1005 (5) for reason APCS_CSTIMER
Oct 16 18:07:05 rc_service: httpd 1220:notify_rc restart_firewall
Oct 16 18:07:05 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 16 18:08:34 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:6c:06:d6:1e:d0:8b:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=60742 DF OPT (94040000) PROTO=2 MARK=0x8000000
Oct 16 18:09:01 kernel: eth0 (Int switch port: 3) (Logical Port: 3) Link DOWN.
Oct 16 18:09:01 kernel: ===> Activate Deep Green Mode
Oct 16 18:09:03 WAN Connection: ISP's DHCP did not function properly.
Oct 16 18:09:03 DualWAN: skip single wan wan_led_control - WANRED off
Oct 16 18:09:03 nat: apply redirect rules
Oct 16 18:09:07 kernel: eth0 (Int switch port: 3) (Logical Port: 3) Link UP 1000 mbps full duplex
Oct 16 18:09:07 kernel: <=== Deactivate Deep Green Mode
Oct 16 18:09:07 kernel: DROP IN=eth0 OUT=eth0 MAC=f0:18:98:47:e4:35:74:4a:a4:24:74:9b:08:00 SRC=31.209.137.10 DST=10.63.10.208 LEN=86 TOS=0x00 PREC=0x00 TTL=248 ID=63053 DF PROTO=TCP SPT=15674 DPT=61181 SEQ=3181639083 ACK=2869703433 WINDOW=126 RES=0x00 ACK PSH URGP=0 OPT (0101080A6474D8714B10EF9A) MARK=0x8000000
Oct 16 18:09:08 WAN Connection: Ethernet link up.
Oct 16 18:09:08 rc_service: wanduck 1135:notify_rc restart_wan_if 0
Oct 16 18:09:10 wan: mac clone: [wan0_hwaddr] == [f0:18:98:47:e4:35]
Oct 16 18:10:49 rc_service: httpd 1220:notify_rc restart_wan_if 0
Oct 16 18:11:03 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=9798 OPT (94040000) PROTO=2 MARK=0x8000000
Oct 16 18:11:04 rc_service: httpd 1220:notify_rc restart_wan_if 0
Oct 16 18:11:06 wan: mac clone: [wan0_hwaddr] == [f0:18:98:47:e4:35]
Oct 16 18:12:04 dropbear[25597]: Password auth succeeded for 'admin' from 192.168.50.107:51081
Oct 16 18:13:00 rc_service: httpd 1220:notify_rc restart_time;restart_upnp;restart_usb_idle;restart_bhblock;
Oct 16 18:13:00 kernel: klogd started: BusyBox v1.24.1 (2020-08-08 03:17:54 CST)
Oct 16 18:13:00 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 16 18:13:00 hour monitor: daemon is starting
Oct 16 18:13:00 hour monitor: daemon terminates
Oct 16 18:13:09 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=10792 OPT (94040000) PROTO=2 MARK=0x8000000
Oct 16 18:13:26 dropbear[25954]: Bad password attempt for 'admin' from 192.168.50.107:52022
Oct 16 18:13:35 dropbear[25954]: Password auth succeeded for 'admin' from 192.168.50.107:52022
Oct 16 18:13:35 PTCSRV: [SSH] login succeeded from 192.168.50.107 after 1 attempts
Oct 16 18:15:14 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=11901 OPT (94040000) PROTO=2 MARK=0x8000000
Oct 16 18:15:36 rc_service: httpd 1220:notify_rc restart_wan_if 0
Oct 16 18:15:38 wan: mac clone: [wan0_hwaddr] == [f0:18:98:47:e4:35]
Oct 16 18:17:19 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=13003 OPT (94040000) PROTO=2 MARK=0x8000000
Oct 16 18:17:42 acsd: selected channel spec: 0x1002 (2)
Oct 16 18:17:42 acsd: Adjusted channel spec: 0x1002 (2)
Oct 16 18:17:42 acsd: selected channel spec: 0x1002 (2)
Oct 16 18:17:42 acsd: acs_set_chspec: 0x1002 (2) for reason APCS_CSTIMER
Oct 16 18:19:23 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=14019 OPT (94040000) PROTO=2 MARK=0x8000000
Oct 16 18:21:28 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=15049 OPT (94040000) PROTO=2 MARK=0x8000000
Oct 16 18:21:46 rc_service: httpd 1220:notify_rc restart_wan_if 0
Oct 16 18:21:48 wan: mac clone: [wan0_hwaddr] == [6c:06:d6:1e:d0:8b]
Oct 16 18:21:48 pppoe-relay[26467]: recv (receivePacket): Network is down
Oct 16 18:21:48 pppoe-relay[26467]: recv (receivePacket): Network is down
Oct 16 18:23:33 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=16300 OPT (94040000) PROTO=2 MARK=0x8000000
Oct 16 18:25:38 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=17283 OPT (94040000) PROTO=2 MARK=0x8000000
Oct 16 18:27:43 kernel: DROP IN=eth0 OUT= MAC=01:00:5e:00:00:01:74:4a:a4:24:74:9b:08:00 SRC=172.16.236.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=18353 OPT (94040000) PROTO=2 MARK=0x8000000

I would appreciate any help

Make a phone call to your ISP.
"Reset my old MAC Address please"
 
Did you manage to solve this @Exelent ?
yep, actually the problem really was with my ISP.
I tried to use ISP's Huawei router and found out that connection is very slow.I contacted my ISP and after weeks of investigation they rebooted olt and the problem with dhcp and speed was gone.
I guessI had this error because of the bad connection. Looks like ASUS is more sensitive to good line, than Huawei.
 
yep, actually the problem really was with my ISP.
I tried to use ISP's Huawei router and found out that connection is very slow.I contacted my ISP and after weeks of investigation they rebooted olt and the problem with dhcp and speed was gone.
I guessI had this error because of the bad connection. Looks like ASUS is more sensitive to good line, than Huawei.

Thanks for confirming.
 
im starting to get alot of those your isp's dhcp is not working correctly, especially from my fing device. and also saw just saw that Activate Deep Green Mode messege but also saw alot of other weird stuff in the log that im afraid might be malicious but i onlydont jave the most knowledge on this stuff so i could be totally off but it seems like a new device was being installed to look like memory and then reading from it and also possibly to write to and then immediatly read "bad" data from it.
 
*Old Thread*
My experience has been that "Fing" devices cause more network issues than they spot. There are better tools available that are not so intrusive!

From other boards, and by testing this myself: At least here in the UK it's sometimes possible to generate the "Your ISP's DHCP does not function correctly" on VDSL simply by switching from a PPPoA/PPPoE to MPoA connection.
 
There are better tools available that are not so intrusive.

Ya it's been awhile since I bought it and my happiness with it has waned significantly since them. Any suggestions?
 
Have you tried manually changing the routers MAC address then rebooting the modem? For me on Comcast it forces the system to reassign the modem a new IP address. My ac88u had this problem but my ax88u does not.
 

Latest threads

Sign Up For SNBForums Daily Digest

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