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

[RocketJSquirrel]

I'm still getting the messages. I can apparently generate them at will by moving between my 2 access points with my iPhone & iPad.

 

[RocketJSquirrel]

I expect the fe80 on rule 3 is from the br0 interface.

That IPv6 address appears as Scope:Link in all of br0, eth0, eth1, and vlan1 in the ifconfig output. (Sorry I don't know what any of this means. During my software career, my area of expertise was user interface design & development. I staunchly stayed away from both networking and server-side software. And IPv6 was only a gleam in someone's eye.)

 

[coldwizard]

I'm still getting the messages. I can apparently generate them at will by moving between my 2 access points with my iPhone & iPad.

We only have two addresses left. Getting them would indicate a configuration problem with a computer I believe.

Can you add for ipv4 the rule
iptables -I INPUT 3 ! -i lo -s 127.0.0.1 -j DROP

and for Ipv6 the rule
ip6tables -I INPUT 1 ! -i lo -s ::1 -j DROP

These are the IP addresses from the lo interface and should never be sent outside the local computer. A programmer may have used ::1 rather than ::0 which is permitted as a source address on a lan.

Tomorrow (or this weekend, if I am busy) I will design the script for Ipv6 and explain what I think are the consequences of what we have found so far. I think we are reducing the number of messages, even if we don't delete them all.

 

[RocketJSquirrel]

We only have two addresses left. Getting them would indicate a configuration problem with a computer I believe.

Can you add for ipv4 the rule
iptables -I INPUT 3 ! -i lo -s 127.0.0.1 -j DROP

and for Ipv6 the rule
ip6tables -I INPUT 1 ! -i lo -s ::1 -j DROP

These are the IP addresses from the lo interface and should never be sent outside the local computer. A programmer may have used ::1 rather than ::0 which is permitted as a source address on a lan.

I added these loopback rules, but they haven't caught anything. I'm seeing one v4 rule and one v6 rule which are dropping packets. And I am still getting the "own address" warning when one of my mobile devices moves from the router to the secondary WAP. The flood of warnings has been reduced to a trickle.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target  prot opt in  out  source  destination
1  29  1706 DROP  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state INVALID
2  5216  629K ACCEPT  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
3  0  0 DROP  all  --  !lo  *  127.0.0.1  0.0.0.0/0
4  0  0 DROP  all  --  !lo  *  76.126.27.xxx 0.0.0.0/0
5  45  6377 DROP  all  --  !lo  *  192.168.1.1  0.0.0.0/0
6  3  1620 DROP  udp  --  *  *  0.0.0.0/0  0.0.0.0/0  udp dpt:9999
...

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target  prot opt in  out  source  destination
1  0  0 DROP  all  !lo  *  ::1/128  ::/0
2  0  0 DROP  all  !lo  *  fe80::blah:blah:blah:8201/128  ::/0
3  0  0 DROP  all  !lo  *  fe80::blah:blah:blah:8204/128  ::/0
4  822 98640 DROP  all  !lo  *  fe80::blah:blah:blah:8200/128  ::/0
5  0  0 DROP  all  !lo  *  2001:blah:blah:blah:6f79/128  ::/0
6  0  0 DROP  all  !lo  *  2601:blah:blah:blah:8200/128  ::/0
...

 

[coldwizard]

I added these loopback rules, but they haven't caught anything. I'm seeing one v4 rule and one v6 rule which are dropping packets. And I am still getting the "own address" warning when one of my mobile devices moves from the router to the secondary WAP. The flood of warnings has been reduced to a trickle.

As usual, test it in a .sh file ending so you can recover if something goes wrong.

Here is the new script which gets past manually entering ipv6 addresses. It handles both the ipv4 and ipv6 rules.
As it is, it will log the first 24 dropped packets and if they are happening fast, drop to only one every 5 minutes. You need to check the variables InsLoc# to see it they are correct for you. Also it tells you how to stop the logging.
The one change from the rules you have is it lets past ipv6 icmp traffic. I was getting drops of the icmp traffic, but when I let it past did not get any of those log entries. Of course, the only machine I have that triggers the messages is ipv4 only.

Anyway if you could try it with logging for a test, you should see logs like

kernel: DROP IPV4 INVALID IN=br0 ... SRC=192.168.1.1 DST=255.255.255.255 ... TTL=64 ... PROTO=UDP SPT=67 DPT=68

What I want you to pay attention to is the TTL= field, if that decreases for a cluster (in time) of packets for the same PROTO, SPT,DPT fields it could indicate a possible broadcast storm.
In this case, the protocol UDP, source port 67, destination port 68 means it was a packet associated with DCHP activity.

#!/bin/sh
# set -v
# set -x
# kill packets from my own addresses
#
TARGET=DROP
# comment the next line to stop logging
TARGET=sickbird
#
# you want to place these rules after the rule ending with "state RELATED,ESTABLISHED"
# use "iptables -nvL INPUT --lin" and "ip6tables -nvL INPUT --lin" to display current rules
#
# Where to insert Ipv4 rules into INPUT chain (change if not correct)
InsLoc4=3
# Where to insert Ipv6 rules into INPUT chain (change if not correct)
InsLoc6=4
#
#  First for Ipv4 addresses
#
# ***** make sure the sickbird chain exists ****
iptables -N sickbird
iptables -I sickbird 1 -j DROP
# log the first 24 then only 12 per hour
iptables -I sickbird 1 -m limit --limit 12/hour --limit-burst 24 -j LOG --log-level warning --log-tcp-sequence --log-tcp-options --log-ip-options --log-prefix "DROP IPV4 INVALID "
#
Ipv4List=`ifconfig | grep -i "inet addr:"  | awk '{print $2 " "}' | awk '{FS = ":" }{print $2 " "}' | sort -u `
for myIP in $Ipv4List
do
#  insert rule to DROP/log packet
   echo "Rule created for $myIP"
   iptables -I INPUT $InsLoc4 ! -i lo -s $myIP -j $TARGET
done
# Get local network ipv6 global address and /mask (only first if more than one)
IP6wMASK=`ifconfig br0 | grep -i "inet6 addr:" | grep -i "Scope:Global"  | head -1 | awk '{print $3}'`
# may not have ipv6 address yet for br0
if [ "x$IP6wMASK" != "x" ]
then
#
#  Now for Ipv6 addresses
#
#    ***** make sure the sickbird chain exists ****
   ip6tables -N sickbird
   ip6tables -I sickbird 1 -j DROP
#    log the first 24 then only 12 per hour
   ip6tables -I sickbird 1 -m limit --limit 12/hour --limit-burst 24 -j LOG --log-level warning --log-tcp-sequence --log-tcp-options --log-ip-options --log-prefix "DROP IPV6 INVALID "
#
   Ipv6List=`ifconfig | grep -i "inet6 addr:" | grep -v "Scope:Compat" | awk '{print $3 " "}' | awk '{FS = "/" }{print $1 " "}' | sort -u `
   for myIP in $Ipv6List
   do
#     insert rule to DROP/log packet
      echo "Rule created for $myIP"
      ip6tables -I INPUT $InsLoc6 ! -p ipv6-icmp ! -i lo -s $myIP -j $TARGET
#
   done
#
else
   echo "No global Ipv6 address on br0, assume Ipv6 not used on lan"
fi
#

Edit to upload a copy of the text above in a file.

 

[RocketJSquirrel]

I'll take a stab at this tomorrow. In the meantime, I've added my own motto to my signature as a sort of counterpoint to yours.

 

[coldwizard]

I'll take a stab at this tomorrow. In the meantime, I've added my own motto to my signature as a sort of counterpoint to yours.

I forgot to say you do not need to do the logging for long..If you get 30 logs lines that should be all you need to see if TTL changes. Then you can disable the logs if you want.

 

[coldwizard]

I forgot to say you do not need to do the logging for long..If you get 30 logs lines that should be all you need to see if TTL changes. Then you can disable the logs if you want.

Since we can stop the messages with iptable rules, we have to conclude that these are real packets coming back to the router.


How can they come back?

What is the consequence of this?

I can only think of two ways:

1. a network loop
   
   
2. A device is sending the packet back.
   

I know that not possible in my network, and if it happened would you not see two packets coming in close together in time. One from each direction around the loop? I get only one.

So that leave the possibility 2 a device sending it back. Routers (or devices acting like one) should not be sending a broadcast packet out on the same interface it came in on. Lets analyze what the symptoms would be if we have devices that are echoing the 255.255.255.255 addressed packet.


One device on network:

packet goes out from router, device echos it, router drops it. Network had one extra packet not noticeable.


Two devices on network:

packet goes out from router, device A echos it, device B sees echo by A and adds second packet to queue to be echoed. Device B echos first packet from router, and second packet from device A with TTL one less. Device A sees both packets from B and echos those ....continues until TTL=0 adding 2 times the TTL packets to network. Maybe noticeable if you were looking for it.


Three devices on network:

packet goes out from router, device A echos it, both device B and C save echoed packet. Device B echos the two packets it now has, and both device A and C see pair of packets. Device C sends its 4 packets and A and B see them. This doubles at each step, and now you will have a packet storm. The increasing number of packets will quickly saturate the network and severely affect other traffic. Once the storm is over, the network will return to normal until someone sends a 255.255.255.255 packet to start the storm. The symptom of this would be a network with spikes of extreme traffic.


So if we look at the pattern TTL of the packets returning, we could detect the presence of two or more devices that are echoing. This assumes they can see each other, but if they are isolated for some reason, they may not be able to, and the pattern would be simpler just multiple echos with no change to TTL.



So can we safely ignore these messages without looking at the log of them? Where is the fix or configuration change needed? How do we find the devices that are echoing to packets?

 

[ColinTaylor]

@coldwizard I think you're getting ahead of yourself here. Let's wait and see whether this actually stops the messages @RocketJSquirrel is seeing and if so, what kind of packets they are.

@RocketJSquirrel Out of interest, when your devices change from one access point to the other, how many messages (typically) does it generate in the syslog? I only ever see one per change.

 

[RocketJSquirrel]

@coldwizard I think you're getting ahead of yourself here. Let's wait and see whether this actually stops the messages @RocketJSquirrel is seeing and if so, what kind of packets they are.

Getting a slow start this Saturday morning, haven't tried the script yet.

@RocketJSquirrel Out of interest, when your devices change from one access point to the other, how many messages (typically) does it generate in the syslog? I only ever see one per change.

I also see only one message at a time. If I take iPhone & iPad away from the router and into the vicinity of the Netgear WAP, each one will cause one line to be added to syslog.

Without the iptables squelching, I get dozens of these lines, maybe 100/day, without physically moving any devices.

 

[RocketJSquirrel]

OK, I rebooted and ran your script, @coldwizard and the syslog is showing many lines already, and they're mostly, but not all, the same:

Oct 24 11:59:29 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 11:59:46 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:00:07 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:00:27 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:00:46 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:00:59 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:01:16 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:01:28 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=192.168.1.255 LEN=237 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=217
Oct 24 12:01:28 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=192.168.1.255 LEN=237 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=217
Oct 24 12:01:34 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:01:51 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:02:11 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:02:36 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105

Interesting.

 

[RocketJSquirrel]

And the occasional oddball line:

Oct 24 12:04:56 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF OPT (94040000) PROTO=2

 

[ColinTaylor]

Interesting. So it looks like it's mostly SSDP. I wonder if it's the media server on the router or some device on your network, i.e. blu-ray player, smart TV, Windows Media Player (sharing media), printer.

It also begs the question as to why this appears to effect you more than others. I guess it's because the mystery device is connected to your Netgear AP.

 

[RocketJSquirrel]

The Netgear WAP is in my home theater, to support the few devices there which lack Ethernet. Everything with an Ethernet socket is wired to the Asus router.

Ooh, one of the "own address" messages snuck through the filter.

Oct 24 12:45:46 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=224.0.0.251 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF OPT (94040000) PROTO=2
Oct 24 12:52:03 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF OPT (94040000) PROTO=2
Oct 24 12:54:58 kernel: br0: received packet on eth1 with own address as source address
Oct 24 12:56:14 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF OPT (94040000) PROTO=2

 

[ColinTaylor]

My gut feeling is that you won't stop the messages relating to the mobile devices switching APs with this method. But as they should be few and far between it shouldn't be a problem.

Tracking down the source of the Multicast DNS (mDNS)/224.0.0.251 and SSDP/239.255.255.250 could be difficult. Got any Apple media servers by any chance? Still can't think why they have 192.168.1.1 as the source.

 

[coldwizard]

OK, I rebooted and ran your script, @coldwizard and the syslog is showing many lines already, and they're mostly, but not all, the same:

Oct 24 11:59:29 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 11:59:46 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:00:07 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:00:27 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:00:46 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:00:59 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:01:16 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:01:28 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=192.168.1.255 LEN=237 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=217
Oct 24 12:01:28 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=192.168.1.255 LEN=237 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=217
Oct 24 12:01:34 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:01:51 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:02:11 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105
Oct 24 12:02:36 kernel: DROP IPV4 INVALID IN=br0 OUT= MAC= SRC=192.168.1.1 DST=239.255.255.250 LEN=125 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=1008 DPT=1900 LEN=105

Interesting.

Only one ending with .255 which is a broadcast type like 255.255.255.255 was shown with 2 same packets close in time. By my logic in the post earlier today this would indicate 2 devices that cannot see each other.

By now the logging is limiting to one every 5 minutes. so we would not see close duplicated if they happened.

If you do a iptables -nvL sickbird --lin you should see a difference in the usage counts on the rules. That difference is how many are being dropped with no logging.

You can change the script to create rules that do not log, if you wish. You do not need to reboot, when you run the script the new rules will be placed before the existing ones, and since they DROP the packet, it will never reach the old copy of the rules.

I need to think about what you have told us today.

 

[coldwizard]

Since we can stop the messages with iptable rules, we have to conclude that these are real packets coming back to the router.

I keep coming back to this. Are the packets really coming from outside the router, or is Asus inserting them into the input queue? Why?

 

[coldwizard]

Ooh, one of the "own address" messages snuck through the filter.

I think this is case of there being crayons along with those toys that the child knocked onto the floor and they are leaving marks.

I will try to answer my own questions.

Can we locate the device causing the messages?

I think still having one of the "own address" messages sneak through the filter, tells us that it is Asus that is reusing code, and forgetting about the crayons in the mix. This also means that my assumption that the packets were coming from outside could likely be wrong. Asus could just as easily be inserting the packets into the input queue to reuse that code as they must be doing elsewhere.
So the device causing the messages is Asus router itself!

So can we safely drop these messages?

We don't know the reason for reusing the code, so there could be side effects from dropping them. I have not noticed any, but I use only basic features of the router. It would appear that as you use more features, you get more messages.

Where is the fix or change needed?

Asus needs to fix the problem. Maybe create specific code to handle the reason they are reusing the code.


So we have a script that can reduce the number of the messages, but I leave it up to you to decide if you want to use it and risk any side effects.

 

[RocketJSquirrel]

I looked at basic squelching. The syslogd built in to BusyBox is set like this on my router:

syslogd -m 0 -O /tmp/syslog.log -S -s 256 -l 7

(I don't know whether that prints up to severity 7 or up through severity 7, though.)
The annoying log entry is printed with

#define br_warn(__br, format, args...) \
                br_printk(KERN_WARNING, __br, format, ##args)

It appears KERN_WARNING is 4, which is pretty high. I probably don't want to drop that many warnings from syslog. It's too bad this message isn't assigned level KERN_DEBUG or even KERN_INFO because I could see setting syslogd to squelch that level.

 

[Toddimus]

For what it's worth, I was having the "kernel: br0: received packet on vlan1 with own address as source address" messages on my main router completely filling the log. I had tried multiple things and was unable to isolate the problem. My setup might be somewhat unconventional:
Main router - RT-AC87R running Merlin 378.56_2
Second router - RT-AC87R running Merlin 378.56_2 - Configured as router but using WDS to create a wireless link to the main router (as opposed to a direct ethernet line)

I recently updated the second router to Merlin 380.57 and then proceeded to reset to factory defaults twice (for good measure). I then re-configured it with very limited options as before (i.e. DHCP, port forwarding, etc. handled by main router). I haven't seen the messages show up in the main router's log since this upgrade to the second router. It's been 36 hours now. Previously, I would start seeing the messages within 12 hours of a main router reboot. Once they started, they never stopped until a reboot of the main router.

I plan to update the main router to 380.57 in the next day or so, and I'll manually reconfigure everything, instead of using John's config tool.

UPDATE 1/25/2016 -- Still haven't gotten around to updating the main router to 380.57 but the update to the second router has seemingly fixed the problem. Almost 7 days of uptime and no "kernel: br0:.." messages on the main router. Well done Merlin (and Asus??)!