What's new

Solved Strange DHCP source and MAC addresses showing 14 pairs

The most unfortunate thing is that this unsolicited request is accepted by the firewall due to history of many "broken" DHCP servers at ISPs. Even though you're not running Merlin firmware, the code is probably the same in stock ASUS:
C:
/* enable incoming packets from broken dhcp servers, which are sending replies
 * from addresses other than used for query, this could lead to lower level
 * of security, but it does not work otherwise (conntrack does not work) :-(
 */
switch (wan_proto) {
default:
        if (!(nvram_get_int(strcat_r(prefix, "dhcpenable_x", tmp)) || inet_addr_(wan_ip) == INADDR_ANY))
                break;
        /* fall-through */
case WAN_DHCP:
        fprintf(fp, "-A INPUT -p udp --sport 67 --dport 68 -j %s\n", logaccept);
        break;
yes that seems to describe the problem possibility quite well.
 
Yes, is strange since occasionally my routers GW IP (CORRECTION very similar to my GW IP) will also show as doing dhcp at the same time as the other IP transaction shows up. This is a brand new router, is there a problem with ASUS security and their firewall? I do not know how it could have been compromised to be honest except when it first got a public ip from the ISP. But what are the odds? Will flashing back to factory settings help? This has been done a couple times so I would have thought it would have been corrected but still exists. EDITED: I suppose this doesn't help to flash if it will just rehappen through the ISP?
There is nothing wrong with your router, it has not been compromised. This is normal behaviour for Asus routers with certain ISP's. My advice: turn off firewall logging and stop fretting over nothing.
 
The most unfortunate thing is that this unsolicited request is accepted by the firewall due to history of many "broken" DHCP servers at ISPs. Even though you're not running Merlin firmware, the code is probably the same in stock ASUS:
C:
/* enable incoming packets from broken dhcp servers, which are sending replies
 * from addresses other than used for query, this could lead to lower level
 * of security, but it does not work otherwise (conntrack does not work) :-(
 */
switch (wan_proto) {
default:
        if (!(nvram_get_int(strcat_r(prefix, "dhcpenable_x", tmp)) || inet_addr_(wan_ip) == INADDR_ANY))
                break;
        /* fall-through */
case WAN_DHCP:
        fprintf(fp, "-A INPUT -p udp --sport 67 --dport 68 -j %s\n", logaccept);
        break;
Unfortunately there doesn't seem to be a solution if the firewall is going to let it in.
 
Thanks everyone for your help, input and advice! I know you are all busy people so thanks for taking the time to share your expertise! It is greatly appreciated!
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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