kernel: br0: received packet on eth1 with own address as source address

[eNORm]

Can we solve this once and for all?

I'm happy to give all info that is needed, just point me in the right direction.

-eNORm-

Jan  9 12:53:38 kernel: br0: received packet on eth1 with own address as source address
Jan  9 13:52:07 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:07 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:09 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:09 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:09 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:09 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:10 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:11 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:11 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:12 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:13 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:13 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:14 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:15 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:17 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:19 kernel: br0: received packet on vlan1 with own address as source address

 

[RMerlin]

Can we solve this once and for all?

I'm happy to give all info that is needed, just point me in the right direction.

-eNORm-

Jan  9 12:53:38 kernel: br0: received packet on eth1 with own address as source address

There's a bazillion posts about this already, and it's also been said that this will have to be resolved by Asus.

 

[Hexabion]

Can we solve this once and for all?

I'm happy to give all info that is needed, just point me in the right direction.

-eNORm-

Jan  9 12:53:38 kernel: br0: received packet on eth1 with own address as source address
Jan  9 13:52:07 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:07 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:09 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:09 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:09 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:09 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:10 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:11 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:11 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:12 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:13 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:13 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:14 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:15 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:17 kernel: br0: received packet on vlan1 with own address as source address
Jan  9 13:52:19 kernel: br0: received packet on vlan1 with own address as source address

Shouldnt LAN-> Switch -> Control -> Enable Spanning Tree Control fix that?
Thats what spanning tree checks/protocol are for anyway, to prevent loops like that.

 

[ehaesen]

No loop

After all the messages about this problem I think it should be clear that this is not a simple loop. And spanning tree protocol does not solve it, believe me I've tried.

I agree with eNORm, can Asus solve this once and for all. Too many people are having this problem.

Thanks.

Eric.

 

[xbrico]

I am seeing the same issue where DHCP is trying to offer my 2.4GHz radio MAC address an IP. There should be no reason DORA should be getting initiated from the radio - and DORA *should* be client initiated. I don't understand why the radio is requesting a L3 address - it shouldnt be.
Any way this could be in relation to WDS or bridging somehow initiating when its not required? I am in standard router mode (Router is controlling my PPPoE session over a dsl modem set to bridged mode - WAN port of AC87U going to dsl modem). Seems to randomly instigate, may be grand for days then this kicks off and floods logs with errors - sometimes multiple errors per second.
Any word even if this may be fixed in the 378 stream of FW? currently running 376.49_4

 

[coldwizard]

If the messages are bothering you, it is easy to suppress the messages.

# Definitely not from my own address(es)
iptables -I INPUT 3 -i ! lo -s `nvram get lan_ipaddr` -j DROP
iptables -I INPUT 3 -i ! lo -s `nvram get wan_ipaddr` -j DROP

Should do the job.

 

[ghoffman]

this is not limited of course to this router or even to asus.

there are circumstances where the 2.4g and 2.4g/5g radios appear to have the same mac addr (they are on the same bridge, and the bridge gets only one mac address). then a loop could occur.

another problem is with client bridging on broadcom - the devices behind the bridge get the mac address of the bridge.

finally - i wonder if this has somethig to do with packets being sent out when the radio is trying to autoselect a channel?

i have both of these scenarios and get a lot of those messages on my main router (currently an r6300v2, but i also have an ac68u that had the same problems) and the messages are decreased by using only one radio per router. i'm currently tring to figure out if the client bridges are the source of hte other messages.

does anyone get these messages with a setup that has no client bridges, no dual radio, and no auto-channel?

 

[xbrico]

I know for sure I am not running any bridging. I have it as straight Router/AP and am not trying bridging to any other router in the house (well, technically I am using a DDWRT Cisco/Linksys E4200 as a WNIC for my PS3, but these errors preceeded that).

When I get a raft of these errors coming though, they are usually accompanied by DHCP discover and request logs for my 2.4GHz wireless MAC only. I tried MAC filtering packets from itself too and this did not help - logs kept filling.

Currently, I am not noticing any serious negative impact, I will assume though this will start having overhead on CPU and RAM (noticed son's ipod went into a DHCP discover loop the other night and it ran the CPU up rightly, responses to the radio got over 150-200ms). Just be nice to know whats causing the issue and if it could be stopped rather than just hidden with a few iptables drop rules.

 

[dsring]

If the messages are bothering you, it is easy to suppress the messages.

# Definitely not from my own address(es)
iptables -I INPUT 3 -i ! lo -s `nvram get lan_ipaddr` -j DROP
iptables -I INPUT 3 -i ! lo -s `nvram get wan_ipaddr` -j DROP

Should do the job.

In an effort to keep from flooding the log with the 'kernel: br0: received packet on eth1 with own address as source address' messages, I set up a nat-start script on my RT-AC87U with the following lines:
iptables -I INPUT 3 -i ! lo -s `nvram get lan_ipaddr` -j DROP
iptables -I INPUT 3 -i ! lo -s `nvram get wan_ipaddr` -j DROP

It was my first time creating the script, and I used Merlin's guide (https://github.com/RMerl/asuswrt-merlin/wiki/User-scripts).

I did check that the script was running by inserting 'touch /tmp/000wanstarted' at the beginning of the script, and then confirmed the presence of 000wanstarted in the /tmp directory.

I am still getting the 'kernel: br0: received packet on eth1 with own address as source address' messages in my log.

Does anyone have any ideas on how the script can be changed to suppress these messages? Thanks.

 

[ghoffman]

I know for sure I am not running any bridging. I have it as straight Router/AP and am not trying bridging to any other router in the house (well, technically I am using a DDWRT Cisco/Linksys E4200 as a WNIC for my PS3, but these errors preceeded that).
Just be nice to know whats causing the issue and if it could be stopped rather than just hidden with a few iptables drop rules.

i agree completely that suppressing the errors is not a solution.

if a client has a mac addr from associating with anther network, then enters the home network, could these errors occur until the nic gets a new dhcp address on the home network?

 

[Puremin0rez]

I always get this message and every single time a device on the network drops and needs to be reconnected to gain access to the network again.

Wish ASUS would do something about it.

 

[coldwizard]

In an effort to keep from flooding the log with the 'kernel: br0: received packet on eth1 with own address as source address' messages, I set up a nat-start script on my RT-AC87U with the following lines:
iptables -I INPUT 3 -i ! lo -s `nvram get lan_ipaddr` -j DROP
iptables -I INPUT 3 -i ! lo -s `nvram get wan_ipaddr` -j DROP

It was my first time creating the script, and I used Merlin's guide (https://github.com/RMerl/asuswrt-merlin/wiki/User-scripts).

I did check that the script was running by inserting 'touch /tmp/000wanstarted' at the beginning of the script, and then confirmed the presence of 000wanstarted in the /tmp directory.

I am still getting the 'kernel: br0: received packet on eth1 with own address as source address' messages in my log.

Does anyone have any ideas on how the script can be changed to suppress these messages? Thanks.

The rules should be in firewall-start, this is where you will usually put your own custom rules for the filter table.

However to debug do the following.

1) Run the script from the command line with debugging turned on. I usually put the script in the file <script name>.sh so if I do something really bad, a reboot gets things back to normal and does not try to run a faulty script.
cd /jffs/scripts
edit the file to contain the commands "set -v" and "set -x" right after the #!/bin/sh line.
firewall-start.sh

2) Check the results of the script. In this case, use command
iptables -nvL INPUT --lin
You should see on lines 3 and 4 the rules with your numeric IP addresses.

3) Comment the lines with "set -v" and "set -x" commands, and rename the file to firewall-start (no .sh) so it will run on reboot. Set file security with "chmod 700 firewall-start" since it is always run by admin.

4) After a day, run the command
iptables -nvL INPUT --lin
You should see it's usage counters be non-zero.

 

[eNORm]

Shouldnt LAN-> Switch -> Control -> Enable Spanning Tree Control fix that?
Thats what spanning tree checks/protocol are for anyway, to prevent loops like that.

Dont have that option on my 87, using it as a AP.

 

[eNORm]

Look at these messages. Every hour, there seams to be a flood. Even at night time when there is very little traffic on the wifi. This is an office wifi, so mostly in use at daytime. CET.

Are there some services that run every hour that triggers this?

Feb 18 14:03:36 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 14:03:37 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 14:03:37 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 14:03:38 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 14:03:39 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 14:03:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 14:03:41 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 14:03:42 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 14:03:43 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 15:02:17 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 15:02:17 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 15:02:18 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 15:02:19 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 15:02:20 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 15:02:21 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 15:02:22 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 15:02:23 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:48 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:48 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:48 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:48 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:48 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:48 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:48 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:50 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:50 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:54 kernel: net_ratelimit: 18 callbacks suppressed
Feb 18 16:01:54 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:54 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:55 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:55 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:55 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:55 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:55 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:55 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:56 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:56 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:59 kernel: net_ratelimit: 4 callbacks suppressed
Feb 18 16:01:59 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:59 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:59 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:01:59 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:02:01 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:02:01 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:02:01 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 16:02:01 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:41 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:41 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:41 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:46 kernel: net_ratelimit: 26 callbacks suppressed
Feb 18 17:01:46 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:46 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:46 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:46 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:46 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:46 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:46 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:47 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:47 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:47 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:52 kernel: net_ratelimit: 7 callbacks suppressed
Feb 18 17:01:52 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:52 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 17:01:52 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 18:01:36 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 18:01:36 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 18:01:37 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 18:01:38 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 18:01:39 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 18:01:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 18:01:41 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 18:01:42 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 19:01:33 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 19:01:33 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 19:01:34 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 19:01:35 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 19:01:36 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 19:01:37 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 19:01:38 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 19:01:39 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 20:01:28 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 20:01:28 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 20:01:29 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 20:01:30 kernel: br0: received packet on vlan1 with own address as source address

 

[eNORm]

Rest of the log file.

Feb 18 20:01:31 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 20:01:32 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 20:01:33 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 20:01:34 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:20 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:20 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:21 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:21 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:22 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:22 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:23 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:23 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:24 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:25 kernel: net_ratelimit: 1 callbacks suppressed
Feb 18 22:01:25 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:25 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:26 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:26 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:27 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 22:01:27 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 23:01:12 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 23:01:12 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 23:01:13 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 23:01:14 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 23:01:15 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 23:01:16 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 23:01:17 kernel: br0: received packet on vlan1 with own address as source address
Feb 18 23:01:18 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 00:01:11 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 00:01:11 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 00:01:12 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 00:01:13 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 00:01:14 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 00:01:15 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 00:01:16 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 00:01:17 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 01:01:04 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 01:01:05 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 01:01:06 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 01:01:07 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 01:01:08 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 01:01:09 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 01:01:10 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 01:01:11 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 02:01:02 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 02:01:02 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 02:01:03 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 02:01:04 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 02:01:05 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 02:01:06 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 02:01:07 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 02:01:08 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 03:00:57 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 03:00:57 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 03:00:58 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 03:00:59 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 03:01:00 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 03:01:01 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 03:01:02 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 03:01:03 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 04:00:53 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 04:00:53 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 04:00:54 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 04:00:55 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 04:00:56 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 04:00:57 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 04:00:58 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 04:00:59 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 05:00:48 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 05:00:48 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 05:00:49 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 05:00:50 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 05:00:51 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 05:00:52 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 05:00:53 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 05:00:54 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:39 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:39 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:39 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:39 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:40 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:41 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:41 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:42 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:44 kernel: net_ratelimit: 3 callbacks suppressed
Feb 19 07:00:44 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:44 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:45 kernel: br0: received packet on vlan1 with own address as source address
Feb 19 07:00:45 kernel: br0: received packet on vlan1 with own address as source address

 

[eNORm]

Bump

 

[RMerlin]

Bump

Bumping this needlessly won't change the answer that was already given in the second post of this thread.

 

[KevTech]

Bump

Posting on a user to user forum over and over again is not going to help as people have told you that Asus has to fix this.

If you want to even have a chance of getting this fixed you have to let Asus know so email to this address with your log/complaint: Networking_Support@asus.com

 

[RocketJSquirrel]

Popping in here from the John fork thread.

The iptables commands shown above just give me an error message.

# iptables -I INPUT 3 -i ! lo -s `nvram get lan_ipaddr` -j DROP
Bad argument `lo'
Try `iptables -h' or 'iptables --help' for more information.

I'm a complete ignoramus when it comes to the iptables command, but it looks like maybe the "!" is in the wrong place?

 

[coldwizard]

Popping in here from the John fork thread.

The iptables commands shown above just give me an error message.

# iptables -I INPUT 3 -i ! lo -s `nvram get lan_ipaddr` -j DROP
Bad argument `lo'
Try `iptables -h' or 'iptables --help' for more information.

I'm a complete ignoramus when it comes to the iptables command, but it looks like maybe the "!" is in the wrong place?

I just did a copy /paste of the iptables command from your post to my command line, and it worked just fine. Thinking ....