Kernel Warning - Received packet with own address as source address

Installing and Using OpenWrt
#1

Hi,

Regardless of build (19.07.x, DavidC502, etc) I get the same warning log on a regular basis (i.e from every few minutes to once every 30ish minutes). I assume it's down to mis-configuration on my part but I can't seem to find any reasonable answers via searches to self-diagnose.

"[kernel] br-lan: received packet on eth0.1 with own address as source address (addr: [Router MAC Address], vlan:0)"

Would be really grateful if anyone could point me in the right direction please?

/etc/config/network config below:

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd8d:ff6b:9c99::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth0.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.78.1'
        option broadcast '192.168.78.255'

config interface 'wan'
        option ifname 'eth1.2'
        option proto 'static'
        option ipaddr '192.168.24.254'
        option netmask '255.255.255.0'
        option gateway '192.168.24.1'

config interface 'wan6'
        option ifname 'eth1.2'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option peerdns '0'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 5t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '4 6t'
Received packet on lan1 with own address as source address
#2

There is probably some loop on your network, or some other device with the same IP address that the router is using.

2 Likes
#3

Thanks for response. I've checked static leases to be sure there are no IP / MAC conflicts with other clients but beyond that don't really know what else to look for. Any ideas on troubleshooting most welcome! Thanks

#4

Could it be a loop in your network? Could you post an schematic of your network?

You mentioned this happens sporadically, perhaps some random device in your network?

#5

Just to be sure, stop the loops:

uci set network.lan.stp='1'
uci commit network
ifup lan

To find the culprit first find the mac of your br-lan interface: ip link show br-lan | grep ether | awk '{print $2}'
Then use the mac in tcpdump:
tcpdump -i br-lan -evn not host 192.168.78.1 and ether host THE_MAC_HERE
This will show you any host using the mac address but not the router IP.

1 Like
#6

Thanks both for your responses. I've set STP but unfortunately this has made no difference. I've had a look at the tcpdump but it's hard to read as there is a lot of data..... it appears that there are a number of the clients that have been picked up (possibly all of them but I've not done a match on every MAC address). I'm not sure what to make of the results if I'm honest. As there are so many results would this identify a misconfiguration, or should I be looking for something particular?

Thanks again for your help.

#7

You can paste it here to have a look.

#8

Thanks Trendy - I've sent you a PM.

#9

So just to update for visibility to the forum - Trendy recommended the following script as it is more strict and should point only the lan host which is using the mac of the router, if any.

tcpdump -i br-lan -evn '(ether src host THE_MAC_HERE) and (not src host 192.168.78.1) and (src net 192.168.78.0/24)'

I've let the script run for around 4 hours but unfortunately it didn't pick up any results at all.

Any other suggestions would be most welcome!

Thanks again

#10

Did you find any log while you were running this?

#11

When I stopped the script it stated 0 packets captured:

image

Thanks Trendy...........

One thing I forgot to mention was my set up. I'm not sure if that might have any relevance but in any case:

Sky Q Hub -> LAN: (DMZ) Linksys WRT3200 (OpenWRT - Davidc502 r13342) -> Plume wireless SuperPod APs x4 (bridge mode) -> Wireless clients.

I also have a Linksys SE4008 WRT switch directly connected to the WRT3200 which serves a couple of wired clients. Would the switch have anything to do with the warning, and do I need to look into the WRT3200 port config at all? It was just a thought that occurred to me.

Thanks again!

#12

There are 2 possibilities for receiving a packet with the mac address of the lan interface.

  1. Some host is spoofing it. This is close to impossible in a controlled environment if you didn't change the mac address yourself.
  2. You have a loop in the network. Given the amount of switches and bridges it is more possible. There must be only one cable running from one device to the other and the bridges should not form any kind of wireless connection between them.
1 Like
#13

Ok thanks - that makes sense. I definitely haven't spoofed the router MAC address anywhere so item 2 looks more likely. As Plume AP's run a mesh network and I regularly roam around the house / APs I guess this may be a side effect. I will be more mindful of when I change location in the house and monitor the logs to see if I can find any patterns. I will also reach out to Plume support directly to see if they have any insight into the matter (Plume OS is also built on OpenWRT apparently) and will report back.

Thanks again, the support is really appreciated!

2 Likes
#14

This is it! Your router has a wired connection to each AP, and the mesh network interconnects APs, creating a loop.

#15

Hi,

Thanks for the response. I'm not 100% convinced about this if I'm honest as only one Plume AP has a wired connection to the router, the other APs create a wireless mesh to each other. I would assume that Plume would have thought about this when designing how the APs operate as my use case is very standard. Users only have two Plume configuration modes - router or bridge. I'm running them in bridge mode so they should take settings from the router (and do seem to).

As a note until recently I was running DD-WRT firmware for a long time with the same hardware, and didn't have any of these issues (just had other issues / lack of flexibility hence the move to OpenWRT). This leads me to believe that it's possibly my OpenWRT configuration that is at fault, not my Plume APs (which I can't really configure!).

Anyway thanks again, I'll see whether Plume support can shed any light.........

#16

I am not aware of Plume or its products, however if it was one time thing, it could be explained with a change in topology of the mesh.
If on the other hand it takes place regularly you'll have to track it and fix it. Since only one AP has wired connection to the router, then I would focus on the mesh part.

1 Like
#17

If there were a consistent loop, you'd expect that to rapidly fill up with copies of packets circulating. The symptom is that the network appears to lock up.

On the other hand, if the mesh very occasionally changes its topology, then a packet in the mesh might enter one side, and then the topology reconfigures, and it would exit back towards the router. If this happens briefly every so often, this is probably harmless.

#18

Thanks - that's interesting. I'll bear in mind when reviewing the logs and timings, although I don't think I would necessarily know when the mesh reconfigures (the Plume app does identify network optimisations but these are few and far between, every few weeks, and certainly don't match the kernel warnings I get regularly each day). Another question for Plume.

Thanks

1 Like
#19

I just observed similar symptoms on my r7500v2 configured as an AP only. Repeated kernel warning messages every couple of minutes. I don't use a mesh network but...

The AP only configuration I'm using has been stable in the past (I did not observe these symptoms - at least at this frequency); however, I just put this device back into service after a period of disuse for about a month and a half.

One recent change I made is to the switch config in which I configured one of the lan ports to forward my "trunk" network (two vlans) to a second AP. I tested this change and it functions like I want, but that AP is not on or even physically connected when these symptoms started.

EDIT: a warning message:

Tue Jul  7 08:57:51 2020 kern.warn kernel: [121402.650525] br-lan: received packet on eth0.3 with own address as source address (addr:XX:XX:XX:XX:XX:59, vlan:0)

my vlan tags are 2 and 3...

I just tried enabling STP for both the br-lan iface (one of the vlans) and also on second br iface (the other vlan for wifi "guests") but 2-3 warning messages continue to show up in my logs every couple of minuets. As I use my logs, I don't want these messages spamming them. Aside form these warnings, I don't seem to have network issues.

Since my network config is different than the OPs I think I should start a new thread to post my config - but that may take a day or two.

#20

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
1 Like