getting a lot of 'br-lan: received packet on eth0.1 with own address as source address'.
The router involved has a fixed mac address of 00:11:22:33:44:55 in CFE. I already have this 'clone' on my lan in my main router.... which is also showing a lot of these....
I can set a new MAC in br-lan (e.g. 00:11:22:33:55:55), but it does not seem to make any difference.
So I assume that the two routers are detecting the eth0/eth0 conflict of MAC address.
I've already bricked one router by trying to hand-modify the CFE and writing it over mtd0 (I guess it's checksummed, oh well).
I don't think there is any populated 'NVRAM' in the routers (nvram mtd5 seems empty).
cat /proc/mtd gives:
the router is a BT Homehub V2A (bcm 63xx), running
LEDE Reboot 17.01.0 r3205-59508e3 / LuCI lede-17.01 branch (git-17.051.53299-a100738)
Any bright ideas appreciated :). I have a couple more of these routers, and they are pretty useless if they can't share a lan!
(I do want to use switch functionality, as this will be an OpenVPN client with one port looking out, and three ports as my private lan).
to post an answer to my own question;
After much more googling, I came across: https://onetransistor.blogspot.co.uk/2016/02/debrick-huawei-hg553-brcm6358-cfe.html
where modifying the CFE data area containing the mac address is explained.
I've produced a modified version with correct CRC32, and will flash the next router... and post back here if successful, and the steps to do it from within lede. If it's bricked, at least I'll have another doorstop!
s
instructions from lede prompt:
NOTE: these instructions are based on the CFE danitool produced for the BT Homehub 2A; if doing this on any other CFE, be very sure to check that the byte offsets make sense...
use ifconfig, and see that eth0 mac 00:11:22:33:44:55
cat /dev/mtd0 >cfe.bin
(copy file off to a windows machine - I used scp to a linux box with samba on it)
edit bytes 0x6a0-0x6a5 to a new (valid) mac (I used HxD).
set bytes 0x6A8-0x6AB to zeros (the crc).
Copy the block 0x580-0x6AB and paste into a new file, and save (e.g. crc.bin).
Use the crc32 program from the link above in windows like:
crc32le crc
gives something like:
CRC32: 0x8b75a384
enter these bytes in order over 0x6A8-0x6AB in the CFE file.
save the file (e.g. cfe-modified.bin), and copy back to the router.
cat /proc/mtd lists the available mtd partition names. mtd0 is 'CFE'
then in lede prompt:
mtd write cfe-modified.bin CFE
as a double check, read back using cat /dev/mtd0 >cfenew.bin, copy back to windows and compare with your modified file (e.g. in HxD).
reboot and cross fingers....
use ifconfig, and see that eth0 mac is now your new mac!
sorry to revive the old post...i have 3-4 router option globe surfer x1. some with cc and one with lede. all but lede has those error kern.warn kernel: [ 1706.730000] br-lan: received packet on eth0.1 with own address as source address every 5 minutes log. stp is off on those. Tried modiefied different hw mac (using ifconfig/edit etc/config/network)..not working..never tried cfe method. The lede has no such error. Atm I ignored those error..on cc
is your cfe change mac address works ? on what version of openwrt ?`
Linux 3.18.20 #1 Fri Sep 4 19:34:21 CEST 2015 mips GNU/Linux openwrt 15.05 on option globe gsx..configured it as client..no dhcp server no wireless, only lan activated ..2 port configured as single vlan.and I turned off ipv6. It happen on multiple network, and also happen on closed network ( gsx with laptop connection only, no internet no other client) just gsx and my laptop via single lan cable.
here's network config
logread | grep br-lan
Mon May 6 10:25:47 2019 kern.warn kernel: [ 288.490000] br-lan: received packet on eth0.1 with own address as source address
Mon May 6 10:30:03 2019 kern.warn kernel: [ 544.490000] br-lan: received packet on eth0.1 with own address as source address
Mon May 6 10:34:19 2019 kern.warn kernel: [ 800.490000] br-lan: received packet on eth0.1 with own address as source address
Mon May 6 10:38:35 2019 kern.warn kernel: [ 1056.490000] br-lan: received packet on eth0.1 with own address as source address
Mon May 6 10:42:51 2019 kern.warn kernel: [ 1312.490000] br-lan: received packet on eth0.1 with own address as source address
Mon May 6 10:47:07 2019 kern.warn kernel: [ 1568.490000] br-lan: received packet on eth0.1 with own address as source address
Mon May 6 10:51:23 2019 kern.warn kernel: [ 1824.490000] br-lan: received packet on eth0.1 with own address as source address
Mon May 6 10:55:39 2019 kern.warn kernel: [ 2080.490000] br-lan: received packet on eth0.1 with own address as source address
Mon May 6 10:59:55 2019 kern.warn kernel: [ 2336.490000] br-lan: received packet on eth0.1 with own address as source address
Mon May 6 11:04:11 2019 kern.warn kernel: [ 2592.490000] br-lan: received packet on eth0.1 with own address as source address
Are you sure there are no other devices in your network with the same MAC address?
In your first post you mentioned "i have 3-4 router", how are those routers connected? how are they configured? are you sure there isn't a loop in your connections?
I tried gsx one at a time. So on closed network only 1 laptop and one gsx in the network connected via cable. So I`m sure no other device connected.
I dont know how to detect loop, but if i turn on stp protection ..the error pop up every 10 second (not 5minutes like my previous config).
Tried lede build and the error is gone, but lede is too heavy for this 32m ram. Back to 15.05 with same error now.
Sorry to respond to such an old post, also been seeing this, seems to occur when I run iftop.
I suspect when a process enables filtering / listening on br-lan there wlan0 and eth0.1 which have the mac results in this messages and also disable of wlan0.
I worked around this with (RPI4)
#!/bin/bash
dmesg -T -x --follow |
while read LINE
do
if [[ "$LINE" == *"received packet on wlan0 with own address"* ]]; then
sleep 1
echo "RESTART hostapd: $LINE" >> /var/log/wlan0.log
systemctl restart hostapd
fi
done
A switches multiple vlans typically all use the same mac address. If you need to bridge two interfaces that are sharing macs, then don't use the real physical interface, create one through it using kmod-macvlan so you keep those collisions away, and ideally do it on both sides of the vlan so that the real interfaces that are sharing a mac never communicate in a way that would loop like this.