Posted: Sat Feb 10, 2018 17:37 Post subject: DD-WRT Primer Series - Network Bridges and Bridging
Hello fellow dd-wrt contributors,
I posted this to accomplish two things;
1 - To understand the reason why I see different network bridging configurations with default DD-WRT software when on different router hardware.
2 -To learn more about network bridging, how dd-wrt uses them, bridging operational and management functionality GUI/CLI built into DD-WRT.
br0:0 and br0:1 is what led me to wanting to do this post. After upgrading my Asus 87u (wl0 is in client bride mode / wl1 disabled) I noticed that the Active Clients table in the LAN tab of the [STATUS] WebGUI would show a 169.address as an active connection very briefly every so often. So I went to find out more information and then doing an ifconfig on my device I saw this output;
I noticed that the output contained more interfaces than i was used to seeing. Specifically the additional bridges br0:0 and br0:1. The latter being the IP I was observing show up in the webGUI [STATUS]--[LAN]--[Active Clients]
Thinking that was an unusual bridging objects I logged onto my Asus 66u ( AP mode/ WAN disabled) and wrt1900 (AP mode internet gateway) and did an ifconfig to see if they had a similar list of bridges. They both only had a total of two bridges listed; br0 and br0:0
Checking the WebGUI for each of the three devices [SETUP]-->[NETWORKING]-->[BRIDGING] You see the same for each one;Only br0
Code:
Current Bridging Table:
Name STP enabled Interface
br0 no vlan1 vlan2 eth1
Doing a more specific command to list the bridging we see only the br0 bridge.
Code:
root@asus87u:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0862669075fa no vlan1
vlan2
eth1
Seeing the ip linkage did not help either
Code:
root@asus87u:~# ip link
1: lo: <LOOPBACK,MULTICAST,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: teql0: <NOARP> mtu 1500 qdisc noop state DOWN qlen 100
link/void
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 1000
link/ether 08:62:66: brd ff:ff:ff:ff:ff:ff
4: vlan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP qlen 1000
link/ether 08:62:66: brd ff:ff:ff:ff:ff:ff
5: vlan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP qlen 1000
link/ether 08:62:66: brd ff:ff:ff:ff:ff:ff
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc fq_codel master br0 state UNKNOWN qlen 1000
link/ether 08:62:66: brd ff:ff:ff:ff:ff:ff
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 08:62:66:90:75:fa brd ff:ff:ff:ff:ff:ff
root@asus87u:~#
I haven't gotten much further than that as I wanted to discuss this topic with the group. I can say that I did use an ifconif command on the Asus rt-87u to remove the br0:0 and br0:1 and I did not see a negative impact on my network and the 169 address stopped popping up in the active clients list, however the additional bridges reappeared after a reboot of the device.
Code:
ip link set br0:1 down
So I thought maybe some keen people here would be able to review this post and provide some clarity as to what I am observing and why there are differences and what each of the additional bridges actually do. Also why can I only 'see' them (the additional bridges) in the ifconfig?
The closest I have gotten is that these bridges are added in the factory settings of dd-wrt to provide compliance to a network standard called APIPA; They go on to say you can simply issue the ip link set [br0:X] down commands at startup to remove them. But that still doesn't explain it enough for me to be content.
I was also able to locate the 169 IP address in the route table
Code:
root@asus87u:~# route -e
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
default 192.168.2.1 0.0.0.0 UG 0 0 0 br0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
169.254.0.0 * 255.255.0.0 U 0 0 0 br0 <---
169.254.39.0 * 255.255.255.0 U 0 0 0 br0 <---
192.168.2.0 * 255.255.255.0 U 0 0 0 br0
root@asus87u:~#
I'm not sure what to make of those two entries.
I have reviewed these pages leading up to this posts however I would appericate some additional education in the matter. Specifically with br0:0 and br0:1. What is their purpose? Why do some routers have them and some don't all running the same build of dd-wrt? Unlike br0 why don't these additional bridges show up in the management tools such as the webGUI and the CLI tools like brctl and ip link? What is the impact of removing them? Under what conditions do I need\would use these bridges?
Thank you for the great reply. I always knew about the host using the fail back 169 address, I never knew routers did as well. It all makes sense to me.
One thing was why do some routers have several additional IPs assigned such as my 87u for example....
br0:0 Link encap:Ethernet HWaddr 08:62:66:
inet addr:169.254.255.1 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
br0:1 Link encap:Ethernet HWaddr 08:62:66:
inet addr:169.254.39.61 Bcast:169.254.39.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Thanks again for the great reply. _________________ Location (urban) - 1x Linksys EA8500 (AP wlan0 & wlan1 enabled)
1x Asus 68u (Repeater Bridge w/VAP) - wl0 disabled
1x Asus 87u (Client Bridge) - wl1 disabled
Thanks.
I can confirm that all my dd-wrt routers have the 169.254.255.1 additional IP. Nice tip by the way....I'll keep that one in mind for future DHCP issues.
Code:
br0:0 Link encap:Ethernet HWaddr 54:A0:50
inet addr:169.254.255.1 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
So why does my 87u have this second 169 IP? Is it something to do with the fact it's operating in client bridge mode?
Code:
br0:1 Link encap:Ethernet HWaddr 08:62:66:90:75:FA
inet addr:169.254.39.61 Bcast:169.254.39.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
_________________ Location (urban) - 1x Linksys EA8500 (AP wlan0 & wlan1 enabled)
1x Asus 68u (Repeater Bridge w/VAP) - wl0 disabled
1x Asus 87u (Client Bridge) - wl1 disabled
That 169.254.39.x is for the quantenna subsystem.
The actual ip is not fixed.
https://www.snbforums.com/threads/identifying-ac87-interfaces.21356/ _________________
Netgear R7800 kongpro 19.07 20190919 || Netgear R7000 36070M kongac (Client Bridge=5GHz, AP=2.4GHz with bridged VAP)
Linksys WRT32X davidc502 OpenWrt || Linksys WRT1200ACv1 Gargoyle 1.11.x
Linksys WRT1900ACSv2 dd-wrt 39956
Great. Thanks for the info. This leaves me back to the reason I took note this 169 IP addresses;
In my Active clients table under [STATUS]-->[LAN].
Every so often I see the 169.254.39.61 listed with 1 connection. I open the list of connections and search for the '169' string.
It comes back with one result. See image attached. The IP it's connected to is reported as 169.254.39.65 Presumably another quantenna system IP from my 87u.
My 87u shows br0:1 with 169.254.39.61
br0:1 Link encap:Ethernet HWaddr 08:62:66:90:75:FA
inet addr:169.254.39.61 Bcast:169.254.39.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Also I do a netstat looking for 169 and I get this result;
Code:
root@asus87u:~# netstat | grep 169
netstat: /proc/net/tcp6: No such file or directory
tcp 0 0 169.254.39.61:silc 169.254.39.65:666 ESTABLISHED
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
root@asus87u:~#
I'm able to ping both IPs (169.254.39.65) from the 87u router. But unlike the smallnetbuilder thread I'm unable to telnet into either of the IPs. So I suspect both the IPs are originating from the 87u quantenna sub-sys but I'm not sure the purpose of these IPs and what the connection being listed is doing.
Thanks again everyone for the free education.
dd-wrt-CaptureConn.JPG
Description:
Connection list
Filesize:
22.7 KB
Viewed:
3431 Time(s)
_________________ Location (urban) - 1x Linksys EA8500 (AP wlan0 & wlan1 enabled)
1x Asus 68u (Repeater Bridge w/VAP) - wl0 disabled
1x Asus 87u (Client Bridge) - wl1 disabled
I'm able to ping both IPs (169.254.39.65) from the 87u router. But unlike the smallnetbuilder thread I'm unable to telnet into either of the IPs.
Did you enable the telnet server inside the quantenna system like what RMerlin explained in that snb thread? _________________
Netgear R7800 kongpro 19.07 20190919 || Netgear R7000 36070M kongac (Client Bridge=5GHz, AP=2.4GHz with bridged VAP)
Linksys WRT32X davidc502 OpenWrt || Linksys WRT1200ACv1 Gargoyle 1.11.x
Linksys WRT1900ACSv2 dd-wrt 39956
Did you enable the telnet server inside the quantenna system like what RMerlin explained in that snb thread?
ATE Enable_Qtn_TelnetSrv you mean?
Yes I ran the command but the ATE utility they used to enabled telnet however is not found on dd-wrt so I do not believe it's enabled.
Quote:
"The RT-AC87U actually has two separate CPU, each one runs its own firmware. There's the Broadcom BCM4709 you are familiar with, which runs Asuswrt. That's the "main" firmware, which you can access over telnet (or SSH if using my firmware). There's a second CPU on this router, from Quantenna, which runs its own firmware, and is only accessible internally from within the Broadcom environment. That's the one that hosts the 5 GHz radio."
Elsewhere they explain the 87u in more detail....
Quote:
"The RT-AC87U is an unusual beast, as it sports radios from two different manufacturers, as well as two completely different CPUs, each of them running their own operating system.
The basic platform is your average Broadcom Northstar. We have a Broadcom BCM4709 CPU running @ 1 GHz, with 256 MB of DDR3 800 MHz RAM, and 128 MB of NAND flash memory. There's one BCM4360 (based on syslog - I didn't check the physical chip) radio for the 2.4 GHz band.
The switch from a BCM4708 to BCM4709 bumps the CPU clock to 1 GHz, in addition to supporting more advanced hardware acceleration. This chip adds Flow Accelerator support (FA for short) on top of the usual Cut-Through-Forwarding (or CTF). This is configurable on the webui as being "Level 1 CTF" or "Level 2 CTF" (the latter adding FA on top of it).
The novelty part is the Quantenna SoC. This chip contains both a CPU (an ARC 700 running at 500 MHz) and a 5 GHz radio. That CPU runs its own Linux kernel, which also handles the 5 GHz radio. That means the 5 GHz stuff is run by that CPU, freeing the main Broadcom CPU."
Explains why I have never been able to turn it off. Currently I have my wl1 / 5 GHz radio mode set to disabled. Strangely I have never been able to get wl1 to stop broadcasting in 5GHz even with it set to mode disabled. I've also learned if I set the Radio to Always Off under the Radio Scheduling within [WIRELESS]-->[WL1 ADVANCED] that has no effect either. So I simply set Wireless SSID Broadcast to Disabled, and settle for having the 5GHz hidden at least.
Quote:
"Internally, the Broadcom (BCM) environment (which is where DD-WRT runs) talks with the Quantenna (QTN) environment through an internal switch. The two of them talk through RPC calls. This means DD-WRT will connect over the internal network to the QTN firmware to configure things such as SSID or crypto, retrieving client info, etc..."
I'm just wondering why is the RPC client and server for the quaantenna system making active RPC connections when everything is set to disabled? What's the purpose of these RPC connections when there is no activity? Why it is doing anything with no connections to it? Also i would be curious to know if someone knows a way to disable the QTN system properly on DD-WRT when it's not in use.
-Stephen _________________ Location (urban) - 1x Linksys EA8500 (AP wlan0 & wlan1 enabled)
1x Asus 68u (Repeater Bridge w/VAP) - wl0 disabled
1x Asus 87u (Client Bridge) - wl1 disabled
