Tido Posted June 25, 2017 Author Posted June 25, 2017 I found a PDF document about the Distributed Switch Architecture, A.K.A. DSA written by: Andrew Lunn, Vivien Didelot, Florian Fainelli - Samstag, 1. April 2017 18.19:10
dumischbaenger Posted June 30, 2017 Posted June 30, 2017 Has anybody tried 5.31? It seems to be the last Armbian we will get - the board is marked as phased out. I made a quick test yesterday. Looks like the switch behavior changed again.
zador.blood.stained Posted June 30, 2017 Posted June 30, 2017 1 minute ago, dumischbaenger said: Has anybody tried 5.31? It seems to be the last Armbian we will get - the board is marked as phased out. Support for this board is marked as "phased out", but the build target was not removed and upgrading the kernel will be possible too (at your own risk). Please check this thread, it appears that there is at least some progress. I will move messages related to R1 to this thread later.
Tido Posted June 30, 2017 Author Posted June 30, 2017 @zador.blood.stained I have thought about that too, but there is no valuable information, beside knowing how to get a networking capable image. Beside, need some information about networking. I guess eth0 sits on the A20 whereas the Broadcom Chip does the VLAN part. The eth0 is a 'transparent' Port and the eth0.101 should receive the IP-Address. What is necessary, configuration wise, that eth0.101 can receive/accept a DHCP offer?
zador.blood.stained Posted June 30, 2017 Posted June 30, 2017 1 minute ago, Tido said: The eth0 is a 'transparent' Port and the eth0.101 should receive the IP-Address. What is necessary, configuration wise, that eth0.101 can receive/accept a DHCP offer? You need to point the DHCP client at this interface? Assuming b53 switch previously was configured correctly to pass and mark traffic from/to specified switch ports so it goes to eth0.101.
Tido Posted June 30, 2017 Author Posted June 30, 2017 14 minutes ago, zador.blood.stained said: You need to point the DHCP client at this interface? Well, without my configuration of VLAN, just interfaces eth0 receives an IP-Address. I can get an IP-Address to eth0, via /etc/network/interfaces. When I remove eth0 from interfaces I cannot receive the DHCP offer from my Netgear router on VLAN-Port eth0.101 (WAN-Port). Kind of missing pass-through. Here I attached a picture of the situation: The beast How do I tell the A20 to pass it through ? Another scenario, if the WAN-Port is physically attached to the B53-Switch, what is needed that B53 will accept an IP-Address?
zador.blood.stained Posted June 30, 2017 Posted June 30, 2017 2 minutes ago, Tido said: Another scenario, if the WAN-Port is physically attached to the B53-Switch, what is needed that B53 will accept an IP-Address? b53 can't accept the address because it's just a switch Again, you need to create a logical interface and bind it to a physical port on a switch. How it should be done - no idea, personally I don't have any DSA capable hardware that runs a DSA enabled kernel.
Tido Posted June 30, 2017 Author Posted June 30, 2017 2 hours ago, zador.blood.stained said: the DHCP client versus DHCP server. I guess, now I see your point. Thank you I will dig in that direction.
zador.blood.stained Posted July 19, 2017 Posted July 19, 2017 https://github.com/armbian/build/issues/511#issuecomment-316457447
Tido Posted August 1, 2017 Author Posted August 1, 2017 On 17.3.2017 at 3:37 PM, BrUser said: BCM53125_DEVICE_ID I have added: .arl_entries = 4 Address Resolution Logic (ARL) The BCM53125 entry was missing an arl_entries member which would basically prevent the ARL search from terminating properly. This switch has 4 ARL entries, so add that. -> Does this somehow effect us in getting it running as a Switch or Router?
Tido Posted August 7, 2017 Author Posted August 7, 2017 The DHCP-Server is working on LAN ports, IP-Address received from the router and with just one (1) bridge!! No error messages in: Quote service networking status service isc-dhcp-server status I have update the DSA-Document with my current configuration files. Unfortunately, rtl8192c comes back with errors, will not start: Spoiler Aug 7 09:21:36 localhost dhcpd: DHCPOFFER on 192.168.9.151 to da:42:ea:9c:92:fe (tinkerboard) via br0 Aug 7 09:24:34 localhost kernel: [ 774.982796] bcm53xx stmmac-0:1e lan1: Link is Down Aug 7 09:24:34 localhost kernel: [ 774.982956] br0: port 2(lan1) entered disabled state Aug 7 09:24:34 localhost rsyslogd-2007: action 'action 17' suspended, next retry is Mon Aug 7 09:25:34 2017 [try http://www.rsyslog.com/e/2007 ] Aug 7 09:25:01 localhost CRON[1461]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Aug 7 09:26:57 localhost systemd[1]: Starting Cleanup of Temporary Directories... Aug 7 09:26:57 localhost rsyslogd-2007: action 'action 17' suspended, next retry is Mon Aug 7 09:27:57 2017 [try http://www.rsyslog.com/e/2007 ] Aug 7 09:26:57 localhost systemd[1]: Started Cleanup of Temporary Directories. Aug 7 09:34:56 localhost kernel: [ 1397.204510] rtl8192cu: MAC auto ON okay! Aug 7 09:34:56 localhost rsyslogd-2007: action 'action 17' suspended, next retry is Mon Aug 7 09:35:56 2017 [try http://www.rsyslog.com/e/2007 ] Aug 7 09:34:56 localhost kernel: [ 1397.238545] rtl8192cu: Tx queue select: 0x05 Aug 7 09:34:57 localhost kernel: [ 1397.565526] rtl8192c_common: chksum report fail! REG_MCUFWDL:0x00030000 . Aug 7 09:34:57 localhost kernel: [ 1397.565537] rtl8192c_common: Firmware is not ready to run! Aug 7 09:34:57 localhost kernel: [ 1397.922711] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Aug 7 09:35:01 localhost CRON[1477]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) /var/log/armhwinfo.log has been uploaded to http://sprunge.us/cUHg
petrmaje Posted October 8, 2017 Posted October 8, 2017 On 6/30/2017 at 9:40 AM, zador.blood.stained said: Support for this board is marked as "phased out", but the build target was not removed and upgrading the kernel will be possible too (at your own risk). Please check this thread, it appears that there is at least some progress. I will move messages related to R1 to this thread later. Hi, the situation with Lamobo is very bad. I understand reasons, why you drop support for the board, but you should provide last working configuration for possible upgrades. All devices with next kernel will die after apt-get upgrade. This happened to me today. In archive is nothing working with kernel 4.x, which I need. So is it possible remove R1 from build target and in download section offer last 4.x kernel with switch support? And block kernel upgrade using apt? Thanks, Petr
MetallJ Posted January 30, 2018 Posted January 30, 2018 Ok, I have now had a detailed look at all this. But some questions occured: What is exactly the difference between default VLAN and native VLAN? Default is set by something on boot? Why do we add wan to our br0? I thought it would be completely seperated from our bridge (VLAN 102)? Why do we need to also add eth0.102 to br0? I know it is virtual adapter for VLAN 102. When I run bridge vlan show: I see that each Port occurs exactly twice (excepting the br0). Is that normal? There is this hint: # - eth0.102 = LAN (4 port switch) + WLAN But I don't see where WLAN is added to VLAN 102. Is it added? Sorry for that load of questions but I would really like to know what's going on there.
Tido Posted January 30, 2018 Author Posted January 30, 2018 8 hours ago, MetallJ said: What is exactly the difference between default VLAN and native VLAN? Default is set by something on boot? see page 10 8 hours ago, MetallJ said: Why do we add wan to our br0? The whole switch is a bridge, keep all interfaces in one Bridge (software wise), devide it into VLANs where needed. https://github.com/armbian/build/issues/511#issuecomment-319487261 IP routing (slides) page 4 - on Doc give you an idea about the connections. 8 hours ago, MetallJ said: Why do we need to also add eth0.102 to br0? I know it is virtual adapter for VLAN 102. answered above - keep all interfaces in one Bridge, devide it into VLANs where needed. 8 hours ago, MetallJ said: When I run bridge vlan show: I see that each Port occurs exactly twice (excepting the br0). Is that normal? My document is a tutorial and guide for newbies; take a fresh copy of armbian burnt with etcher.io 1.1.2 or brand new 1.3.1 and about 45 min. DO NOT skip any file just follow it, when you have backup - play with it ;-) In each section you find "Checks"; but they are only useful at the end, when the device is configured. Would be nice to hear back from you
MetallJ Posted January 30, 2018 Posted January 30, 2018 42 minutes ago, Tido said: see page 10 Page 10 only says: # There is a difference between Default VLAN and Native VLAN. # Native VLAN can be of a value of same as Default VLAN # which is 1. # But when a native VLAN is changed for e.g in this case its 10, # still the default VLAN remains 1. It does not say anything about the differences. Just that it is a different thing. But neither where default VLAN is set nor how (by which part?)? 42 minutes ago, Tido said: The whole switch is a bridge, keep all interfaces in one Bridge (software wise), devide it into VLANs where needed. https://github.com/armbian/build/issues/511#issuecomment-319487261 IP routing (slides) page 4 - on Doc give you an idea about the connections. answered above - keep all interfaces in one Bridge, devide it into VLANs where needed. OK, I guess it is a best practice to do VLAN instead of creating different bridges? But bridges would also work? I see the rule: Put everything in the bridge, but don't understand why. For example all devices from VLAN 102 are already in the bridge. So there should be no need to also add the interface eth0.102. Is there any reason to do this? Same for wan. Why would I like it to join br0? If I leave it on it's own. I have one more seperation instead of seperation only by VLAN. So what is the interest? 42 minutes ago, Tido said: My document is a tutorial and guide for newbies; take a fresh copy of armbian burnt with etcher.io 1.1.2 or brand new 1.3.1 and about 45 min. DO NOT skip any file just follow it, when you have backup - play with it ;-) In each section you find "Checks"; but they are only useful at the end, when the device is configured. Would be nice to hear back from you That is exactly what I have done. But I only did the DSA part and the interfaces-Configuration and then used my configuration of dnsmasq. Thank you so much for taking the time and answering my questions.
Angelo Calvão Posted February 26, 2019 Posted February 26, 2019 I can't make the b53 switch driver to work with newer kernels? Anybody had success? Works well for 4.14.84-sunxi, but does not work for the 4.19.x...
HKnaack Posted April 22, 2019 Posted April 22, 2019 On 2/27/2019 at 12:02 AM, Angelo Calvão said: I can't make the b53 switch driver to work with newer kernels? Anybody had success? Works well for 4.14.84-sunxi, but does not work for the 4.19.x... I ran into the same issue after updating the kernel. Florian Fainelli told me, that with newer kernels, we need to specify "vlan_filtering 1" during creation of the bridge. Otherwise all the switch ports may end up in dumb switch mode (no separation between WAN and LAN ports). The only problem, when still on Debian Jessie: the ip command doesn't accept this option. So, I ended up upgrading from Jessie to Stretch. Here are the steps starting from the bricked device via serial console: Jessie with too new kernel (4.19) remove bound IPs (LAN: 192.168.0.20, WAN: 192.168.1.3)from bridge root@lamobo:~# bridge vlan show port vlan ids wlan0 1 PVID Egress Untagged eth0.102 1 PVID Egress Untagged br0 1 PVID Egress Untagged root@lamobo:~# ip addr show 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group defa0 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever 12: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group0 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.0.20/24 brd 192.168.0.255 scope global br0 valid_lft forever preferred_lft forever inet 192.168.1.3/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever root@lamobo:~# ip addr del 192.168.0.20/24 dev br0 root@lamobo:~# ip addr del 192.168.1.3/24 dev br0 assign desired IP to eth0 (since switch is in unconfigured mode) root@lamobo:~# ip addr add 192.168.0.20/24 dev eth0 root@lamobo:~# ping 192.168.0.200 PING 192.168.0.200 (192.168.0.200) 56(84) bytes of data. 64 bytes from 192.168.0.200: icmp_seq=1 ttl=64 time=0.701 ms root@lamobo:~# route add default gw 192.168.0.200 root@lamobo:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=25.7 ms Follow the Debian Distribution Upgrade Guide change in /etc/apt/preferences.d/90-backports.pref instances of "jessie" to "stretch" change in /etc/apt/sources.list.d/armbian.list and /etc/apt/sources.list instances of "jessie" to "stretch" root@lamobo:/home/mbs# apt-get update root@lamobo:/home/mbs# apt-get dist-upgrade put new DSA compatible /etc/network/interfaces in place (change "pre-up ip link add br53125 type bridge" to "pre-up ip link add br53125 type bridge vlan_filtering 1" ) reboot When using a fresh downloaded image, a properly configured /etc/network/interfaces file also containing "vlan_filtering 1" works as well, but I had some issues to get hostapd running. First off, the wifi interface name changed from wlan0 to wl<mac-address>. Besides, I had some problems with blocked radio. It seems, uninstalling network-manager helps (I don't see a reason to have network-manager on a router). Otherwise, the rfkill tool helps in resolving this issue. 2
Recommended Posts