Packet received with own address as source address: Is it on the Wi-Fi adapters?

[lord_Galathon]

Hello,

I recently setup an RT-AC66U for my work with Merlin firmware, it's been running great for 48h now but I see the following messages being constantly logged:

May 29 09:17:57 kernel: eth2: received packet with own address as source address
May 29 09:17:57 kernel: eth1: received packet with own address as source address
May 29 09:21:32 kernel: eth1: received packet with own address as source address
May 29 09:24:33 kernel: eth2: received packet with own address as source address
May 29 09:28:28 kernel: eth1: received packet with own address as source address

and so on.

Which bring me to ask the following question:

The hardware addresses (MAC) for the br0 (LAN), eth0 (WAN), vlan1 (Wi-Fi?) and eth1 (Wi-Fi?) adapters are the same which I find odd. Is there a table somewhere that shows what those adapters actually translate to?

I'm showing the following in ifconfig:

br0 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <- internal LAN address

eth0 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <-WAN IP #1

eth0:2 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <-WAN IP #2

eth0:3 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <-WAN IP #3

eth0:4 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <- WAN IP #4

eth1 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 NO IP

eth2 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:8C NO IP

lo Link encap:Local Loopback Self explanatory

vlan1 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 NO IP

wl0.1 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:89 NO IP (and no idea...I'm guessing it's related to Wi-Fi SSIDs because I have two SSIDs, normal and guest mode)

wl1.1 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:8D NO IP (same as above)

When I use Wi-Fi analyzer on my cell phone to scan the wi-fi networks it returns the following MAC addresses:
54:A0:50:5C:BE:88 Main Wi-Fi
54:A0:50:5C:BE:89 Guest Wi-Fi separated from my LAN (perfect, the way I want it.)

I'm wondering if the messages I get in the log are related to the wi-fi network? I do have two more APs wired to the network, each with its own static IP to cover the manufacturing plant and warehouse area.

Thanks.

 

[DSwit]

Do either of the other access points use the same ssid as your RT-AC66U?

 

[lord_Galathon]

Yes. Both have the same SSID.

 

[DSwit]

You may want to try changing them to separate ssid's. This is a common cause of the log entries your concerned with.

 

[lord_Galathon]

I will try that and report back. It makes sense.

 

[mstombs]

Using same SSID for access points is a pretty common config, so clients can roam between them, but I am sure this is the reason since I also have occasional logs on 5GHz interface which I have like this

May 29 07:46:15 kernel: eth2: received packet with  own address as source address
May 29 11:08:30 kernel: eth2: received packet with  own address as source address
May 29 11:12:46 kernel: eth2: received packet with  own address as source address
May 29 11:14:09 kernel: eth2: received packet with  own address as source address
May 29 11:14:49 kernel: eth2: received packet with  own address as source address

I doubt the router listens to its own wired access point by wireless, so maybe a client is passing on broadcasts it receives?

 

[sfx2000]

Using same SSID for access points is a pretty common config, so clients can roam between them, but I am sure this is the reason since I also have occasional logs on 5GHz interface which I have like this

May 29 07:46:15 kernel: eth2: received packet with  own address as source address
May 29 11:08:30 kernel: eth2: received packet with  own address as source address
May 29 11:12:46 kernel: eth2: received packet with  own address as source address
May 29 11:14:09 kernel: eth2: received packet with  own address as source address
May 29 11:14:49 kernel: eth2: received packet with  own address as source address

I doubt the router listens to its own wired access point by wireless, so maybe a client is passing on broadcasts it receives?

Normally when this is seen is because of a network loop - see this from time to time with VM's if one is using bridging with virtual interfaces, and I've also had it happen with the bonding driver...

Odd... wouldn't expect to see it here, but perhaps something the br0 config... don't think it has anything to do with the wireless side.

@RMerlin - thoughts here?

 

[john9527]

Apparently there is also a wifi denial of service protection, CTS-to-self, that sounds like if could fit the bill (the firmware has the code for it, although I didn't check if it was implemented). I have one AC client that implements it, and about 1/2 the time it connects I get one of these messages for the 5GHz interface, eth2.

 

[sfx2000]

Apparently there is also a wifi denial of service protection, CTS-to-self, that sounds like if could fit the bill (the firmware has the code for it, although I didn't check if it was implemented). I have one AC client that implements it, and about 1/2 the time it connects I get one of these messages for the 5GHz interface, eth2.

CTS to Self is normally handled at the MAC layer and below, and shouldn't be passed up the stream to the linux kernel...

 

[RMerlin]

This frequently occurs when people have a laptop connected to both wireless and Ethernet at the same time, causing a loop.

 

[john9527]

CTS to Self is normally handled at the MAC layer and below, and shouldn't be passed up the stream to the linux kernel...

Was only making an empirical observation....
-I have one client that explicitly has an option for CTS-to-self (which is set as default)
-The only time is see the 'own address as source address' message is immediately before the DHCPREQUEST for that client is logged
-The message references the interface being used by that client (which is usually the only user of the 5GHz band)

I have separate SSIDs for each band, and that client has only the wireless interface in use. I agree it could be some other quirk of the wireless driver (7260AC), but did run across the CTS-to-self setting while investigating.

 

[sfx2000]

Was only making an empirical observation....
-I have one client that explicitly has an option for CTS-to-self (which is set as default)
-The only time is see the 'own address as source address' message is immediately before the DHCPREQUEST for that client is logged
-The message references the interface being used by that client (which is usually the only user of the 5GHz band)

I have separate SSIDs for each band, and that client has only the wireless interface in use. I agree it could be some other quirk of the wireless driver (7260AC), but did run across the CTS-to-self setting while investigating.

Completely Valid Observation - things like this can be a bear to troubleshoot via kernel messages alone - pcap's can help out on the debug side, getting down into the wires to sort what exact packets are bouncing around in the loop...

And RMerlin raised a good point about being doubled up (WiFi and Ethernet) as being something to consider...

If one goes back to the OP's ifconfig, note this:

br0 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <- internal LAN address
eth0 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <-WAN IP #1
eth0:2 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <-WAN IP #2
eth0:3 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <-WAN IP #3
eth0:4 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 <- WAN IP #4
eth1 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:88 NO IP
eth2 Link encap:Ethernet HWaddr 54:A0:50:5C:BE:8C NO IP

The bridge interface is on BE:88, along with eth0, and virtual eth0's bound across 4 IP's, which is ok... then we have eth1, which is bound to the same MAC addr as eth0, br0, and the vif's extended from eth0...​

kernel glitch with enumerating eth* interfaces with the various MAC addr's?

 

[sfx2000]

So when digging into something like this...

ethtool, along with its friends mii-tool and ip, plus ifconfig and tcpdump - these are all very useful tools... and then to see what the kernel is doing on init, dmesg | grep eth can be pretty helpful...

 

[john9527]

The bridge interface is on BE:88, along with eth0, and virtual eth0's bound across 4 IP's, which is ok... then we have eth1, which is bound to the same MAC addr as eth0, br0, and the vif's extended from eth0...

I don't know the reasoning behind it, but AFAIK all the ASUS routers have eth0 and eth1 sharing the same MAC address.

From my nvram.....

lan_hwaddr=XX:XX:XX:58:BC:88
wan0_hwaddr=XX:XX:XX:58:BC:88
wl0_hwaddr=XX:XX:XX:58:BC:88
wl0.1_hwaddr=XX:XX:XX:58:BC:89
wl0.2_hwaddr=XX:XX:XX:58:BC:8A
wl0.3_hwaddr=XX:XX:XX:58:BC:8B
wl1_hwaddr=XX:XX:XX:58:BC:8C
wl1.1_hwaddr=XX:XX:XX:58:BC:8D
wl1.2_hwaddr=XX:XX:XX:58:BC:8E
wl1.3_hwaddr=XX:XX:XX:58:BC:8F

 

[sfx2000]

I don't know the reasoning behind it, but AFAIK all the ASUS routers have eth0 and eth1 sharing the same MAC address.

From my nvram.....

lan_hwaddr=XX:XX:XX:58:BC:88
wan0_hwaddr=XX:XX:XX:58:BC:88
wl0_hwaddr=XX:XX:XX:58:BC:88
wl0.1_hwaddr=XX:XX:XX:58:BC:89
wl0.2_hwaddr=XX:XX:XX:58:BC:8A
wl0.3_hwaddr=XX:XX:XX:58:BC:8B
wl1_hwaddr=XX:XX:XX:58:BC:8C
wl1.1_hwaddr=XX:XX:XX:58:BC:8D
wl1.2_hwaddr=XX:XX:XX:58:BC:8E
wl1.3_hwaddr=XX:XX:XX:58:BC:8F

Oh wow... that might explain why some services get confused when they should be internal, but somehow end up external. Depending on how the br0 interface gets setup by the kernel, and how the IPTables are then structured, this could be a real rat's nest to change.

And that's for router mode, much less Bridge or AP-Only.

Uggh...

 

[sfx2000]

@RMerlin - you know the code here... comments?

 

[RMerlin]

@RMerlin - you know the code here... comments?

I know Asus does indeed use the same MAC for eth0 and eth1. No idea if this is on purpose or not, but I vaguely remember seeing at least one other router manufacturer who did that, so it could be for some specific reason. I'd rather not change something that's been working as it is for years without a complete understanding of it.

 

[sfx2000]

I know Asus does indeed use the same MAC for eth0 and eth1. No idea if this is on purpose or not, but I vaguely remember seeing at least one other router manufacturer who did that, so it could be for some specific reason. I'd rather not change something that's been working as it is for years without a complete understanding of it.

I agree - if it works, treat it as though it were a hive of angry bees...

Looking at it from face-value, might have made sense at some point... but with the WebGUI driving the bus, and IPTables in general, probably better to not worry about things

 

[Nexus]

I've been getting this same message the OP is referring to on my ASUS RT-N66U since forever. Post #8 from John prompted me to try something different on my Dell laptop with an Intel Centrino N-6230 adapter. In the Properties--Configure--Advanced section of my adapter, I changed Mixed Mode Protection from its default CTS-to-self Enabled to RTS/CTS Enabled. This change was applied on Friday afternoon. I've checked the system log on my ASUS since then and the "received packet with own address as source address" is no longer evident.

 

[lord_Galathon]

Wow that escalated quickly... Thanks to all that intervened.

As much as I'd love to be able to change the adapter properties to RTS/CTS, all the devices that connect to the Wi-Fi here are smart phones and tablets and don't have the option.

The error doesn't seem to be affecting anything else or slowing things down so for now I'll leave it be and just "acknowledge" the situation. All it seems to do right now is fill the log up.

BTW, I absolutely LOVE the interface and flexibility of this router. The fact that I can use and configure a normal domestic router with a decent firewall that I'm comfortable with, for a small business, is astounding and I thank everyone involved.