What's new

[RT-AC56] "Local" traffic on eth0

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

mreckhof

Occasional Visitor
I've noticed that I'm seeing local traffic (from an IP perspective) hitting my eth0 interface.
Update: The packets that don't make sense me to as to why they are showing on eth0 have a dot1q tag on them showing vlan ID 1.

I have to admit, I'm not totally up on the full architecture of this router, but I've been search and reading and from both a linux level and from what I can tell reading, eth0 is supposed to be the WAN interface.

If I do a tcpdump against the interface and ping 8.8.8.8, I see the traffic post-NAT, so I know it's definitely on the WAN side (going to replace the real WAN IP with 142.1.1.1 in the example test below):

mreckhof@RT-AC56R-CE50:/tmp/home/root# tcpdump -ni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
05:48:00.812415 IP 142.1.1.1 > 8.8.8.8: ICMP echo request, id 29466, seq 0, length 64
05:48:00.820375 IP 8.8.8.8 > 142.1.1.1: ICMP echo reply, id 29466, seq 0, length 64
05:48:01.812670 IP 142.1.1.1 > 8.8.8.8: ICMP echo request, id 29466, seq 1, length 64
05:48:01.821378 IP 8.8.8.8 > 142.1.1.1: ICMP echo reply, id 29466, seq 1, length 64​

However, if I unrestrict tcpdump and let it roll, I ALSO see:

mreckhof@RT-AC56R-CE50:/tmp/home/root# tcpdump -ni eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
05:50:34.200336 IP 192.168.2.142.2000 > 255.255.255.255.55555: UDP, length 110
05:50:34.201136 IP 192.168.2.105.58173 > 192.168.2.253.80: Flags , seq 1125200762, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 706542103 ecr 0,sackOK,eol], length 0
05:50:34.203379 IP 192.168.2.253.80 > 192.168.2.105.58173: Flags [S.], seq 327639061, ack 1125200763, win 5792, options [mss 1460,sackOK,TS val 84667212 ecr 706542103,nop,wscale 1], length 0
05:50:34.204682 IP 192.168.2.252.80 > 192.168.2.105.58172: Flags [P.], seq 1409331351:1409331368, ack 563730421, win 2896, options [nop,nop,TS val 31844916 ecr 706542050], length 17
05:50:34.205341 IP 192.168.2.252.80 > 192.168.2.105.52731: Flags [P.], seq 4046307056:4046308080, ack 2303112246, win 2896, options [nop,nop,TS val 31844917 ecr 706542084], length 1024
05:50:34.206662 IP 192.168.2.105.58173 > 192.168.2.253.80: Flags [.], ack 1, win 4117, options [nop,nop,TS val 706542107 ecr 84667212], length 0
05:50:34.206688 IP 192.168.2.105.58172 > 192.168.2.252.80: Flags [.], ack 17, win 4117, options [nop,nop,TS val 706542108 ecr 31844916], length 0
05:50:34.207716 IP 192.168.2.105.58173 > 192.168.2.253.80: Flags [P.], seq 1:281, ack 1, win 4117, options [nop,nop,TS val 706542108 ecr 84667212], length 280
05:50:34.208816 IP 192.168.2.253.80 > 192.168.2.105.58173: Flags [.], ack 281, win 2896, options [nop,nop,TS val 84667213 ecr 706542108], length 0
05:50:34.209476 IP 192.168.2.252.80 > 192.168.2.105.58172: Flags [P.], seq 17:34, ack 1, win 2896, options [nop,nop,TS val 31844918 ecr 706542108], length 17​


Under a normal router, this traffic really has no business being here. I'm seeing it in my SNMP stats as well (attached).

Interestingly, it seems to be transient. I know what the traffic is, and it's an IP camera for the baby monitor. Therefore, I know this also streams every night to an iPad (the other side of the connection). However, if you look at the bandwidth chart, you don't see this behavior of a constant 6Mbps traffic rate every night.

Is this an expected behavior or something unique to consumer routers related to the chipsets (I typically work with enterprise gear)?

Interestingly, if I look at Adaptive QoS or Traffic Analyzer, it doesn't show this traffic - it only shows the traffic that truly is heading out the Internet. It's only snmp, confirmed by tcpdump, that even registers it.

Code version is Merlin 378.55 and I have not yet rolled back to various versions to see if it goes away or has always been there. Since it seems transient, I don't want to change too much or reboot the thing until I have data pointing one way or the other.

Another interesting thing I've noticed is that my snmp poller started erring out on br0 as well. I don't recall if that was completely matching with this or not time wise. Is it possible that it's using eth0 to bridge the radios instead of br0?

Some other data:

mreckhof@RT-AC56R-CE50:/tmp/home/root# robocfg show
Switch: enabled
Port 0: DOWN enabled stp: none vlan: 1 jumbo: off mac: 68:f7:28:0d:fe:2b
Port 1: 100FD enabled stp: none vlan: 1 jumbo: off mac: 3c:b1:5b:4f:ca:91
Port 2: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 90:b9:31:8a:c8:73
Port 3: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 00:14:c1:43:a3:f9
Port 4: 100FD enabled stp: none vlan: 2 jumbo: off mac: 4c:5e:0c:e8:4f:4f
Port 8: DOWN enabled stp: none vlan: 2 jumbo: off mac: 00:00:00:00:00:00
VLANs: BCM5301x enabled mac_check mac_hash
1: vlan1: 0 1 2 3 5t
2: vlan2: 4 5
56: vlan56: 7t
57: vlan57: 0 4 5t
58: vlan58: 0 2 3t
59: vlan59: 0t 1 7
60: vlan60: 4 7 8t
61: vlan61: 0 1 2t 3 5 8u
62: vlan62: 0t 2t 3t 4t 7t

mreckhof@RT-AC56R-CE50:/tmp/home/root# ifconfig
br0 Link encap:Ethernet HWaddr 40:16:7E:BD:CE:50
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: masked/64 Scope:Link
inet6 addr: masked/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11225323 errors:0 dropped:0 overruns:0 frame:0
TX packets:18314077 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1693311798 (1.5 GiB) TX bytes:24702532233 (23.0 GiB)

eth0 Link encap:Ethernet HWaddr F0:D1:A9:0A:AD:05
inet add:142.1.1.1 Bcast:142.1.1.127 Mask:255.255.255.224
inet6 addr: masked/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:132930446 errors:0 dropped:0 overruns:0 frame:0
TX packets:131009923 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1906600829 (1.7 GiB) TX bytes:563907678 (537.7 MiB)
Interrupt:179 Base address:0x4000

eth1 Link encap:Ethernet HWaddr 40:16:7E:BD:CE:50
inet6 addr: masked/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:36885495 errors:0 dropped:0 overruns:0 frame:4256224
TX packets:34543813 errors:488 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2063575053 (1.9 GiB) TX bytes:1324867776 (1.2 GiB)
Interrupt:163

eth2 Link encap:Ethernet HWaddr 40:16:7E:BD:CE:54
inet6 add: masked/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7008840 errors:0 dropped:0 overruns:0 frame:85923
TX packets:11953761 errors:255 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2303082709 (2.1 GiB) TX bytes:323294537 (308.3 MiB)
Interrupt:169

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:801127 errors:0 dropped:0 overruns:0 frame:0
TX packets:801127 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:157140910 (149.8 MiB) TX bytes:157140910 (149.8 MiB)

tun21 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

v6in4 Link encap:IPv6-in-IPv4
inet6 addr: masked/128 Scope:Link
inet6 addr: masked/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:25005 errors:0 dropped:0 overruns:0 frame:0
TX packets:22563 errors:1 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:0
RX bytes:27938702 (26.6 MiB) TX bytes:2674398 (2.5 MiB)

vlan1 Link encap:Ethernet HWaddr 40:16:7E:BD:CE:50
inet6 addr: masked/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:61356337 errors:0 dropped:0 overruns:0 frame:0
TX packets:87612612 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7725022157 (7.1 GiB) TX bytes:114503030958 (106.6 GiB)

vlan2 Link encap:Ethernet HWaddr 40:16:7E:BD:CE:50
inet6 addr: masked/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:402 (402.0 B)
 

Attachments

  • eth0 traffic.png
    eth0 traffic.png
    123.1 KB · Views: 360
Last edited:
Also, below is brctl. If this is right, then it kind of blows away my theory it's somehow bridging radios to eth0 instead of br0, right? That is if the commands and the kernel aren't lying to each other.

mreckhof@RT-AC56R-CE50:/tmp/home/root# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.40167ebdce50 yes vlan1
eth1
eth2
 
Also, this may be a nuance of this type of hardware, but this looks fishy to me. Compared to what's in robocfg show, I would expect only vlan2 to contain eth0 since vlan1 is supposed to contain the local radios/br0, right?

mreckhof@RT-AC56R-CE50:/proc/7210/net/vlan# cat /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD
vlan1 | 1 | eth0
vlan2 | 2 | eth0

mreckhof@RT-AC56R-CE50:/proc/7210/net/vlan# cat /proc/net/vlan/vlan1
vlan1 VID: 1 REORDER_HDR: 1 dev->priv_flags: 8001
total frames received 61784048
total bytes received 7755017614
Broadcast/Multicast Rcvd 538010
total frames transmitted 88115040
total bytes transmitted 115108521771
total headroom inc 1004737
total encap on xmit 88115040
Device: eth0
INGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
EGRESS priority mappings:

mreckhof@RT-AC56R-CE50:/proc/7210/net/vlan# cat /proc/net/vlan/vlan2
vlan2 VID: 2 REORDER_HDR: 1 dev->priv_flags: 1
total frames received 0
total bytes received 0
Broadcast/Multicast Rcvd 0

total frames transmitted 3
total bytes transmitted 402
total headroom inc 0
total encap on xmit 3
Device: eth0
INGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
EGRESS priority mappings:​
 
I've just come across this issue as well on an RT-N66U. I'm using RRD to monitor WAN traffic, but it's picking up all the local stuff too!

I'm curious about how the traffic monitor in the Web GUI works.
 
it's somehow bridging radios to eth0 instead of br0?
eth0 is the WAN interface
eth1 is the 2.4GHz primary Wi-Fi interface
eth2 is the 5GHz primary Wi-Fi interface
vlan1 is the 4x Ethernet ports interface
wl0.1 is the 2.4GHz guest #1 Wi-Fi interface
wl1.1 is the 5GHz guest #1 Wi-Fi interface
wl0.2 is the 2.4GHz guest #2 Wi-Fi interface
wl1.2 is the 5GHz guest #2 Wi-Fi interface
wl0.3 is the 2.4GHz guest #3 Wi-Fi interface
wl1.3 is the 5GHz guest #3 Wi-Fi interface
br0 is the LAN (all interfaces except eth0)
 
Right, but why is local traffic also showing up on eth0?
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top