Strange DHCP source and MAC addresses showing 14 pairs

[Jojo]

Hello, I recently picked up a ASUS RT-BE82U router with AsusWRT v 3.0.0.6.102_39099. After setup without issues, I was watching the system log and noticed traffic which appears strange to me. It appears to be DHCP traffic, based on the ports 67 and 68 and the destination is 255.255.255.255. In addition, there is no OUT= and the MAC address first 6 pairs are listed as FF so is likely truly a broadcast. The remaining 8 pairs look like valid addressing--only too long for MAC addressing standards.

First thing strange is the MAC address shown being 14 pairs in length versus standard 6 pairs. I could find nothing on the internet about MAC addresses that are 14 pairs in length and the source. Secondly is the source IP being 30.46.144.1. I am unable to determine where this is coming from. I was also unable to determine anything with wireshark captures as actually coming inbound which made me think it's some source internally within the firmware. This is not my ISP or at least so they say. When I contacted them, they said everything appears normal and working from their end. Even more odd--on occasion an actual ISP DHCP address, or at least one from their subnets and ending in a .1, also shows with far less frequency going to the same MAC of length 14 pairs that the 30.46.144.1 ip does. This broadcast from 30.46.144.1 is quite frequent and appears static.

My understanding is that we can only pick up dhcp traffic from our ISP and that other non-ISP subnets could not provide it to my router. But as mentioned this isn't reported as theirs by them when I called them or from web searches I did. When I searched the web for that IP, for what it's worth info from two different sites, it was reported owned by DoD. Perhaps they do or did own it I don't know. Perhaps the web data about IP ownership is old which most of it is, but nevertheless, why is it shown in my router?

In any case so I can understand what's occuring, I am wondering if someone who knows AsusWRT firmware or it's derivatives can tell me what exactly are the MAC addresses that are 14 pairs in length and what are they for? Are these ASUS virtual adapters? And also anything about the source of that IP? Is this IP hardcoded somewhere? And if it is DoD owned, why is it in my router?

There are two of the long MAC addresses I see--so far. I list the log transactions below. One is the one I described while there is one other one of 14 pairs. The first shows not going out, which makes sense for a broadcast, but the other is an eth0 out. Here is the first entry, but with my addressing x'd out for anonymization:
kernel: ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:xx:xx:xx:xx:xx:xx:xx SRC=30.46.144.1 DST=255.255.255.255 LEN=352 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=332 MARK=0x8000000

and here is the second which was not a broadcast traffic and appears outbound. The long MAC is unknown, but the IP outbound traffic appears normal or valid known traffic. In question is just the source of the long MAC address because my traffic is routing through it:
kernel: ACCEPT IN=br0 OUT=eth0 MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=<valid internal ip> DST=<valid external ip> LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53170 DPT=443 SEQ=1856759468 ACK=0 WINDOW=0 RES=0x00 CWR ECE SYN URGP=0 OPT (020405B4010303060101080AEDA43EA20000000004020000) MARK=0x1

I thought maybe my cell phone using random private mac addressing might be triggering this frequent broadcasting, but I disabled that and no change.

I also thought maybe the internal dhcp server in the router was these long MAC addresses and they were internally derived virtual interfaces, but disabling dhcp had no effect either. The inbound 30.46.144.1 broadcasts continued. And by the ip range, it isn't a private local address from some random unknown dhcp service in my local lan because I have none.

Are these simply non-standard MAC addresses internally created by the firmware for the br0 interface? But the 2 long MAC addresses are different. I would think br0 only needed one.

I also called ASUS support, but they said they didn't have that level of information and to submit it within the router software, however when I went to explore that option they wanted a ton more of personal info and also highlighted doing so would not get an individual response--so what good is that?

Can someone who knows ASUS firmware shed some light on this please?
Thanks!

 

[ColinTaylor]

The "MAC" field is the destination MAC address (either broadcast or your router's WAN interface, eth0), followed by the source MAC address (e.g. your cable modem), followed by the EtherType.

This is just normal DHCP noise from your ISP's local network equipment.

 

[jzchen]

I found info/explanation of the MAC, which seems source, dest, and type:

Why do we see long MAC address in iptables log message? - Red Hat Customer Portal

Why do we see long MAC address in iptables log message? Following command has been executed in order to log the iptables log for ftp service : iptables -A INPUT -j LOG -p tcp --dport 22 --log-level warn Found following messages in log file: Feb 15 07:57:25 backupR3 kernel: IN=eth1 OUT=...

access.redhat.com

 

[Jojo]

Thanks for the clarification! So I understand correctly, are you saying 6 pairs destination, 6pairs source mac and 2 pairs for indicating EtherType and they're all scrunched into the 14 pair MAC listed? Got it! Thanks again! Any ideas on the 30.46.144.1?

 

[Jojo]

I found info/explanation of the MAC, which seems source, dest, and type:

Why do we see long MAC address in iptables log message? - Red Hat Customer Portal

Why do we see long MAC address in iptables log message? Following command has been executed in order to log the iptables log for ftp service : iptables -A INPUT -j LOG -p tcp --dport 22 --log-level warn Found following messages in log file: Feb 15 07:57:25 backupR3 kernel: IN=eth1 OUT=...

access.redhat.com

awesome! Thanks! Your searches are far better than mine apparently!! Any ideas on the strange IP source?

 

[dave14305]

Logging all packets in the firewall will eventually overwhelm the router’s logging capability. No need for it really. It leads to unnecessary anxiety.

 

[Jojo]

Logging all packets in the firewall will eventually overwhelm the router’s logging capability. No need for it really. It leads to unnecessary anxiety.

Funny you should mention unnecessary anxiety!! Yeah, I would normally leave off and randomly check, but I decided to watch just incoming for a few days after the install to see if anything weird or unexpected popped up and everything seemed good except those two unknowns I mention and I got stuck on them

 

[jzchen]

Thanks for the clarification! So I understand correctly, are you saying 6 pairs destination, 6pairs source mac and 2 pairs for indicating EtherType and they're all scrunched into the 14 pair MAC listed? Got it! Thanks again! Any ideas on the 30.46.144.1?

I searched and it appears to be of the public domain, so I suspect it is the default gateway just beyond your router...

 

[Jojo]

Using the very helpful information provided, I was able to determine the second non-standard MAC was between the destination being the Router/Lan and the source is my cell phone. So following that, the MAC beginning ff:ff:ff:ff:ff:ff is a dhcpoffer with the second 6 pairs being the source are the ISP's MAC address. I verified that none of my devices have the MAC of the offer.

I searched and it appears to be of the public domain, so I suspect it is the default gateway just beyond your router...

Are you referring to the gateway given to the router?

 

[jzchen]

Does your ISP require use of a gateway (like our AT&T does)? There's a "default gateway" that provides the WAN IP address for your service. That's the one I suspect....

 

[Jojo]

Using the very helpful information provided, I was able to determine the second non-standard MAC was between the destination being the Router/Lan and the source is my cell phone. So following that, the MAC beginning ff:ff:ff:ff:ff:ff is a dhcpoffer with the second 6 pairs being the source are the ISP's MAC address. I verified that none of my devices have the MAC of the offer.

Does your ISP require use of a gateway (like our AT&T does)? There's a "default gateway" that provides the WAN IP address for your service. That's the one I suspect....

There were no instructions other than plug it in it auto configured everything so the router was given the wan ip/public ip address, the DNS and assigned a default gateway to the router. Pretty painless. But the default gateway IP given the router does not match that IP. So I'm not sure I answered your question but I think we're referring to the same thing.

I searched and it appears to be of the public domain, so I suspect it is the default gateway just beyond your router...

Are you referring to the gateway given to the router?

 

[jzchen]

It's my understanding, and I may be incorrect, that your router's LAN IP address is the default gateway to your local network, and the default gateway ahead of your router/modem provides your WAN address, as well as others using your same ISP. I'm not very versed in terminology I'm afraid so when you say "given my router" it could be either of these two in my mind...

 

[Jojo]

Does your ISP require use of a gateway (like our AT&T does)? There's a "default gateway" that provides the WAN IP address for your service. That's the one I suspect....

Or are you saying this is the ISP's gateway and that it doesn't have to necessarily be in the ranges of their DNS or the default gateway IP range they assign to customer's routers?

 

[Jojo]

It's my understanding, and I may be incorrect, that your router's LAN IP address is the default gateway to your local network, and the default gateway ahead of your router/modem provides your WAN address, as well as others using your same ISP. I'm not very versed in terminology I'm afraid so when you say "given my router" it could be either of these two in my mind...

You are correct. The LAN IP is of a private subnet. The WAN IP is my public ip. The router itself has a different GW IP from another slightly different subnet and DNS from another ISP subnet range. My thought was maybe you were referring to the ISP GW at their location as that 30.46.144.1 address, but it is entirely different that any of the other IP's involved.

 

[Twiglets]

Logging all packets in the firewall will eventually overwhelm the router’s logging capability. No need for it really. It leads to unnecessary anxiety.

Translation:
Logging all packets in the firewall will eventually overwhelm the router’s logging capability users capabilities . No need for it really. It leads to unnecessary anxiety for the user.

 

[Jojo]

Translation:
Logging all packets in the firewall will eventually overwhelm the router’s logging capability users capabilities . No need for it really. It leads to unnecessary anxiety for the user.

maybe so! but at least the others are trying to be helpful

 

[jzchen]

You are correct. The LAN IP is of a private subnet. The WAN IP is my public ip. The router itself has a different GW IP from another slightly different subnet and DNS from another ISP subnet range. My thought was maybe you were referring to the ISP GW at their location as that 30.46.144.1 address, but it is entirely different that any of the other IP's involved.

You may have caught something then... There were times when I saw in the logs some IP address has tried (and thankfully failed) to log in to my router. The best advice was given by @RMerlin to disable access from WAN.

Scum of the www I guess....

 

[Twiglets]

maybe so! but at least the others are trying to be helpful

Sorry .... it was a joke !!!

I obviously missed you with it !!!

I do tend to be helpful ... Honest !!!

 

[dave14305]

kernel: ACCEPT IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:xx:xx:xx:xx:xx:xx:xx SRC=30.46.144.1 DST=255.255.255.255 LEN=352 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=332 MARK=0x8000000

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:

asuswrt-merlin.ng/release/src/router/rc/firewall.c at 5b063cb58066ffa9099bc4c1dd2b5a7d7d303760 · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

/* 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;

 

[Jojo]

You may have caught something then... There were times when I saw in the logs some IP address has tried (and thankfully failed) to log in to my router. The best advice was given by @RMerlin to disable access from WAN.

Scum of the www I guess....

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?