Jump to content

BPi-R1 with new B53 switch driver (DSA)


Recommended Posts

Posted

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

Posted

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.

Posted
  On 6/30/2017 at 7:36 AM, dumischbaenger said:

Has anybody tried 5.31? It seems to be the last Armbian we will get - the board is marked as phased out.

Expand  

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.

Posted

@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?

 

Posted
  On 6/30/2017 at 8:38 AM, 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?

Expand  

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.

Posted
  On 6/30/2017 at 8:41 AM, zador.blood.stained said:

You need to point the DHCP client at this interface?

Expand  

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?

Posted
  On 6/30/2017 at 8:58 AM, 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?

Expand  

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.

Posted
  On 3/17/2017 at 2:37 PM, BrUser said:

BCM53125_DEVICE_ID I have added: .arl_entries = 4

Expand  

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?

 

Posted

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

Expand  

I have update the DSA-Document with my current configuration files.

 

 

Unfortunately, rtl8192c comes back with errors, will not start:

  Reveal hidden contents

 

/var/log/armhwinfo.log has been uploaded to http://sprunge.us/cUHg
 

Posted
  On 6/30/2017 at 7: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.

Expand  

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

Posted

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.

 

Posted
  On 1/30/2018 at 11:42 AM, MetallJ said:

What is exactly the difference between default VLAN and native VLAN? Default is set by something on boot?

Expand  

see page 10

 

  On 1/30/2018 at 11:42 AM, MetallJ said:

Why do we add wan to our br0?

Expand  

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.

  On 1/30/2018 at 11:42 AM, MetallJ said:

Why do we need to also add eth0.102 to br0? I know it is virtual adapter for VLAN 102.

Expand  

answered above - keep all interfaces in one Bridge, devide it into VLANs where needed.

 

  On 1/30/2018 at 11:42 AM, MetallJ said:

When I run bridge vlan show: I see that each Port occurs exactly twice (excepting the br0). Is that normal?

Expand  

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

Posted
  On 1/30/2018 at 8:09 PM, Tido said:

see page 10

Expand  

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?)? 

 

  On 1/30/2018 at 8:09 PM, 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.

Expand  

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?

  On 1/30/2018 at 8:09 PM, 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

Expand  

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.

 

  • Igor unpinned this topic
Posted
  On 2/26/2019 at 11:02 PM, 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...

Expand  

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.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines