RT-AX86S and saved syslog showing: kernel: br0: received packet on eth1 with own address as source address

[rappel]

So, purchased new router before Christmas. Installed and running OK. This to replace an ageing Draytek, which was solid but couldn't process the new 300M fibre link.

No real issues, everything was fast and looked OK. Then we had one or two instances of delayed page loading in browsers on wired and wireless devices and the odd pause in streaming services.

Had a look and could see nothing in the log. Did speedtests on the link but all looked OK.

A month ago we noticed that the same issues of loading and pausing have gotten slightly worse but it was once every couple of days and the fibre is Gigaclear and they have had issues in this area in the past.

This week it's got particularly bad and we're experiencing this regularly.

Still nothing in the log and still the speedtests seem OK, although they have taken longer to get to full speed both up and down. ...and yes I could be imagining some of that.

Then I decided to save the system log and have a closer look.

I was surprised to find that the saved log bears absolutely no resemblance to the system log displayed through the web UI.

Equally it was clear that there are many, many repeats of the message in the title and netratelimits on the log (see below for an extract of the router log) so I ahve a feeling that whatever is going on it may be the cause of my issues but I don't know that for sure.

My limited understanding is that this indicates duplicate addresses on devices, but I've checked what is showing on the network, both in the router and with a scanner and I can find nothing showing active with the same address (I'm assuming it's IP, not MAC but that may be invalid)

Nearly all my kit is set to static addresses and I am certain that I have never set up anything with the router address except the old router, which is now in recycle heaven so it's not that.

All equipment has been rebooted, several times today actually as I have had work done on the house power butit continues to happen.

I've checked the only new device added since Christmas - but as that was only added this afternoon it's long after the issue was there anyway.

Updated to latest firmware today but still the same.

I've seen in a number of forums that historically there have been issues with this message and ASUS routers, but not found anything about whether this was proven as an Asus issue or not and if so whether it got fixed.

Only other thing I noticed slightly odd was in the system log routing table, but it may just be me not understanding the content.

It shows:
Destination Gateway Genmask Flags Metric Ref Use Type Iface
default 217.146.96.120 0.0.0.0 UG 0 0 0 WAN0 ppp0
169.254.0.0 * 255.255.0.0 U 0 0 0 MAN0 eth0
192.168.27.0 * 255.255.255.0 U 0 0 0 LAN br0
192.168.101.0 * 255.255.255.0 U 0 0 0 br1
192.168.102.0 * 255.255.255.0 U 0 0 0 br2
217.146.96.77 217.146.96.120 255.255.255.255 UGH 1 0 0 WAN0 ppp0
217.146.96.78 217.146.96.120 255.255.255.255 UGH 1 0 0 WAN0 ppp0
217.146.96.120 * 255.255.255.255 UH 0 0 0 WAN0 ppp0

Essentially the odd bit is LAN is showing three interface br0, 1 and 2. 1 and 2 have destination defaults of 101 and 102 subnets.
not sure what these interfaces are.

So if anyone could suggest things to try to recitfy the ...own address as source address messages as I suspect that will cure the issues I am experiencing.
Meanwhile if anyone can explain why the saved syslog isn't the displayed syslog
and if anyone can explain what I'm seeing in the routing table

I'd be very grateful.

Thanks.


------------------
log extract

Mar 15 22:33:18 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:31 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:32 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:33 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:35 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:38 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:43 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:44 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:45 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:47 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:53 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:33:58 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:11 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:18 kernel: net_ratelimit: 12 callbacks suppressed
Mar 15 22:34:18 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:22 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:23 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:25 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:36 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:38 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:34:58 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:18 kernel: net_ratelimit: 13 callbacks suppressed
Mar 15 22:35:18 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:36 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:38 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:35:58 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:10 kernel: br0: received packet on eth1 with own address as source address
Mar 15 22:36:18 kernel: net_ratelimit: 13 callbacks suppressed

 

[PunchCardBoss]

Essentially the odd bit is LAN is showing three interface br0, 1 and 2. 1 and 2 have destination defaults of 101 and 102 subnets.
not sure what these interfaces are.

These appear to be Guest WiFi connections. Asus Routers will commonly assign psudo-VLANs for Guest WiFi connections.

Suggest you disable Guest WiFi operations to verify these LAN IPs disappear.

 

[PunchCardBoss]

received packet on eth1 with own address as source address

These may be proper logs for "hair-pin" or "loop-back" requests. Asus routers have built-in "look-back" features (its a good thing). These may appear (my guess) when you access a LAN address with http/https URL.

Are you accessing any devices within your LAN with a web URL?

 

[rappel]

These appear to be Guest WiFi connections. Asus Routers will commonly assign psudo-VLANs for Guest WiFi connections.

Suggest you disable Guest WiFi operations to verify these LAN IPs disappear.

Well, I had one guest network (seems a sensible idea) and disabling that got rid of br1, but br2 remains. I assume, given the br0 : ...on eth1 text, that br0 is the wired LAN interface.

 

[rappel]

These may be proper logs for "hair-pin" or "loop-back" requests. Asus routers have built-in "look-back" features (its a good thing). These may appear (my guess) when you access a LAN address with http/https URL.

Are you accessing any devices within your LAN with a web URL?

I do, but manually when I'm looking at web interfaces on speakers, recorder boxes etc. but not at the rate that this seems to be clocking up messages.

Is that what you meant?

not heard of look back before, what's the purpose? but again surely if this is causing the logging to overflow from time to time that's not quite right?

 

[PunchCardBoss]

not heard of look back before, what's the purpose? but again surely if this is causing the logging to overflow from time to time that's not quite right?

"hair-pin" or "Loop-back" is when a device in your LAN attempts to connect to another device in your LAN. But instead of using an LAN IP, the device uses a http/https link that reconciles back to your ISP IP address.

A good example is accessing a local NAS. I can access my NAS with a local IP address when I am connected to my LAN. But, I can also connect remotely using a http://XXXX.diskstation.me. This sub-domain resolves to my ISP IP address.

Now, if I am connected to my LAN, and I use http://XXXX.diskstation.me to access my NAS (from within my LAN), the Asus router will say: "what is this? I don't want to go out to the internet just to come back in. So, I will just make a "U-Turn" and not go out to the internet."

Sooo, (still my guess), your log file may be capturing every time there is a communication packet that does a "hair-pin" or "Loop-back" call.

I seem to remember seeing lots of these types of logs when I was doing some trace routing with WINsharkPACKETcapture.

 

[ColinTaylor]

@rappel br0 is the router's LAN interface. br1 and br2 are additional interfaces created for the first guest network on the 2.4GHz and 5GHz bands respectively. This is all normal.

The eth1 interface is one of your router's LAN ports. It may be labelled as #1 or #4. What do you have plugged into this port? The "received packet" messages are quite normal but usually infrequent, that's why they're hidden in the GUI. They are usually caused by a Wi-Fi client roaming from one access point to another. But in your case eth1 is not an access point so it's a bit strange.

 

[rappel]

Re loopback - understood. I would have to say don't think there is much there unless any of the "intelligent" devices are doing something that I'm not aware of. I usually configure most things to not dial home etc. but doesn't mean I haven't missed something.

re. ports, I have direct connection to the Gigaclear network unit on the Asus WAN port and port 4 is a direct connection into my primary Netgear switch

One other thing this morning, the main log screen is showing a repeating behaviour as the extract below. Not seen this behaviour before whenever I have looked at the log. I assume it's a wireless device connecting and disconnecting? Possibly on the edge of wireless reception? Full log also attached but nothing obvious on terms of corresponding pattern.

I'll do some more digging later today and see if I can identify the Mac address but that may take a while.

Beginning to think I'll try a factory reset, but I prefer to understand what I may have done wrong before I wipe it.


--------------------------
Mar 16 09:39:03 wlceventd: wlceventd_proc_event(530): eth6: Auth 9C:8C:6EA:C7:00, status: Successful (0), rssi:0
Mar 16 09:39:03 wlceventd: wlceventd_proc_event(559): eth6: Assoc 9C:8C:6EA:C7:00, status: Successful (0), rssi:-55
Mar 16 09:39:03 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:39:03 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:39:15 wlceventd: wlceventd_proc_event(530): eth6: Auth 9C:8C:6EA:C7:00, status: Successful (0), rssi:0
Mar 16 09:39:15 wlceventd: wlceventd_proc_event(559): eth6: Assoc 9C:8C:6EA:C7:00, status: Successful (0), rssi:-55
Mar 16 09:39:16 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:39:16 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:39:36 wlceventd: wlceventd_proc_event(530): eth6: Auth 9C:8C:6EA:C7:00, status: Successful (0), rssi:0
Mar 16 09:39:36 wlceventd: wlceventd_proc_event(559): eth6: Assoc 9C:8C:6EA:C7:00, status: Successful (0), rssi:-55
Mar 16 09:39:36 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:39:36 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:40:00 wlceventd: wlceventd_proc_event(530): eth6: Auth 9C:8C:6EA:C7:00, status: Successful (0), rssi:0
Mar 16 09:40:00 wlceventd: wlceventd_proc_event(559): eth6: Assoc 9C:8C:6EA:C7:00, status: Successful (0), rssi:-55
Mar 16 09:40:00 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:40:00 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:40:08 wlceventd: wlceventd_proc_event(530): eth6: Auth 9C:8C:6EA:C7:00, status: Successful (0), rssi:0
Mar 16 09:40:08 wlceventd: wlceventd_proc_event(559): eth6: Assoc 9C:8C:6EA:C7:00, status: Successful (0), rssi:-56
Mar 16 09:40:08 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:40:08 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:40:19 miniupnpd[2083]: remove port mapping 4141 TCP because it has expired
Mar 16 09:40:23 wlceventd: wlceventd_proc_event(530): eth6: Auth 9C:8C:6EA:C7:00, status: Successful (0), rssi:0
Mar 16 09:40:23 wlceventd: wlceventd_proc_event(559): eth6: Assoc 9C:8C:6EA:C7:00, status: Successful (0), rssi:-56
Mar 16 09:40:23 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Mar 16 09:40:23 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 9C:8C:6EA:C7:00, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

 

[ColinTaylor]

re. ports, I have direct connection to the Gigaclear network unit on the Asus WAN port and port 4 is a direct connection into my primary Netgear switch

Do you have any access points connected to your switch?

These sorts of messages can also be caused by a misconfigured network that has a network loop. Maybe you could post a diagram of your network setup.

 

[Jbennett360]

AX86S user here.

I've had issues over the last couple of months where randomly, it feels like a page takes a few seconds to think what it needs to do, before it kicks in and does it. (I've not had the streaming service buffer issues though)

I believe the issue I have/had is ISP related. (Few friends on the same ISP who have commented the same thing)

Plus, if you've had issues in the past with the ISP then chances are it is them at fault again. Can neighbours/friends verify it?

In terms of the logs, not sure, I'll leave that to the experts on here!