Build: [RfE] Drop support for Lamobo R1

[ThomasKaiser]

This device suffers from a few fundamental problems, the most severe claiming to be useable as a router which is not the case.

For R1 users to be able to fool themselves it's necessary that an external piece of software called swconfig works to configure the dumb Broadcom switch which caused problems with 5.20 update and maybe now also with 5.23 (wouldn't call this a bug report since zero information has been provided to be able to even understand what might be happening).

Maybe switching to kernel 4.8 with sunxi-next branch as part of the 5.22 update to fix Dirty COW caused again an incompatibility with this swconfig tool, maybe it's something else. R1 users do not care about security that much so they don't need security updates that urgently or at all.

So let's drop further support for this device and stop providing updates. Unhappy users can switch to Bananian for example since less upgrades are considered a feature and not a problem for sure.

[golfromeo-fr]

@ThomasKaiser
TK, I agree with you.

Slowing support & stopping later, yes sure. I am waiting for the Turris Omnia (+NAS box) to arrive & to replace the R1 (I will be keeping R1 as a "smart" lan switch).

Idea:
legacy version: ?
next version: forcing a step back to kernel 4.4.x and letting the R1 dies slowly.
dev version: mainline with a disclaimer for swconfig

[zador-blood-stained]

This device can still be used as anything other than a router, and b53 switch driver is now a part of mainline kernel. So we don't have to drop updates for the device completely, instead building beta images once a month should be enough, and if users are interested in this device, they will have to test the beta image, and if it is reported as working, stable update should be made based on tested version.

[zador-blood-stained]

next version: forcing a step back to kernel 4.4.x and letting the R1 dies slowly.

This will turn our build script into a mess since sunxi-next kernel branch and sunxi-next set of patches are used for many other devices, and we can't split this without breaking backwards compatibility.

[ThomasKaiser]

I am waiting for the Turris Omnia

@golfromeo-fr I think it's not about you or your plans with R1 or any successor. It's about

• properly documenting what's up with this device below https://github.com/igorpecovnik/lib.docs/tree/master/docs/board_details (which is pretty easy since it's just explaining the _dumb switch_ issue one more time in big red letters, a link to linux-sunxi wiki and describing Armbian support status)
• Armbian users taking care of software support for this specific device. _If_ we manage to get a better release/testing policy and _if_ people support this device (I totally agree with Mikhail here) then there's no need to drop support

But if there are no people willing to test prior to releases or unforeseen events like Dirty COW now then it's simply a matter of focusing on devices worth the effort and removing Lamobo R1 from list of automated builds.

[golfromeo-fr]

@ThomasKaiser @zador-blood-stained
I understand and agree. Thanks. I've added some tasks for XU4 (incl. Zador remarks). I will try to help here also.

[igorpecovnik]

I would not change the current schema because of last events.

[ThomasKaiser]

IMO we need at least one person 'feeling' responsible for devices like R1 that are

• known to be mis-used (since people ignore that this is not a routerboard but a dumb switchboard instead)
• known to be fragile since the way people want to mis-use the device implies using a driver and a piece of software to set up the dumb switch

So someone caring about this device could've take notice that there's a change with 4.8 and start early to develop a fix that can be included in Armbian long before the kernel update (in our case now needed due to Dirty COW) will be rolled out.

I believe we've a lot of users capable of doing this amongst us (see https://github.com/igorpecovnik/lib/issues/514 for example) but IMO it's necessary to improve testing/release cycles and get them on board.

[hknaack]

I would not like to see support for this device dropped. Basically, it is just an A20 board with a b53 and some crappy rtl8192cu on the USB (which any other board could have, as well). Although I feel pretty busy on my other projects, if this is the price I have to pay to keep this device supported, then I volunteer to do some testing (hopefully just every now and then).

[igorpecovnik]

I was referring to not dropping the board.

IMO we need at least one person 'feeling' responsible for devices like R1 that are

Yes, that's the idea. Before we start next testing period, we have to deal with roles. I would propose to start with a simple check list. We can expand it later, on the way, when we got the system working. For now, only basic parameters. If we need something extra, we could add it to armbianmonitor. When we build images, they must (only) boot and be able to connect to network. The rest is usually fixable with update.

[ThomasKaiser]

I was referring to not dropping the board.

I know but this can only work with a changed release/test policy since otherwise we don't get support by users testing stuff prior to release.

As for automated tests I already thought about that in the past and maybe it can work like this:

• adding a test routine to firstrun (called with a trailing &)
• the test routine logs everything to /var/log/armbian-initial-tests.log
• most basic test is ping -c10 $(ip route show default | awk '/default/ {print $3}')
• Next test is ping -c1 armbian-test.local >/dev/null 2>&1 and based on result then a bunch of other tests could be fired up

Idea behind: When we want to do automated testing after image creation then all that's needed is another host in the network that registers itself through avahid as armbian-test.local and has iperf3 -s running. Also the pure existence of a armbian-test.local can be used to fire up a few more non-network tests on the board (like eg. running sysbench).

In case firstrun detects full test mode based on existence of this other host we could then use show_motd_warning functionality to inform user about test results. So in the end our testers have to download a new image, start it unattended, log in 10 minutes later and see whether everything's ok or not.

The list of tests can easily be extended/updated/adjusted as needed and even with boards like Orange Pi Lite or NanoPi Air we can do a fully automated test based on the assumption that we (or experienced testers) simply use another SBC (called armbian-test.local ;) ) with active AP providing a Wi-Fi network called ARMBIAN-$some-garbage-here where $some-garbage-here contains the passphrase in an obfuscated form. So this is just 2 lines using nmcli to establish an unattended Wi-Fi test setup.

And no, no idea about A33-OlinuXino (but I fear I have to admit that I've not the slightest idea what to do with it anyway -- zero connectivity to the outside isn't comptabile with my use cases)

[hknaack]

I did another attempt to upgrade to 5.23 (this time from 5.20), made sure to have swconfig installed, too. But that didn't work out. After realizing, that no b53 driver was loaded, I modprobe'd b53_common and the corresponding mdio driver. That was the result in dmesg:

[ 411.023547] libphy: mdio_driver_register: bcm53xx
[ 411.024377] b53_common: found switch: BCM53125, rev 4
[ 411.024607] DSA: switch 0 0 parsed
[ 411.024620] DSA: tree 0 parsed
[ 411.169920] libphy: dsa slave smi: probed
[ 411.266978] Generic PHY dsa-0.0:00: attached PHY driver Generic PHY
[ 411.366953] Generic PHY dsa-0.0:01: attached PHY driver Generic PHY
[ 411.466962] Generic PHY dsa-0.0:02: attached PHY driver Generic PHY
[ 411.567005] Generic PHY dsa-0.0:03: attached PHY driver Generic PHY
[ 411.667091] Generic PHY dsa-0.0:04: attached PHY driver Generic PHY
[ 411.675727] bcm53xx stmmac-0:1e: Configured port 8 for rgmii
[ 413.310845] Link is Up - 1000/Full

As a result, all switch ports got separated. swconfig list however did not find any switch. Digging further into the topic and DSA, it appears that swconfig won't be necessary any more (so no need to have such dependency on lamobo kernel images), and configuration should be done with ip and brctl.
As the dmesg output shows, PHY devices are created for each external ethernet port, with aliases lan1 to lan4 and wan for convenience. Furthermore, I was able to set links up or down using ifconfig wan up and ifconfig wan down (same for other ports). There was also a dependency between those ports and eth0.101/eth0.102 in the sense, that the corresponding eth0.10x had to be up, before those ports could be configured. This is the dmesg log when trial-and-erroring:

[ 2687.703430] IPv6: ADDRCONF(NETDEV_UP): wan: link is not ready
[ 2689.328289] bcm53xx stmmac-0:1e wan: Link is Down
[ 2691.408503] bcm53xx stmmac-0:1e wan: Link is Up - 100Mbps/Full - flow control off
[ 2691.408567] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[ 2693.488812] bcm53xx stmmac-0:1e wan: Link is Down
[ 2695.568792] bcm53xx stmmac-0:1e wan: Link is Up - 100Mbps/Full - flow control off
[ 2697.649028] bcm53xx stmmac-0:1e wan: Link is Down
[ 2698.689012] bcm53xx stmmac-0:1e wan: Link is Up - 100Mbps/Full - flow control off
[ 2700.769130] bcm53xx stmmac-0:1e wan: Link is Down
[ 2702.849329] bcm53xx stmmac-0:1e wan: Link is Up - 100Mbps/Full - flow control off
[ 2849.529885] IPv6: ADDRCONF(NETDEV_UP): lan1: link is not ready
[ 2850.619736] bcm53xx stmmac-0:1e lan1: Link is Down
[ 2851.659851] bcm53xx stmmac-0:1e lan1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 2851.659915] IPv6: ADDRCONF(NETDEV_CHANGE): lan1: link becomes ready
[ 2892.222626] bcm53xx stmmac-0:1e lan1: Link is Down
[ 2905.854285] IPv6: ADDRCONF(NETDEV_UP): lan2: link is not ready
[ 2907.423733] bcm53xx stmmac-0:1e lan2: Link is Down
[ 2908.463875] bcm53xx stmmac-0:1e lan2: Link is Up - 100Mbps/Full - flow control off
[ 2908.463940] IPv6: ADDRCONF(NETDEV_CHANGE): lan2: link becomes ready
[ 2921.984511] bcm53xx stmmac-0:1e lan2: Link is Down
[ 2926.780949] IPv6: ADDRCONF(NETDEV_UP): lan3: link is not ready
[ 2928.385226] bcm53xx stmmac-0:1e lan3: Link is Down
[ 2931.505480] bcm53xx stmmac-0:1e lan3: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2931.505547] IPv6: ADDRCONF(NETDEV_CHANGE): lan3: link becomes ready
[ 2936.705536] bcm53xx stmmac-0:1e lan3: Link is Down
[ 2941.078079] IPv6: ADDRCONF(NETDEV_UP): lan4: link is not ready
[ 2943.026239] bcm53xx stmmac-0:1e lan4: Link is Down
[ 2944.066393] bcm53xx stmmac-0:1e lan4: Link is Up - 100Mbps/Full - flow control off
[ 2944.066460] IPv6: ADDRCONF(NETDEV_CHANGE): lan4: link becomes ready
[ 2989.829301] bcm53xx stmmac-0:1e lan4: Link is Down
[ 3012.533573] br0: port 2(wlan0) entered disabled state
[ 3012.533741] br0: port 1(eth0.102) entered disabled state
[ 3035.469970] IPv6: ADDRCONF(NETDEV_UP): lan1: link is not ready
[ 3036.792867] bcm53xx stmmac-0:1e lan1: Link is Down
[ 3038.873087] bcm53xx stmmac-0:1e lan1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 3038.873154] IPv6: ADDRCONF(NETDEV_CHANGE): lan1: link becomes ready
[ 3199.044075] bcm53xx stmmac-0:1e lan1: Link is Down
[ 3210.702451] IPv6: ADDRCONF(NETDEV_UP): lan2: link is not ready
[ 3212.165292] bcm53xx stmmac-0:1e lan2: Link is Down
[ 3214.245499] bcm53xx stmmac-0:1e lan2: Link is Up - 100Mbps/Full - flow control off
[ 3214.245563] IPv6: ADDRCONF(NETDEV_CHANGE): lan2: link becomes ready
[ 3264.168700] bcm53xx stmmac-0:1e lan2: Link is Down
[ 3268.699627] IPv6: ADDRCONF(NETDEV_UP): lan3: link is not ready
[ 3272.649638] bcm53xx stmmac-0:1e lan3: Link is Up - 1Gbps/Full - flow control rx/tx
[ 3272.649705] IPv6: ADDRCONF(NETDEV_CHANGE): lan3: link becomes ready
[ 3304.891576] bcm53xx stmmac-0:1e lan3: Link is Down
[ 3309.532806] IPv6: ADDRCONF(NETDEV_UP): lan4: link is not ready
[ 3311.212363] bcm53xx stmmac-0:1e lan4: Link is Up - 100Mbps/Full - flow control off
[ 3311.212428] IPv6: ADDRCONF(NETDEV_CHANGE): lan4: link becomes ready

However, I assigned the wan and lan aliases a valid IP, but every ping to my devices on the corresponding port failed.
After that, I went back to 5.20 and try to gather further information. One good explanation of the DSA concept can be found at http://trac.gateworks.com/wiki/linux/vlan#LinuxDistributedSwitchArchitecture. Other than that, I will look into the documentation of ip and brctl to see what useful features they hide under the hood.
Until we have all the issues figured out, would there be a problem in keep building the old openwrt driver for the b53 with swconfig? That would make testing less painful, since it would just involve loading and unloading kernel modules to test some configurations.

[ThomasKaiser]

Unless there is a testing branch and appropriate mechanisms established and volunteers are known who care for this weird switchboard (it isn't and never will be a routerboard) I still think the best thing is to drop support (implement checks in package upgrading scripts and skip the device so it remains at 4.7 until someone cares about the switchboard again).

[golfromeo-fr]

probably swconfig is no longer needed anymore, maybe "bridge" instead
http://lwn.net/Articles/634787/
Just an idea, we have experts here

[kotc]

i've tried to tackle this issue too, but without much success. theoretically it should 'just work', practically it doesnt. script i've used:

ip link set eth0 up
brctl addbr lan
for i in lan1 lan2 lan3 lan4; do
ip addr flush $i
ip link set $i up
brctl addif lan $i
done
ip addr add 192.168.1.1/24 brd 192.168.1.255 dev lan
ip link set lan up

and while apparently switch ports regained forwarding capability, i cant connect to/from the lamobo. something makes the packets get dropped when they are originated from the device (they show on eth0, but not on any of the lanX interfaces or lan bridge). let's see if the driver author/maintainer responds.

[kotc]

more funnies, leave switch unconfigured, assign local lan ip to eth0, set /proc/sys/net/ipv4/conf/eth0/{forwarding,proxy_arp} to 1, and voila! switch acts like a dumb hub where everything sees everything (even with downed lanX ports o.o). while this might not be the wanted case, if one only needs this device for local lan functionality with mainline, its nice, in a dumb way of nice

[ThomasKaiser]

switch acts like a dumb hub where everything sees everything

This is the only mode this device should be operated since U20 (EEPROM to save switch state so the dumb switch could be brought up in a way where not each and every port is interconnected at layer 2) isn't populated on this crappy device.

Still: best idea would be to drop support entirely since currently we help users actively fooling themselves since people don't want to understand that this is not a routerboard but just a dumb switchboard.

BTW: When using the switchboard as such is GbE performance still crappy or normal A20 level (exceeding 300 Mbits/sec)?

[kotc]

@ThomasKaiser otoh, would be interesting if adding this eeprom could make it remember the setting

[kotc]

as for the speed, serving file from /tmp:
/dev/null 100%[====================================>] 230.00M 52.9MB/s in 4.5s
2016-11-02 17:40:37 (51.1 MB/s) - '/dev/null' saved 241172480/241172480

[zador-blood-stained]

Still: best idea would be to drop support entirely since currently we help users actively fooling themselves since people don't want to understand that this is not a routerboard but just a dumb switchboard.

Still, the best idea IMO is to write on the download page that network features are supported only on legacy kernel due to changes to mainline. At least until we can provide at least basic network connectivity out of the box with 4.8+ kernels. Or temporary add the old swconfig-compatible driver to the next branch and leave dev branch for DSA tests.

[kotc]

previous result was with bpi-m1 as a receiver, this one is using thinkpad t500:
/dev/null 100%[==================================>] 230.00M 62.4MB/s in 3.8s
2016-11-02 17:43:54 (59.9 MB/s) - '/dev/null' saved [241172480/241172480]

[kotc]

and this one is when serving the file from bpi-m1 to thinkpad t500:
/dev/null 100%[==================================>] 240.00M 25.5MB/s in 9.6s
2016-11-02 17:49:49 (25.1 MB/s) - '/dev/null' saved [251658240/251658240]

[ThomasKaiser]

Still, the best idea IMO is to write on the download page that network features are supported only on legacy kernel due to changes to mainline.

Sure, it's simply adjusting https://github.com/igorpecovnik/lib.docs/blob/master/docs/boards/lamobo-r1.md so please feel free to add this in big red letters.

Still people will run into upgrade troubles and in case no one with a R1 around and feeling responsible for the device will join development/testing efforts the next time a kernel upgrade happens, this will repeat.

@kotc: Thanks for the numbers (though I would've preferred real measurements using iperf3 instead), I rebooted the one R1 I unfortunately bought last year at a customer yesterday (still running 3.4.108, uptime 199 days) and might switch to 4.8 immediately (since only switch mode is needed and with 4.8 currently performance doesn't seem to suck that much as with this b53 stuff with both legacy/vanilla kernels before)

[kotc]

@ThomasKaiser but remember, this config is somehwat hacky/invalid, also, why not 4.9? also, it's proxy_arp_pvlan, not proxy_arp

[zador-blood-stained]

@kotc
New DSA based driver was merged in 4.8, before that we had the old one from OpenWRT (swconfig-compatible)

[kotc]

@zador-blood-stained just wanted to know why sticking to 4.8 when 4.9 is almost baked.
@ThomasKaiser if you provide me the command lines i can do them (both hosts running armbian so should be no problem)

[zador-blood-stained]

@kotc
-rc3 means it's only around half-way through, usually there will be 6-8 release candidates. And since Armbian's "next" branch points at stable releases, linux-sunxi-next in the repository will be 4.8.x for a while.

[igorpecovnik]

Or temporary add the old swconfig-compatible driver to the next branch and leave dev branch for DSA tests.

Let's do this if it's not too complicated? Addin patch back in? Anything else? Even we write things on download page ... people usually ask first than read, when things fails.

[ThomasKaiser]

Even we write things on download page

Why should people look at the download page if they do an apt upgrade? Seriously: the only way to prevent such upgrade hassles is to either drop support for the board or change release/testing policies and search for at least one person able/willing to test through new releases prior to pushing them out.

[igorpecovnik]

OK, if / when we choose to stop dealing with a board we should at least leave it in a working state. That means our last update should remove sources list or similar?

[ThomasKaiser]

Even if I started this here (playing my provocative role as usual) I would prefer to be able to announce stuff like that since this might be the event getting users/testers/volunteers on board. But still this won't work if we don't improve regarding #512

If I understood correctly @hknaack is both willing and able to test through stuff (me unfortunately not, the R1 is serving in productive use) so if it's possible to use the old drivers with 4.8 then this might be the best short term solution as @zador-blood-stained suggested.

[kotc]

bpi-r1 as server, -m1 as client, both set to fixed 912MHz.
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.01 sec 792 MBytes 664 Mbits/sec 0 sender
[ 4] 0.00-10.01 sec 792 MBytes 664 Mbits/sec receiver
reverse:
[ 4] 0.00-10.00 sec 321 MBytes 269 Mbits/sec 6194 sender
[ 4] 0.00-10.00 sec 321 MBytes 269 Mbits/sec receiver

[zador-blood-stained]

Let's do this if it's not too complicated? Addin patch back in?

Done: 077a3dd. At least compilation still works.

[zador-blood-stained]

OK, if / when we choose to stop dealing with a board we should at least leave it in a working state. That means our last update should remove sources list or similar?

We can also put up a one time MOTD warning (in board support package) like we do with slow SD cards and docs.armbian.com link at first boot. Won't work for very old releases where board support packages don't update properly, but for newer ones it's a simple enough option.

[igorpecovnik]

@hknaack @kotc
(possibly fixed) Lamobo R1 image NEXT will be among daily test builds - avaliable in few hours from now, build 161102.

@zador-blood-stained
Tnx for updating patch. Perhaps we can define a date when support ends in a board config?

@ThomasKaiser
I'll move on that discussion asap.

[zador-blood-stained]

Perhaps we can define a date when support ends in a board config?

I don't think this is needed yet,

If you want you can modify download pages for boards that are not tested properly to include clearly visible "Limited support" notice and "Testers wanted" link to forum thread or section related to beta images or test requests/reports.

[kotc]

@zador-blood-stained have you checked if it works? i'm either missing some patches, dts definitions or 4.9 is incompatible with that patch. it's getting compiled but swconfig can't find the switch

[zador-blood-stained]

@kotc

Don't have this board to test, sorry. Looks like I missed DT patch, will try to add it ASAP.

[kotc]

@zador-blood-stained if you drop me kernel+dts+dtb+modules tgz i can check if it boots/works here

[zador-blood-stained]

@kotc

https://www.dropbox.com/sh/md7cfrdow6xmlxq/AACG8LAowlQNhoA817v8kC5wa?dl=0

You should be able to extract necessary files from the packages or just test them on top of an Armbian image for R1 with mainline kernel.

[kotc]

noope. swconfig doesnt work, might it be something changed regarding swconfig interface?

[kotc]

hmm. either my switch went bananas from all those experiments or something is fishy. i've just tried kernel/dtb/modules from armbian 5.17 (kernel 4.6.2-sunxi) and legacy kernel 3.4.112-sun7i. same output. i hope i didnt kill it ;)

[zador-blood-stained]

What swconfig did you use? Please try this one: http://apt.armbian.com/pool/utils/s/swconfig/swconfig_15.04-2~armbian5.23%2B1_armhf.deb

[kotc]

ahm. i'm stupid. i was missing ifconfig eth0 up ;) it showed on 4.6.8 armbian kernel. not on yours though. anyway, bed time, gotta check it tomorrow in the morning

[zador-blood-stained]

I rebuilt the kernel to switch b53 from module to built-in since old driver doesn't have DT compatible property for auto probing.

[hknaack]

I contacted Florian Fainelli, the submitter of the new b53 driver, on how to configure a router (bridged lan1-4 with wlan, separate wan), this is his response:

Sure, so there are a few caveats since we implement DSA without a tagging protocol, but basically, what you would want to do is this:

# Create a bridge which is mandatory for Bridge VLAN filtering to work
brctl addbr br-lan
brctl addif br-lan lan0
brctl addif br-lan lan1
brctl addif br-lan lan2
brctl addif br-lan lan3
brctl addif br-lan wan

Once there, you can configure different VLANs on the LAN interfaces, the default VLAN ID is 1, unless configured otherwise:

for lan in $(seq 0 3)
do
bridge vlan add vid 2 dev lan$lan
bridge vlan del vid 1 dev lan$lan pvid untagged
done

vconfig add eth0.2

and you should have now eth0 receive packets from "wan" by default, and eth0.2 receive all the LAN traffic

There are currently two limitations with DSA and B53 that I plan on addressing:

• the bridge master device: br-lan is actually our view of the switch's CPU port, but it cannot be configured in a way that the CPU would receive only tagged traffic (thus requiring eth0.1 and eth0.2)
• since we do not support Broadcom tags on b53, we cannot segregate traffic from "wan" and "lan0-3" other than by putting them in separate VLANs, but once Broadcom tags are in place "wan" alone can be used, and ports would be properly separated

[kotc]

@hknaack nice. but this sequence of commands doesnt do the trick. it might be missing something trivial (as setting some interface up with ip etc). but at least he is willing to communicate, thanks!

[kotc]

@hknaack also, thank you very much for that dts patch! now my banana works with mainline (4.9.0-rc3) and as a pseudo router! good riddance to that murky 3.4 kernel, thanks again :)

[kotc]

uh, of course in the last comment thanks go to @zador-blood-stained :)

[zador-blood-stained]

@kotc
Thanks for testing 😄

[hknaack]

@igorpecovnik I tested this build <1> (extracted the filesystem image and put it on a separate partition on my SD card, then issued the appropriate boot commands in uboot console) and it was missing swconfig in the first place, so the switch didn't work out of the box. After copying swconfig and my /etc/network/interfaces from my main partition, basic networking worked (apt-get, ping). Anything else you like to get checked?

<1>http://image.armbian.com/betaimages/Armbian_5.24.161104_Lamobo-r1_Ubuntu_xenial_4.8.6.7z

[igorpecovnik]

Great, now we need to check why swconfig is not installing and close this issue. Dropping support will be solved on some generic way with at least a note "updating on your own risk" or some automated removal that apt upgrade in future won't break on those boards ... which we will not monitor any more.

[kotc]

well, you can do only 'warning device support has ended' and simply dont upgrade the kernel part anymore, without removing upgrade capabilities?

[igorpecovnik]

Yes, kernel and dtb package should be put on hold on board without support and a warning. Upgrade for other packages should work normally.

[hknaack]

Why is dropping support still a thing? Going through this thread, the reasons mentioned by @ThomasKaiser were:

claiming {the device} to be useable as a router which is not the case.

Good point, and worth mentioning it. And I agree, that in certain cases, it should not be connected to the open internet. Other than that, the responsibility for safe use should be at the owner. And I don't see the point in repeating this over and over again.

problems with 5.20 update and maybe now also with 5.23 (wouldn't call this a bug report since zero information has been provided to be able to even understand what might be happening)

The problem and also information about the reason and some hint for a solution have been provided, meanwhile in this thread.

Armbian users taking care of software support for this specific device. If we manage to get a better release/testing policy and if people support this device (I totally agree with Mikhail here) then there's no need to drop support

@kotc and myself have already been testing some images. I also have something in my developing pipeline to have both drivers coexist, but need to test it, as well as some more testing of the configuration provided by Florian. Well, it will take some time, but I am confident that we will be successful.

@zador-blood-stained mentioned:

if users are interested in this device, they will have to test the beta image, and if it is reported as working, stable update should be made based on tested version

As mentioned, I am interested and do my part. So, I don't see a reason to drop support.

For the tests, I agree with @igorpecovnik that we need some checklist (or a script). However, if it contains network tests (which I think it should), it should not be run on automatically at firstrun. A proper network configuration has to be done in the first place.

[typingArtist]

claiming {the device} to be useable as a router which is not the case.

Good point, and worth mentioning it. And I agree, that in certain cases, it should not be connected to the open internet. Other than that, the responsibility for safe use should be at the owner. And I don't see the point in repeating this over and over again.

Just for the curious. There is a pin strapping option for the BCM53125 via LED[9] which Lamobo exported to us as a resistor soldering option.

If you like to disable frame forwarding by the switch in the unconfigured/booted state, you can solder a 2k2 ohm resister on unpopulated R1308 soldering pads on the board (bottom side, between unpopulated R110 and R132, next to populated C195).

Ref: BCM53125U datasheet (53125U-DS02-R.pdf, e.g. from here, Table 25 p.117, LED[9] description) and BPI-R1 MP Schematic-SD_V3-20140922.pdf from here p. 11). You can solder the resistor in series with a dip switch or alike so you can enable/disable this feature without repetitive soldering.

According to the docs, this pin strapping option affects the Port Control Register (Page 00h: Addresses 00h-05h STP_STATE[2:0]) and Switch Mode Register (Page 00h: Address 0Bh, SW_FWDG_EN and SW_FWDG_MODE) which might need additional care by the driver.

Note that I have not tried that myself and I haven’t looked at the driver sources whether it can handle the unconfigured switch properly. Any modification to the board is done at your own risk.

For my part, I am fine with the current behavior.

[typingArtist]

Please, don’t drop support for the BPI-R1, and please leave a build available with the standard 4.8 drivers so we testers can try and find a solution. Yes, I need the router in production and can only do testing occasionally, but I’d definitely like a working switchdev setup better than the old swconfig stuff.

[golfromeo-fr]

@typingArtist
kernel 4.8 doesn't seem to have long term support.
https://www.geeksbureau.com/2016/08/14/linux-kernel-4-9-lts/
kernel 4.4 has got it, used by OpenWrt/TurrisOS.
Maybe the easy way is to stall Armbian for R1 with kernel 4.4
(btw, Turris Omnia NAS is just magic, it can handle my fiber 950/250 Mbits/s internet connexion)
edit: I bought my L-R1 about 80 Euros in 2015, the Turris Omnia NAS public price would be around 400 Euros (non-NAS version is currently 330 Euros)
edit2: Lamobo-R1 is great for ADSL internet & cheap NAS.

[igorpecovnik]

If we will got some help and R1 will gets his own tester, we might prolong support. If problems are detected early enough. Ideally it would be that someone outside from our core group takes this board over and provides a fix if/when needed. I don't expect much changes / work.

Turris Omnia / Clearfog kernel and u-boot still have some rough edges. For production use, you have to use kernel 3.10, since both modern options lacks some vital functions. SFP port is available only in Marvell dev branch with kernel 4.4, which have troubles with mPCI stack ...

[typingArtist]

@golfromeo-fr, I don’t care whether it is 4.8 or 4.9 LTS. The main point was: Please ensure it’s easy to put a kernel on it that is in-line with the current Armbian philosophy, and contains the mainline b53 drivers for testing/implementing the bridge setup using the new switchdev functions instead of using the old swconfig tool.

[zador-blood-stained]

Just a thought: swconfig-compatible b53 driver (based on OpenWRT one) for current stable mainline release is maintained by us as a patch. New kernel versions may break this patch so it may require a rework. New kernel versions may also contain vulnerability fixes which should be covered ASAP in an unplanned kernel release.

So choose your option: releasing a new kernel without this patch (potentially breaking networking on R1 devices with mainline kernel) or delaying a release for 15 other boards only to get R1 covered.

Edit: yes, security related fixes are usually backported to older kernel releases too, but again, switching to newer kernel version may be delayed only because of one "unusual" board.

The main point was: Please ensure it’s easy to put a kernel on it that is in-line with the current Armbian philosophy, and contains the mainline b53 drivers for testing/implementing the bridge setup using the new switchdev functions instead of using the old swconfig tool.

Kernel from dev branch can be compiled manually and it will have new DSA based driver (may need tweaking kernel config)

[hknaack]

Having the swconfig b53 driver from Openwrt should just be a temporary step, until we have figured how to exactly use the new DSA based driver.
Mostly following the sequence provided by Florian, plus doing an ip link set lanX up for every LAN port got me to the point, that I had a switch configuration for the LAN ports running (meaning, I could acccess devices connected to the LAN ports).
Unfortunately, when trying the same again, just recently, I did not succeed. What's also not working: although eth0.2 was set up with the normal LAN IP for the R1 and link was up, I could not ping any other connected LAN device. I also tried the same on interface eth0, eth0.1, wan with the normal WAN IP, but could not ping my gateway. Any ideas welcome.

[kotc]

@zador-blood-stained could that patched driver work as an out-of-tree module?
@hknaack that could mean switch was preconfigured by your earlier experiments and reset to non-forwarding state at some point. it's a pity, because mainline/dsa way looks almost sane (though it's still incomplete and buggy apparently for bcm53125)

[zador-blood-stained]

@kotc
I don't see why not, the only problem for us is that DKMS is broken in Armbian. Let's hope that new DSA driver is fixed/extended soon, then we won't have to worry about mainline kernel on R1 at all.

[hknaack]

@igorpecovnik I tested another beta images <1>, still the tool swconfig is not included, but copying it over gets ethernet working. However, wifi was causing major troubles. Starting with the fact, that the interface name gets changed from wlan0 to something weird. See the attached log (time index 17.159624).
dmesg.txt

<1>http://image.armbian.com/betaimages/Armbian_5.24.161108_Lamobo-r1_Ubuntu_xenial_4.8.6.7z

[kotc]

that's either udev or systemd doing. i have quite old image here (4.70) and wlan0 is wlan0 as it should. (i have systemd removed and replaced with sysvinit, also, upgrading only kernel and packages manually).

[igorpecovnik]

I just build one Ubuntu Xenial image and it's working out of the box. swconfig is insalled and yes, wlan naming is strange. I don't recall whether this naming scheme is a bug or a feature, unrelated to our work.

I guess I need to rebuild rootfs cache on test images.

[zador-blood-stained]

It's a feature called "persistent device names", more specifically - Predictable Network Interface Names and it's slowly making it into different distributions, i.e. it's implemented in Ubuntu Xenial and Debian Stretch (testing). It's done with udev rules.

https://wiki.archlinux.org/index.php/Network_configuration#Network_interfaces

[hknaack]

Some more tests on the DSA side, please see this log for reference. Basically, it only proves how to setup the LAN ports of the bridge so it acts as a bridge for the connected devices (see time index 710.92, after which my pings from LAN3 to LAN1 and LAN2 are successful). So basically, this boils down to having those ports configured with the same VLAN id and enable PVID and Untagged.
Short info about the setup: 4 devices connected in LAN (LAN1: 192.168.0.79, LAN2: 192.168.0.199, LAN3: 192.168.0.80 => my PC, LAN4: 192.168.0.1), I ping from my PC to all 3 other devices. The R1 should have 192.168.0.200 on LAN bridge.
Since brctl and vconfig are deprecated, I substituted them with ip from iproute2.
Whats noticable is, that pings from the R1 skip icmp_seq numbers in some cases, when the CPU interface is NOT set to PVID and Untagged (see line 180f).
So, remaining problem still is: how to get traffic from the CPU interface to the LAN ports? Any input welcome.

[kotc]

@hknaack that was my problem too, i cant get traffic from the cpu go get back on the bridge. imo its a bug in b53 dsa code, and should be reported to the driver author, because it should work by simply adding ip to the bridge, but it isnt. (we might be simply missing some config command too)

[ffainelli]

@hknaack there is actually a fundamental problem in the b53 driver/DSA at the moment, which is that you can actually have two VLANs map to different ports, but the expectation is to have two groups of ports untagged flowing to the CPU as tagged, and right now, there is no way you can express that configuration request. I will come up with a fix in the next few days, sorry about that.

[faddat]

I prefer not dropping support for nostalgia reasons. Its one of my first three boards.

[oleg-krv]

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e47112d9d6009bf6b7438cedc0270316d6b0370d

[hknaack]

Yes, we have been busy and @ffainelli solved that issue. Unfortunately, it did not make it into 4.8.10.
In the R1 dts file, we also need to change the phy-mode of the b53125's cpu-port to rgmii-txid, this eliminated a major network package drop on my device.
And we need to implement new /etc/network/interface.r1* files, which deal with bridge and ip instead of swconfig.
Here are basically the steps to get it into "router" mode:
brctl addbr br0
brctl addif br0 lan1
brctl addif br0 lan2
brctl addif br0 lan3
brctl addif br0 lan4
brctl addif br0 wan
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
bridge vlan add vid 2 dev wan pvid untagged
bridge vlan del vid 1 dev wan
ip link set wan up
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
ip link set lan4 up
And then just assign eth0.1 the LAN IP address and eth0.2 the WAN address (or DHCP).

[typingArtist]

Instead of, or in addition to, /etc/network/interface.r1*, could we also supply some modern examples for /etc/systemd/network/ in the distribution?

[zador-blood-stained]

@typingArtist
Well, systemd-networkd can be great for configuring network until you (by "you" I mean average user) want to deal with wireless connections, so it's better th have ifplugd (or whatever it is called) and NetworkManager configs by default, but if systemd-networkd provides good integration with DSA we could have a HOWTO in the documentation.

[faddat]

Tell me what I need to do to help test for it?

[faddat]

Yeah, I wonder how to address that systemd-networkd deficiency in wireless networks. Say what you will, systemd has won me over.

[zador-blood-stained]

@faddat
For wireless network you need to use wpa_supplicant@ service and configuration file for it. So it's easy enough for a geek if you want a static wireless connection, but for end users that want to use GUI tools and don't want to edit configuration files manually it's not an option.

[faddat]

I tinker in go pretty often. I'm currently wondering if it is possible to
re-do wifi-menu in a systemd-networkd context. Thanks for your pointer in
the right direction, Mikhail.

Jacob Gadikian
E-mail: [email protected]
SKYPE: faddat
Phone/SMS: [phone]

On Thu, Nov 24, 2016 at 8:39 PM, Mikhail [e-mail] wrote:

@faddat https://github.com/faddat
For wireless network you need to use wpa_supplicant@ service and
configuration file for it. So it's easy enough for a geek if you want a
static wireless connection, but for end users that want to use GUI tools
and don't want to edit configuration files manually it's not an option.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/igorpecovnik/lib/issues/511#issuecomment-262778330,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGz6ia8sRYnLMM1urPeKR-uF0Aa_cmjGks5rBZOCgaJpZM4KftkS
.

[oleg-krv]

Hi.
Compiled linux dev sunxi 5.24 (debian jessie)
log.txt

# uname -a
Linux lamobo-r1 4.9.0-sunxi #1 SMP Thu Dec 1 18:33:49 EET 2016 armv7l GNU/Linux

The router is connected via a terminal, I have the opportunity to experiment. :)

[giovannirc]

@oleg-krv can you provide the compiled image? I can make extensive testing here

[oleg-krv]

I did not complete the image - only kernel update. Installable image 5.20 + updates and build a bridge. Not very well bridge. It gets the address of the DNS, but pings are losses. I'm not very versed in network bridges. Now I try recommendations from this thread. I connect with the board on tty0 (COM port) SSH - does not work in such packet loss

[hknaack]

@oleg-krv Have a look at this patch to address packet loss issues.
Feel free to use more patches from my branch. I had ethernet working so far, but failed on the wifi side (no interface with rtl8xxxu and hostapd didn't work with rtl8192cu). But haven't had the time to get this issue solved, lately.

[giovannirc]

how do I compile the kernel with the patch? also i have question about this board that have been bugging me for more than a year, I power it via battery connector since USB cant handle SATA properly. And whenever I have a power outage i need to click in the power button of the board. Is it possible to always power on when there is power?

Also another question, I would love to use Arch Linux on this board, did anyone tried it already?

[oleg-krv]

Build image Lamobo dev with https://github.com/igorpecovnik/lib/pull/255#issuecomment-205045273 - image is fail:

#LANG=us_UK.UTF-8 fdisk -lu Armbian_5.24_Lamobo-r1_Debian_jessie_4.9.0.img
Disk Armbian_5.24_Lamobo-r1_Debian_jessie_4.9.0.img: 1.2 GiB, 1334837248 bytes, 2607104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x135bc6e3

Device                                          Boot Start     End Sectors  Size Id Type
Armbian_5.24_Lamobo-r1_Debian_jessie_4.9.0.img1       2048 2607103 2605056  1.2G 83 Linux

# LANG=us_UK.UTF-8 mount -t ext3 -o loop,offset=$((2048*512)) Armbian_5.24_Lamobo-r1_Debian_jessie_4.9.0.img /mnt/tmp
mount: wrong fs type, bad option, bad superblock on /dev/loop5,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

I will update packages :)

[oleg-krv]

with the use of a patch from @hknaack - the network is working! thanks

[oleg-krv]

This compiled deb-files (with patch from @hknaack)
Armbian_5.24_Lamobo-r1_Debian_jessie_4.9.0_dev_debs.zip

[hknaack]

Greg Kroah-Hartman informed me, that he has the b53-patch queued up for the 4.8 branch, so I guess it will be in 4.8.14.

[legorado]

The todays beta apt sources work with swconfig tool, but not with brctl as mentioned above from @hknaack

root@lamobo-r1:~# brctl addif br0 lan1
interface lan1 does not exist!

Linux lamobo-r1 4.8.14-sunxi #2 SMP Mon Dec 12 09:17:59 CET 2016 armv7l GNU/Linux
bridge-utils 1.5-9
swconfig 15.04-2~armbian5.24.161212+1

[zador-blood-stained]

Next branch (4.8.x) still uses swconfig patches, once mainline 4.9.1 is released next branch will be switched to 4.9.x with DSA/brctl b53 driver.

[hknaack]

I've got a few commits sitting in my fork to switch back to the mainline B53/DSA driver, now that the necessary fixes got into 4.8.14. Do you want a pull request? I just haven't had the time to test it, and outstanding issue is still a proper /etc/network/interface.r1* config. Some days ago, I tested it with just ip and bridge, and I also think we should get rid of using brctl, as it is deprecated and from what I read, DSA drivers are supposed to be interacted with ip and bridge. So, this is what we would have to squash into interface.r1router:
ip link add br0 type bridge
ip link set lan1 master br0
ip link set lan2 master br0
ip link set lan3 master br0
ip link set lan4 master br0
ip link set wan master br0
ip link set wlan0 master br0
ip link add link eth0 name eth0.1 type vlan id 1
ip link add link eth0 name eth0.2 type vlan id 2
bridge vlan add vid 2 dev wan pvid untagged
bridge vlan del vid 1 dev wan
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
ip link set lan4 up
ip link set wan up
ip addr add 192.168.0.1/24 dev eth0.1
ip addr add 192.168.1.1/24 dev eth0.2
ip link set eth0.1 up
ip link set eth0.2 up
ip route add default via 192.168.1.2 dev eth0.2

And for interface.r1switch:
ip link add br0 type bridge
ip link set lan1 master br0
ip link set lan2 master br0
ip link set lan3 master br0
ip link set lan4 master br0
ip link set wan master br0
ip link set wlan0 master br0
ip link add link eth0 name eth0.1 type vlan id 1
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
ip link set lan4 up
ip link set wan up
ip addr add 192.168.0.1/24 dev eth0.1
ip link set eth0.1 up
Where 192.168.0.1 is the LAN interface, 192.168.1.1 the WAN interface and 192.168.1.2 the gateway.

I won't get the time to work on these issues during the next couple of weeks, but hope this helps you guys a bit.

[wiesl]

@hknaack Can you please provide your pull requests
Did you get it to work?
What I don't understand: How is the VLAN mapping configured for the external switch ports?
So what is identically to:
swconfig dev ${INTERFACE} set reset 1
swconfig dev ${INTERFACE} set enable_vlan 1
swconfig dev ${INTERFACE} vlan 101 set ports '3 8t'
swconfig dev ${INTERFACE} vlan 102 set ports '4 0 1 2 8t'
swconfig dev ${INTERFACE} set apply 1

Thnx.

[wiesl]

I'm getting:
libphy: mdio_driver_register: bcm53xx

But I miss the further detection:
b53_common: found switch: BCM53125, rev 4
DSA: switch 0 0 parsed
DSA: tree 0 parsed
libphy: dsa slave smi: probed
Generic PHY dsa-0.0:00: attached PHY driver Generic PHY
Generic PHY dsa-0.0:01: attached PHY driver Generic PHY
Generic PHY dsa-0.0:02: attached PHY driver Generic PHY
Generic PHY dsa-0.0:03: attached PHY driver Generic PHY
Generic PHY dsa-0.0:04: attached PHY driver Generic PHY
bcm53xx stmmac-0:1e: Configured port 8 for rgmii
Link is Up - 1000/Full

Any ideas?
(I'm using a self compiled kernel 4.8.15)

[wiesl]

I think the reverse patch should do it:
https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sunxi-next/revert-lamobo-r1-dts-for-old-b53-driver.patch

[wiesl]

Boot environment wasn't set correctly:
sunxi# env print fdtfile
fdtfile=sun7i-a20-bananapi.dtb

env set fdtfile sun7i-a20-lamobo-r1.dtb
env save

sunxi# env print fdtfile
fdtfile=sun7i-a20-lamobo-r1.dtb

reset

[wiesl]

Ok, main problem is the default VLAN 1, I got the following with default DTB to work. the section "Delete VLANs 1 on interfaces: lan0 lan1 lan2 lan3 lan4 wan wlan0 eth0.1 eth0.2 eth0.101 eth0.102 br0 br1" is important that it works.
If VLAN1 section isn't called, I'm getting packet loss as well as strange problems in the network (e.g. another router isn't reachable).
Any ideas with the VLAN 1/switch topic?

[wiesl]

# ================================================================================================================================================================
# Cleanup existing setup
# ================================================================================================================================================================

# Delete link list: lan0 lan1 lan2 lan3 lan4 wan wlan0 eth0.1 eth0.2 eth0.101 eth0.102 br0 br1
ip link del lan0
ip link del lan0 type bridge
ip link del lan1
ip link del lan1 type bridge
ip link del lan2
ip link del lan2 type bridge
ip link del lan3
ip link del lan3 type bridge
ip link del lan4
ip link del lan4 type bridge
ip link del wan
ip link del wan type bridge
ip link del wlan0
ip link del wlan0 type bridge
ip link del eth0.1
ip link del eth0.1 type bridge
ip link del eth0.2
ip link del eth0.2 type bridge
ip link del eth0.101
ip link del eth0.101 type bridge
ip link del eth0.102
ip link del eth0.102 type bridge
ip link del br0
ip link del br0 type bridge
ip link del br1
ip link del br1 type bridge

# Delete VLAN 1 on: lan0 lan1 lan2 lan3 lan4 wan wlan0 eth0.1 eth0.2 eth0.101 eth0.102 br0 br1
bridge vlan del vid 1 dev lan0
bridge vlan del vid 1 dev lan1
bridge vlan del vid 1 dev lan2
bridge vlan del vid 1 dev lan3
bridge vlan del vid 1 dev lan4
bridge vlan del vid 1 dev wan
bridge vlan del vid 1 dev wlan0
bridge vlan del vid 1 dev eth0.1
bridge vlan del vid 1 dev eth0.2
bridge vlan del vid 1 dev eth0.101
bridge vlan del vid 1 dev eth0.102
bridge vlan del vid 1 dev br0
bridge vlan del vid 1 dev br1

# Delete VLAN 101 on: lan0 lan1 lan2 lan3 lan4 wan wlan0 eth0.1 eth0.2 eth0.101 eth0.102 br0 br1
bridge vlan del vid 101 dev lan0
bridge vlan del vid 101 dev lan1
bridge vlan del vid 101 dev lan2
bridge vlan del vid 101 dev lan3
bridge vlan del vid 101 dev lan4
bridge vlan del vid 101 dev wan
bridge vlan del vid 101 dev wlan0
bridge vlan del vid 101 dev eth0.1
bridge vlan del vid 101 dev eth0.2
bridge vlan del vid 101 dev eth0.101
bridge vlan del vid 101 dev eth0.102
bridge vlan del vid 101 dev br0
bridge vlan del vid 101 dev br1

# Delete VLAN 102 on: lan0 lan1 lan2 lan3 lan4 wan wlan0 eth0.1 eth0.2 eth0.101 eth0.102 br0 br1
bridge vlan del vid 102 dev lan0
bridge vlan del vid 102 dev lan1
bridge vlan del vid 102 dev lan2
bridge vlan del vid 102 dev lan3
bridge vlan del vid 102 dev lan4
bridge vlan del vid 102 dev wan
bridge vlan del vid 102 dev wlan0
bridge vlan del vid 102 dev eth0.1
bridge vlan del vid 102 dev eth0.2
bridge vlan del vid 102 dev eth0.101
bridge vlan del vid 102 dev eth0.102
bridge vlan del vid 102 dev br0
bridge vlan del vid 102 dev br1

# ================================================================================================================================================================
# Setup switch, interfaces, VLANs and IP
# ================================================================================================================================================================

# Create VLAN 101 on interface eth0: eth0.101
ip link add link eth0 name eth0.101 type vlan id 101
ip link set eth0.101 up

# Create VLAN 102 on interface eth0: eth0.102
ip link add link eth0 name eth0.102 type vlan id 102
ip link set eth0.102 up

# Create bridge br0 with STP(0) on VLAN 101 with interfaces/tagged: lan1 untag lan2 untag lan3 untag lan4 untag wlan0 untag eth0.101 tag
ip link add br0 type bridge
ip link set dev br0 type bridge stp_state 0
ip link set lan1 master br0
bridge vlan add vid 101 dev lan1 pvid untagged
bridge vlan add vid 101 dev lan1 pvid untagged self
ip link set lan1 up
ip link set lan2 master br0
bridge vlan add vid 101 dev lan2 pvid untagged
bridge vlan add vid 101 dev lan2 pvid untagged self
ip link set lan2 up
ip link set lan3 master br0
bridge vlan add vid 101 dev lan3 pvid untagged
bridge vlan add vid 101 dev lan3 pvid untagged self
ip link set lan3 up
ip link set lan4 master br0
bridge vlan add vid 101 dev lan4 pvid untagged
bridge vlan add vid 101 dev lan4 pvid untagged self
ip link set lan4 up
ip link set wlan0 master br0
bridge vlan add vid 101 dev wlan0 pvid untagged
bridge vlan add vid 101 dev wlan0 pvid untagged self
ip link set wlan0 up
ip link set eth0.101 master br0
bridge vlan add vid 101 dev eth0.101 pvid untagged
bridge vlan add vid 101 dev eth0.101 pvid untagged self
ip link set eth0.101 up
ip link set br0 up

# Create bridge br1 with STP(0) on VLAN 102 with interfaces/tagged: wan untag eth0.102 tag
ip link add br1 type bridge
ip link set dev br1 type bridge stp_state 0
ip link set wan master br1
bridge vlan add vid 102 dev wan pvid untagged
bridge vlan add vid 102 dev wan pvid untagged self
ip link set wan up
ip link set eth0.102 master br1
bridge vlan add vid 102 dev eth0.102 pvid untagged
bridge vlan add vid 102 dev eth0.102 pvid untagged self
ip link set eth0.102 up
ip link set br1 up

# Delete VLANs 1 on interfaces: lan0 lan1 lan2 lan3 lan4 wan wlan0 eth0.1 eth0.2 eth0.101 eth0.102 br0 br1
bridge vlan del dev lan0 vid 1 self
bridge vlan del dev lan0 vid 1 master
bridge vlan del dev lan1 vid 1 self
bridge vlan del dev lan1 vid 1 master
bridge vlan del dev lan2 vid 1 self
bridge vlan del dev lan2 vid 1 master
bridge vlan del dev lan3 vid 1 self
bridge vlan del dev lan3 vid 1 master
bridge vlan del dev lan4 vid 1 self
bridge vlan del dev lan4 vid 1 master
bridge vlan del dev wan vid 1 self
bridge vlan del dev wan vid 1 master
bridge vlan del dev wlan0 vid 1 self
bridge vlan del dev wlan0 vid 1 master
bridge vlan del dev eth0.1 vid 1 self
bridge vlan del dev eth0.1 vid 1 master
bridge vlan del dev eth0.2 vid 1 self
bridge vlan del dev eth0.2 vid 1 master
bridge vlan del dev eth0.101 vid 1 self
bridge vlan del dev eth0.101 vid 1 master
bridge vlan del dev eth0.102 vid 1 self
bridge vlan del dev eth0.102 vid 1 master
bridge vlan del dev br0 vid 1 self
bridge vlan del dev br0 vid 1 master
bridge vlan del dev br1 vid 1 self
bridge vlan del dev br1 vid 1 master

# Setup IP addresses and routing
ip addr flush dev br0
ip addr add 192.168.32.2/24 dev br0
ip addr flush dev br1
ip addr add 192.168.1.1/24 dev br1
ip route add default via 192.168.32.1 dev br0

[ruyrybeyro]

I discovered this thread today, because I had some run in bug with the kernel (suspect timing, leap second?), and I had not rebooted for months due to being traumatic rebooting after upgrades.

I have to set aside a card anyway for testing, wont mind testing new releases on it too.

As for previous comments, I am not using systemd and do not plan to do it anytime soon. Actually as an anedocte, initially I tried to use netbsd on this board, unfortunately the specific model of the switch was not supported. Unfortunately time proved me right.

As for the current install/updates have they regressed?

As for the rules from @wiesl , are they for the stock or a compiled kernel? I somewhat got lost in the thread.

[badrianiulian]

Hy
I've been on the beta repository for a while now
With the migration to the 4.9.1 kernel (as of 07.01.2017), the B53 patch was removed
I tried it though and used some of the commands above but after ip link set lan1 master br0 I only get interface lan1 does not exist!
Am I missing something? I'd love to help testing

[rpodgorny]

removed? what do you mean? https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/dsa/b53?id=refs/tags/v4.9.1

[zador-blood-stained]

removed? what do you mean?

swconfig-compatible patch from OpenWRT was removed in favor of in-kernel DSA based driver.

Am I missing something? I'd love to help testing

Output from armbianmonitor -u would be a good start. You will need to connect to Internet first, i.e. via vireless or USB-Ethernet adapter

[badrianiulian]

Well ... connecting to the internet it's a bit tricky... i have a pppoe connection, no wireless possibilities (the old router went bye bye for a good cause) and no USB-ethernet adapter... All have is the board and a backup of the last packages that worked (4.8.15 kernel with B53 driver patched) allong with my PC. Will try to get the output from the armbianmonitor -u though and post it back here (I'll just go back and forth with the packages)

[badrianiulian]

So I went back and forth and here are my log and my new swconfig in if-pre-up.d
http://sprunge.us/RLMH
and
http://sprunge.us/GYDK

[zador-blood-stained]

@badrianiulian
Hm, feels like you are using the wrong DT and a rather old board support package. Please test the latest nightly image from here: https://img.armbian.com/lamobo-r1/nightly/
I'm mostly interested in the kernel log (dmesg), modules list (lsmod) and interfaces list (ifconfig, whether lan* interfaces are created or not)

[badrianiulian]

So: I installed the Armbian_5.24.170110_Lamobo-r1_Ubuntu_xenial_4.9.1.7z image
Even after adding in /etc/modules the b53_common driver, result is the same Cannot find device"lan1"
dmesg.log : http://sprunge.us/JVKH
ifconfig(-a).log : http://sprunge.us/eQFC
lsmod.log : http://sprunge.us/dRRH
By the looks of it the interfaces defined in the dtb aren't created.
Also swconfig list is blank (obviously)

[zador-blood-stained]

This is strange, because b53_mdio module should be loaded first. Please try to load it manually and check if there are any messages in dmesg after that.

[badrianiulian]

I had a little time this morning to test that and here it is: the lan/wan ports are visible in ifconfig
dmesg.log: http://sprunge.us/idTG
ifconfig(-a).log: http://sprunge.us/ALPb
lsmod.log: http://sprunge.us/PKMK
So this might be just a dependancy issue?

[zador-blood-stained]

The module should be probed by the compatible string... I changed it to built-in: e9337fe so it should work without loading anything explicitly.

Meanwhile we will need a minimal working config for /etc/network/interfaces so the device has proper network connectivity at first boot, at least for the router config with DHCP client on the WAN port and static LAN on the LAN* ports.

[badrianiulian]

Finnaly had a chance to test things: the module is loaded in the 4.9.2 nightly without glitches
Also I found a router at a coworker (he did not need it anymore) and used it for testing
Using wiesl's code kinda gets me to some conectivity... I got to ping the received router from the wan port (wan port of the lamobo-r1 beeing connected to the lan port of the received router).
The only problem is that the script kinda gets a lot of errors and when trying to use it in /etc/network/if-pre-up.d breaks the network service (fail because bla bla bla..)
For now I'm gonna go to sleep before I get some brain damadge for trying to understand that script (and also for beeing exhausted)

[badrianiulian]

Back again with some more testing. Using this files, somehow I got to where I needed:
/etc/network/if-pre-up.d/router http://sprunge.us/KBdH
/etc/network/interfaces http://sprunge.us/ATAH (for router with dhcp server installed and using br1 as a dhcp client)
... something mixed up the IP settings on my PC (with this config router<->lamobo-r1<->PC) so I went to the next step and removed the router just to add my pppoe configuration through br1:
/etc/network/interfaces http://sprunge.us/GEca
armhwinfo.log http://sprunge.us/UHRC
dmesg.log http://sprunge.us/HVNi
ifconfig.log http://sprunge.us/fOjh
The problem is that from my PC I can ping www.google.ro for example and I get only the IP but no reply, but when pinging from the lamobo-r1, I get the long awaited reply along with the IP... can't figure out if it's a isc-dhcp-server or a dnsmasq issue...
Also another issue is that I have to issue pon dsl-provider after each restart witch is kinda odd...
For now this is all I could test with the last build... also no wifi testing yet

[badrianiulian]

I was tired trying to make the new Ubuntu_xenial image to work and got back to my old ssd config and upgraded it. Turns out I did good since after upgrading and setting some things up according to the last working configs, I got connectivity with all interfaces (wifi and lans) using my pppoe connection through br1
I think that with the new image, either there's something I missed or the Network Manager may be the culprit.
Anyways the working configs are like this:
/etc/network/if-pre-up.d/router : http://sprunge.us/AcCH
/etc/network/interfaces : http://sprunge.us/YODM
As far as I've tested, this config works well, using my pppoe connection
For DHCP, the lines regarding WAN config need to be replaced with something like
auto br1 iface br1 inet dhcp
Now for /etc/init.d/networking restart command to work like it should, another script needs to be setup in the /etc/network/if-post-down.d/ where all the settings done by the /etc/network/if-pre-up.d/router script are undone. For now I'm just glad that I'm on the newest kernel and all is well.

[badrianiulian]

I was saying that _I think that with the new image, either there's something I missed or the Network Manager may be the culprit._ I think I missed the dnsmasq configuration since on the jessie distribution I used isc-dhcp-server (not anymore)
https://www.dropbox.com/sh/ciiun8n56c46q2n/AACfXvu5cEoZS5jbO6Xc5L4Ha?dl=0 there are working scripts that work for jessie and I think that they might work also with xenial... with dnsmasq set-up just right (since Network Manager uses dnsmasq)
There might be a way to setup the bridges and vlans in Network Manager without beeing setup in interfaces but haven't gotten there just yet.
Right now I'm on last stable 5.25 build with an uptime of 3 days (long stability testing period)

[rpodgorny]

@badrianiulian what is the dtb patch good for? is it necessary?

[badrianiulian]

The dtb patch is something I use for a DS18B20 temperature sensor I have connected to pin 12 ... before I made that patch I used this guide: https://forum.armbian.com/index.php/topic/993-ds18b20-temperature-sensor-in-lamobo-r1/#entry16089
I got tired to go through the same process and found some markers to insert what I needed and checked wether it's ok or not before overwriting at the end of the patch (answer Y _es_ for overwriting)
I do the patching after every upgrade

[dumischbaenger]

Is it possible to get R1 now up and running with vanilla armbian 5.25 or is a patched kernel or os necessary?

[dumischbaenger]

badrianiulian wrote:

Right now I'm on last stable 5.25 build with an uptime of 3 days (long stability testing period)

Does your config work reliable for you? I can start the network and obtain an IP via dhcp but I have problems with this config -> package loss, sometimes no ping, ...

[badrianiulian]

What distribution are you running? I'm on the debian based version... not the ubuntu based version
All works well... but still at some point I had to restart the board because of loss of conectivity.... nothing worked... I already tried everything (had this board for two years now) but the freezes just don't stop.

[dumischbaenger]

I am on 5.25 (Linux lamobo-r1 4.9.12-sunxi) vanilla from Armbian, Debian based, all updates installed. At the moment I use the configuration from BrUser here: https://forum.armbian.com/index.php?/topic/3476-bpi-r1-with-new-b53-switch-driver-dsa/&page=2.

[badrianiulian]

Try my network setup I shared on dropbox.... it should work

[dumischbaenger]

Now I tried your config again. I build a minimal script with your configuration.

I noticed two of your commands throw an error, but I don't think they have something to do with my problems:
+ ip link set dev br0 type bridge stp_state 0
Garbage instead of arguments "stp_state ...". Try "ip link help".

+ bridge vlan add vid 101 dev eth0.101 pvid untagged self
RTNETLINK answers: Operation not supported

Here is the script:

set -xu

ip link set eth0 down
ip addr flush eth0


# =================================
# Setup interfaces and VLANs 
# =================================
ip link set eth0 up
# Create VLAN 101 on interface eth0: eth0.101
ip link add link eth0 name eth0.101 type vlan id 101
# Create bridge br0 with STP(0) on VLAN 101 with interfaces/tagged: 
# lan1 untag lan2 untag lan3 untag lan4 untag wan untag wlan0 untag eth0.101 tag
ip link add br0 type bridge
ip link set dev br0 type bridge stp_state 0

bridge vlan

ip link set lan1 master br0
bridge vlan add vid 101 dev lan1 pvid untagged
bridge vlan add vid 101 dev lan1 pvid untagged self
ip link set lan1 up

ip link set lan2 master br0
bridge vlan add vid 101 dev lan2 pvid untagged
bridge vlan add vid 101 dev lan2 pvid untagged self
ip link set lan2 up

ip link set lan3 master br0
bridge vlan add vid 101 dev lan3 pvid untagged
bridge vlan add vid 101 dev lan3 pvid untagged self
ip link set lan3 up

ip link set lan4 master br0
bridge vlan add vid 101 dev lan4 pvid untagged
bridge vlan add vid 101 dev lan4 pvid untagged self
ip link set lan4 up

ip link set wan master br0
bridge vlan add vid 101 dev wan pvid untagged
bridge vlan add vid 101 dev wan pvid untagged self
ip link set wan up

#ip link set wlan0 master br0
#bridge vlan add vid 101 dev wlan0 pvid untagged
#bridge vlan add vid 101 dev wlan0 pvid untagged self
#ip link set wlan0 up

ip link set eth0.101 master br0
bridge vlan add vid 101 dev eth0.101 pvid untagged
bridge vlan add vid 101 dev eth0.101 pvid untagged self
ip link set eth0.101 up

bridge vlan

ip addr add 192.168.178.2/24 broadcast 192.168.178.255 dev br0
ip route add default via 192.168.178.1

cat > /etc/resolv.conf <<EOF
domain fritz.box
search fritz.box
nameserver 192.168.178.1
EOF

sleep 5

ping 192.168.178.1

Here is the script plus output. At the end of the script the ping works but not reliable. At icmp_seq 24 suddenly three pings got lost. At icmp_seq 29 ditto.

+ ip link set eth0 down
+ ip addr flush eth0
+ ip link set eth0 up
+ ip link add link eth0 name eth0.101 type vlan id 101
+ ip link add br0 type bridge
+ ip link set dev br0 type bridge stp_state 0
Garbage instead of arguments "stp_state ...". Try "ip link help".
+ bridge vlan
port    vlan ids
br0  1 PVID Egress Untagged

+ ip link set lan1 master br0
+ bridge vlan add vid 101 dev lan1 pvid untagged
+ bridge vlan add vid 101 dev lan1 pvid untagged self
+ ip link set lan1 up
+ ip link set lan2 master br0
+ bridge vlan add vid 101 dev lan2 pvid untagged
+ bridge vlan add vid 101 dev lan2 pvid untagged self
+ ip link set lan2 up
+ ip link set lan3 master br0
+ bridge vlan add vid 101 dev lan3 pvid untagged
+ bridge vlan add vid 101 dev lan3 pvid untagged self
+ ip link set lan3 up
+ ip link set lan4 master br0
+ bridge vlan add vid 101 dev lan4 pvid untagged
+ bridge vlan add vid 101 dev lan4 pvid untagged self
+ ip link set lan4 up
+ ip link set wan master br0
+ bridge vlan add vid 101 dev wan pvid untagged
+ bridge vlan add vid 101 dev wan pvid untagged self
+ ip link set wan up
+ ip link set eth0.101 master br0
+ bridge vlan add vid 101 dev eth0.101 pvid untagged
+ bridge vlan add vid 101 dev eth0.101 pvid untagged self
RTNETLINK answers: Operation not supported
+ ip link set eth0.101 up
+ bridge vlan
port    vlan ids
lan2     1 Egress Untagged
     101 PVID Egress Untagged

lan2     1 Egress Untagged
     101 PVID Egress Untagged

lan3     1 Egress Untagged
     101 PVID Egress Untagged

lan3     1 Egress Untagged
     101 PVID Egress Untagged

lan4     1 Egress Untagged
     101 PVID Egress Untagged

lan4     1 Egress Untagged
     101 PVID Egress Untagged

wan  1 Egress Untagged
     101 PVID Egress Untagged

wan  1 Egress Untagged
     101 PVID Egress Untagged

lan1     1 Egress Untagged
     101 PVID Egress Untagged

lan1     1 Egress Untagged
     101 PVID Egress Untagged

eth0.101     1 Egress Untagged
     101 PVID Egress Untagged

eth0.101
br0  1 PVID Egress Untagged

+ ip addr add 192.168.178.2/24 broadcast 192.168.178.255 dev br0
+ ip route add default via 192.168.178.1
+ cat
+ sleep 5
+ ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
64 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=0.547 ms
64 bytes from 192.168.178.1: icmp_seq=2 ttl=64 time=0.552 ms
64 bytes from 192.168.178.1: icmp_seq=3 ttl=64 time=0.501 ms
64 bytes from 192.168.178.1: icmp_seq=4 ttl=64 time=0.409 ms
64 bytes from 192.168.178.1: icmp_seq=5 ttl=64 time=0.526 ms
64 bytes from 192.168.178.1: icmp_seq=6 ttl=64 time=0.537 ms
64 bytes from 192.168.178.1: icmp_seq=7 ttl=64 time=0.572 ms
64 bytes from 192.168.178.1: icmp_seq=8 ttl=64 time=0.541 ms
64 bytes from 192.168.178.1: icmp_seq=9 ttl=64 time=0.874 ms
64 bytes from 192.168.178.1: icmp_seq=10 ttl=64 time=0.499 ms
64 bytes from 192.168.178.1: icmp_seq=11 ttl=64 time=0.537 ms
64 bytes from 192.168.178.1: icmp_seq=12 ttl=64 time=0.559 ms
64 bytes from 192.168.178.1: icmp_seq=13 ttl=64 time=0.571 ms
64 bytes from 192.168.178.1: icmp_seq=14 ttl=64 time=0.477 ms
64 bytes from 192.168.178.1: icmp_seq=15 ttl=64 time=0.556 ms
64 bytes from 192.168.178.1: icmp_seq=16 ttl=64 time=0.583 ms
64 bytes from 192.168.178.1: icmp_seq=17 ttl=64 time=0.460 ms
64 bytes from 192.168.178.1: icmp_seq=18 ttl=64 time=0.553 ms
64 bytes from 192.168.178.1: icmp_seq=19 ttl=64 time=0.543 ms
64 bytes from 192.168.178.1: icmp_seq=20 ttl=64 time=0.501 ms
64 bytes from 192.168.178.1: icmp_seq=21 ttl=64 time=0.511 ms
64 bytes from 192.168.178.1: icmp_seq=22 ttl=64 time=0.549 ms
64 bytes from 192.168.178.1: icmp_seq=23 ttl=64 time=0.531 ms
64 bytes from 192.168.178.1: icmp_seq=24 ttl=64 time=0.548 ms
64 bytes from 192.168.178.1: icmp_seq=27 ttl=64 time=0.441 ms
64 bytes from 192.168.178.1: icmp_seq=28 ttl=64 time=0.483 ms
64 bytes from 192.168.178.1: icmp_seq=29 ttl=64 time=0.506 ms
64 bytes from 192.168.178.1: icmp_seq=32 ttl=64 time=0.474 ms
64 bytes from 192.168.178.1: icmp_seq=33 ttl=64 time=0.555 ms
64 bytes from 192.168.178.1: icmp_seq=34 ttl=64 time=0.542 ms

[badrianiulian]

What configuration are you trying to implement? (be specific about the lans/wan/wlan)
As to the sometimes not responding to ping issue, I had that at first. So to get the right responsive configuration, I had to add the section that undos everything at "pre-down" moment for interfaces stop/restart event.

[dumischbaenger]

What configuration are you trying to implement?

I try to use is as simple switch.

I had to add the section that undos everything at "pre-down"

Okay thank you. I will try that.

[dumischbaenger]

Now I added your "switch down" section to my init script, but I had no success. Network connection is still unreliable.

set -xu


# ================================
# Delete interfaces and VLANs
# ================================
# Delete bridge br0 on VLAN 101 with interfaces/tagged: lan1 untag lan2 untag lan3 untag lan4 untag wan untag wlan0 untag eth0.101 tag
ip link set br0 down
ip link set eth0.101 down
bridge vlan del vid 101 dev eth0.101
ip link set wlan0 down
bridge vlan del vid 101 dev wlan0
ip link set wan down
bridge vlan del vid 101 dev wan
ip link set lan4 down
bridge vlan del vid 101 dev lan4
ip link set lan3 down
bridge vlan del vid 101 dev lan3
ip link set lan2 down
bridge vlan del vid 101 dev lan2
ip link set lan1 down
bridge vlan del vid 101 dev lan1
ip link del br0 type bridge
# Delete VLAN 101 on interface eth0: eth0.101
ip link del link eth0 name eth0.101 type vlan id 101
ip link set eth0 down

ip addr flush eth0




# =================================
# Setup interfaces and VLANs 
# =================================
ip link set eth0 up
# Create VLAN 101 on interface eth0: eth0.101
ip link add link eth0 name eth0.101 type vlan id 101
# Create bridge br0 with STP(0) on VLAN 101 with interfaces/tagged: 
# lan1 untag lan2 untag lan3 untag lan4 untag wan untag wlan0 untag eth0.101 tag
ip link add br0 type bridge
ip link set dev br0 type bridge stp_state 0

bridge vlan

ip link set lan1 master br0
bridge vlan add vid 101 dev lan1 pvid untagged
bridge vlan add vid 101 dev lan1 pvid untagged self
ip link set lan1 up

ip link set lan2 master br0
bridge vlan add vid 101 dev lan2 pvid untagged
bridge vlan add vid 101 dev lan2 pvid untagged self
ip link set lan2 up

ip link set lan3 master br0
bridge vlan add vid 101 dev lan3 pvid untagged
bridge vlan add vid 101 dev lan3 pvid untagged self
ip link set lan3 up

ip link set lan4 master br0
bridge vlan add vid 101 dev lan4 pvid untagged
bridge vlan add vid 101 dev lan4 pvid untagged self
ip link set lan4 up

ip link set wan master br0
bridge vlan add vid 101 dev wan pvid untagged
bridge vlan add vid 101 dev wan pvid untagged self
ip link set wan up

#ip link set wlan0 master br0
#bridge vlan add vid 101 dev wlan0 pvid untagged
#bridge vlan add vid 101 dev wlan0 pvid untagged self
#ip link set wlan0 up

ip link set eth0.101 master br0
bridge vlan add vid 101 dev eth0.101 pvid untagged
bridge vlan add vid 101 dev eth0.101 pvid untagged self
ip link set eth0.101 up

bridge vlan

ip addr add 192.168.178.2/24 broadcast 192.168.178.255 dev br0
ip route add default via 192.168.178.1

cat > /etc/resolv.conf <<EOF
domain fritz.box
search fritz.box
nameserver 192.168.178.1
EOF

sleep 5

ping 192.168.178.1

[zador-blood-stained]

So in the end

• R1 support in Armbian was not dropped, but there are still problems with DSA configuration, so it is not provided for the mainline based images
• b53 driver probing was fixed and ARM: dts: sun7i: lamobo-r1: Fix CPU port RGMII settings patch was merged upstream
• Further discussion of DSA network configuration can continue on the forum: https://forum.armbian.com/index.php?/topic/3476-bpi-r1-with-new-b53-switch-driver-dsa/

[typingArtist]

So in the end

R1 support in Armbian was dropped.

[zador-blood-stained]

R1 support in Armbian was dropped.

It's still available as a build script option (though hidden a little bit) and all older prebuilt images are still available on the download server. But this thread was open on 25 Oct 2016 and since then nobody solved the DSA configuration issue on mainline builds, so this device is no longer listed as "supported".

If anybody is willing to fix and maintain the configuration, it can be moved to the "community supported" section.

[ffainelli]

"But this thread was open on 25 Oct 2016 and since then nobody solved the DSA configuration issue on mainline builds, so this device is no longer listed as "supported"."

What configuration issues exactly? This went into so many different directions that I still have a hard time understanding what are the actual problems met by people with B53 and DSA...

[zador-blood-stained]

What configuration issues exactly? This went into so many different directions that I still have a hard time understanding what are the actual problems met by people with B53 and DSA...

Since I don't own this device (or any other DSA capable device running a DSA enabled kernel) I don't exactly understand this too, but people who own this device have troubles making at least these 2 configurations:

• "Dumb switch" mode (bridge all available ports together)
• "LAN+WAN" mode - bridge all ports marked as "lan" together, and use port marked as "wan" as a separate interface

using Debian Jessie or Ubuntu Xenial userspace tools and current mainline kernel (4.11, 4.12)

[ffainelli]

""Dumb switch" mode (bridge all available ports together)"

-> Create a bridge, have all ports of the switch join the bridge, and create eth0.1 to determine VLAN tags, requires CONFIG_BRIDGE_VLAN_FILTERING=y in the kernel

"LAN+WAN" mode - bridge all ports marked as "lan" together, and use port marked as "wan" as a separate interface

-> Create a bridge, have all ports of the switch join the bridge, create eth0.1 to terminate VLAN tag for LAN traffic, create eth0.2 to terminate VLAN tag for WAN traffic, put "wan" port in PVID 2:
bridge vlan add vid 2 pvid untagged dev wan and that would do it.

I guess I should fire up my Lamobo R1 and give this another try because it has been since 4.9 that I tested that on this particular board and the stmmac driver was also reasonably broken to some extent.

[zador-blood-stained]

Thanks for the explanation, I posted a link to this comment in the forum thread related to R1 DSA discussion.

[tido-]

For R1
The physical WAN port is a separate eth interface on the SoC CPU. The switch Phy is connected to the CPU with a trunk. - is this correct ?

With a typical VLAN switch there is only one bridge (the switch itself), of which every port is a member.
Traffic segmentation is achieved with separate per-port ingress (PVID) and egress VLAN membership rules.
Because Linux can have multiple bridges, the PVID setting is unnecessary.
This is what I read plus/minus here. It makes sense to me but I have no clue how to configure it.

The problem for the DHCPOFFER is that from a Layer-2 perspective the two "devices" (eth0 and eth0.1) are indistinguishable, and so (from a Layer-3 perspective) the DHCPOFFER is destined for 255.255.255.255 (because eth0.1 doesn't yet have an IP address), it should receive one from the DHCP-Server from the Modem.

So it was impossible for me to get an IP-Address on the WAN port and having it separeted from the LAN ports. This I tried to solve, I hope my words makes sense ?

[zador-blood-stained]

The physical WAN port is a separate eth interface on the SoC CPU. The switch Phy is connected to the CPU with a trunk. - is this correct ?

No. According to the DT and schematics so-called "WAN port" is just one of the ports of b53xx switch, and the SoC is connected only to the switch.

[dumischbaenger]

@ffainelli @zador-blood-stained
At the moment Armbian comes with 4.9.7-sunxi. As far as I understand this commit is necessary for the dumb switch mode. If my mind serves me right it was mentioned at armbian.com that this fix comes with 4.11. So at the moment there is no chance to get dumb switch mode working on R1 isn't it?

@ffainelli
In the patch description "default state" is mentioned. What is the wanted default state of an integrated switch after reboot? Dumb switching mode?

[ffainelli]

"So at the moment there is no chance to get dumb switch mode working on R1 isn't it?"

I don't think this is necessary for BCM53125 which is used here, it was only for newer integrated switches such as those in BCM585x (Northstar Plus), BCM7445 and BCM7278, the "dumb switch" you refer to should be the default based on the strapping options anyway.

"In the patch description "default state" is mentioned. What is the wanted default state of an integrated switch after reboot? Dumb switching mode?"

Yes, dumb switch is kind of ideal after reboot.

[wiesl]

This script works on Fedora: https://github.com/armbian/build/issues/511#issuecomment-269622336

just a matter of integration and automation into Debian/Ubuntu (systemd)

[ThomasKaiser]

dumb switch is kind of ideal after reboot.

For something advertised as being a router separating WAN and LAN ports? Seriously?

[rpodgorny]

For something advertised as being a router separating WAN and LAN ports? Seriously?

not again, please. we all know the switch is a joke but let's make it work "somehow" first and "perfect" second...

[ThomasKaiser]

we all know the switch is a joke but let's make it work "somehow" first and "perfect" second...

Are you kidding? Unless you solder a 2k2 ohm resister on unpopulated R1308 soldering pads on the board (who has tried that? Everyone I asked already never came back to me with answers) this is just a dumb switch and can only be operated in this state. At least this device should not be connected to the Internet since it does NOT behave like a router physically separating WAN and LAN.

[rpodgorny]

so you're suggesting what exactly? throwing the boards to the trash bin? let's work with what we have and add a big fat warning about the security implications.

it's unfortunate this issue is being tracked in the armbian repo - this is a distro agnostic thing. let armbian drop the support and "stay safe" and that's ok but it would still be nice to know how to make it work for users who are aware of the implications. i'll have to try the script wiesl referenced once i get to the board again...

[ThomasKaiser]

so you're suggesting what exactly? throwing the boards to the trash bin?

Yes, given the many design flaws (eg. powering problems and shitty onboard Wi-Fi) this is a reasonable option. Also no one will be stupid enough to run a graphics stack on a router/firewall thingie or put NAS data on such a device so what are the remaining use cases anyway?

Fortunately we bought only one of these R1 thingies and implement the only reasonable use case possible: Using the dumb switch as just that connected to a PoE injector powering a bunch of IP cams, recording/re-streaming the h.264 raw streams and using Cedrus to display one of the streams on a connected HDMI display. This requires legacy kernel of course (required to make use of the full feature set of this R1 toy) so I really don't understand why there's a discussion about mainline kerrnel especially as part of an Armbian Github issue where it's about to drop support for this device.

I'll try to unwatch this issue now so feel free to continue your adventures with this fail.

[ThomasKaiser]

I'll try to unwatch this issue now so feel free to continue your adventures with this fail.

[x] done!

[R1SwitchUser]

Hello,
i mean, the R1 works well if you want to have a simple managed 5-port switch or a dumb 5-port switch. For both you can try dsa-example below. I have tested at last at debian desktop:
Linux bpi 4.12.2-sunxi #3 SMP Wed Jul 19 13:40:24 CEST 2017 armv7l GNU/Linux

Router i have not tested, only forwarding problem at boot.
For wan port you must have resistor R1308 (2,2kOhm) to avoid unwanted forwarding to wan-port during boot (u-boot). It is not easy R1308 to solder. But then no forwarding after switch power up in u-boot. I have tested some month ago.
Yes, WiFi only works on short distance only.
But for me, last problem is missing graphics support on mainline.

Current legacy kernel I have tested too. GBit ethernet seems to work only on port 0 ("lan1" on mainline). Possible this is new on legacy? It would nice any can help or have solution.
From my Point of view, drop support is bad because currently there is only R1 with switch available in armbian.

dsa.txt
interfaces.txt

[igorpecovnik]

drop support is bad because currently there is only R1 with switch available in armbian.

Our major mistake, in this case, is that we didn't drop support about one year ago. Armbian crew is tiny and we can not afford to waste precious time on disasters like R1. For all wasted time - all we get back is a constant flow of negative emotions which are damaging to us.

Anyone can proceed from where we left without our involvement.

[ffainelli]

"Router i have not tested, only forwarding problem at boot."

Because there is only CPU port attached to this switch, and 5 external ports, you will have to segregate traffic by creating separate VLANs for the "LAN" ports and the "WAN" ports. We have been doing this for years in OpenWrt/LEDE because a lot of routers have that limitation, there is simply no way around it.

If you are not happy with VLAN tags, we could try to enable Broadcom tags in b53, which would create a similar effect in that the CPU port receives frames pre-pended with per-port metadata (e.g: source port) to deliver traffic only to specific network interfaces. The end result is exactly the same though.

From a Linux driver perspective, are there fundamental issues preventing people to use b53? Based on previous comments it seems to me like there are no more issues. There appears to be two problems though:

• there is a possible mis-understanding of what a "router" is and how to configure it
• there is a board-level problem that makes ports "leak" because of a missing strap resistor

Anything else?

[kotc]

ports leakage only exists during bootup i think. once configured and running (with battery backup) it acts as advertised. as mentioned above it's not meant to be used in any serious application though. home use is good as long one knows about the limitations. so while it might be called a disaster, for me it does what i expect from it without a single problem for 2 years now. and i thank armbian team for initially supporting this disaster ;)

[ThomasKaiser]

once configured and running (with battery backup) it acts as advertised

Nope: http://linux-sunxi.org/Lamobo_R1#Security_Implications

The day your SD card wears out and you reboot this device it comes up as a dumb switch and interconnects all ports (there is no real WAN and there are no real LAN ports, it's just one dumb switch bridging everything on layer 2 by default unless you take your solder iron and fix this crappy device). Soldering resistor R1308 (2,2kOhm) is minimum requirement to speak about WAN and LAN ports and to connect then the WAN port of this thingie to the Internet and let it act as router/firewall.

If you don't do this you have to buy a f*cking USB Ethernet dongle and use this as WAN port. And then you can let the dumb switch be the dumb switch it is and get even one more LAN port for free.

[R1SwitchUser]

@ffainelli : enable Broadcom tags in b53 is a good idea. In B53125 manual i have not found, but if exist, it will solve lldp-problem with VLAN-bit in driver too.
If you change B53_common.c, can you please add for B53125 missing
.arl_entries = 4,
Forwarding problem at boot: If resistor is solded, possible the gap in kernel initalization is short. With ping thest i have not seen any frames forwarded to other ports. Next time I take hrping 5ms.

[ffainelli]

"@ffainelli : enable Broadcom tags in b53 is a good idea. In B53125 manual i have not found, but if exist, it will solve lldp-problem with VLAN-bit in driver too."

Sure, that's the plan at some point, when I get some cycles to work on that. My test setup has a 7445 (bcm_sf2) connected to a BCM53125 (b53) and so there is a bit of Broadcom tag-ception to be sorted first.

"If you change B53_common.c, can you please add for B53125 missing .arl_entries = 4,"

Good catch, submitted: http://patchwork.ozlabs.org/patch/791749/ thanks!

[tido-]

there is a possible mis-understanding of what a "router" is and how to configure it

Please add suggestion to it - or confirm that it fits: https://docs.google.com/presentation/d/1GMGeXn3iX1tCwCTh4oVmHh-SE-XFfbxxH-6wjigV3RI/edit?usp=sharing
Thank you

[tido-]

@ffainelli I did all my testing with: Armbian_5.31_Lamobo-r1_Debian_jessie_next_4.11.5.7z but this is no longer on the download server.
Well at least a 4.11 is available: Armbian_5.27.170611_Lamobo-r1_Ubuntu_xenial_next_4.11.4.7z https://dl.armbian.com/lamobo-r1/nightly/

Where I still stuck is here (Router functionality):
The problem for the DHCPOFFER is that from a Layer-2 perspective the two "devices" (eth0 and eth0.1) are indistinguishable, and so (from a Layer-3 perspective) the DHCPOFFER is destined for 255.255.255.255 (because eth0.1 doesn't yet have an IP address), it should receive one from the DHCP-Server from the Modem - but it cannot.

[ffainelli]

@tido- not sure why that is a problem though because the DHCPOFFER should ingress the switch port with no tag and the switch adds the appropriate VLAN tag (VID 1 or 2 depending configuration/source port) thus making either eth0.1 or eth0.2 receive the DHCPOFFER, am I missing something?

[zador-blood-stained]

am I missing something?

I guess the question (to you) should be rephrased to "which logical interfaces should be used in the configurations discussed above?"

If I understand it correctly, there will be lan?, wan, eth0, eth0.10? and br0 logical interfaces after creating the bridge and VLANs. And at least in the "dumb switch" config br0 should be used to configure a DHCP client or a static IP for the outside connectivity. But what about the "router mode" which should have 2 separate logical interfaces?

[R1SwitchUser]

The wan port does not work anymore in 5-port switch mode in current mainline + U-Boot 2017.07.

In legacy it works with swconfig. All OK if combined with U-Boot 2017.05. Perfect!!! In U-Boot 2017.07 no GBIT only 100MBit.

In mainline problem caused by U-Boot 2017.07 too or last changes in B53_common.c? I will try U-Boot 2017.05.

Possible we need a new thread?!

[tido-]

This is an interesting finding R1SwitchUser.
@zador-blood-stained, how can one compare the sources for U-Boot 2017.05 vs. 2017.07 - is this possible on Github or will we need to extract U-Boot from the image and compare it this way.

The thread has a misleading title, I am with you.

[zador-blood-stained]

@zador-blood-stained, how can one compare the sources for U-Boot 2017.05 vs. 2017.07 - is this possible on Github or will we need to extract U-Boot from the image and compare it this way.

Clone the repository and use "git diff". I'm not sure if the web frontend used on git.denx.de supports listing diff between 2 arbitrary tags.

I don't know of any serious breakages from v2017.05 to v2017.07, but I know that this commit broke A10/A20 networking in general (only in the u-boot itself and legacy kernels which would explain why no one noticed this yet) starting with v2017.05.

[R1SwitchUser]

Now I have generated mainline again. Boot v2017.07 again. Kernel changed 04.12.02-->04.12.03.
Wan port now works, I dont know why.

Additional have try router configuration, switch part only, based on 5-port Switch (but not router itself):
dsa:
lan1, lan2, lan3, lan4, wan -->eth0.101, eth0.102, eth0.103, eth0.104, eth0.105
eth0.101, eth0.102, eth0.103, eth0.104 --> br0 (local Network)
eth0.105 --> br1 ( wan )
Interfaces:
br0 static IP
br1 DHCP

Result:
DHCP works at br1.
lan1, lan2, lan3, lan4 forwarded, but not forwarded to br1, only seen in br0

I think, dummischbaenger has used this some month before with success.

Possible we do not need B53125-internal dumb switch configuration or internal wan configuration and effort to implement.

[ffainelli]

Just have one bridge device encompassing all ports of the switch and have as many VLANs are you need per-port within this bridge. You can have two bridges if you want, but the results are not going to be way different.

[tido-]

With SWCONFIG I need the bridge for: WLAN & LAN.
With DSA this is different - I think.

Like this I would have a bridge and 2 VLANs
```
* create the BRIDGE *
ip link add br0 type bridge

* ALLOCATION *
ip link set lan1 master br0
ip link set lan2 master br0
ip link set lan3 master br0
ip link set lan4 master br0
ip link set wlan0 master br0

* create the native VLAN *
ip link add link eth0 name eth0.101 type vlan id 101
ip link add link eth0 name eth0.102 type vlan id 102
```
So far so good BUT how do I now tell the switch that the WAN port is eth0.101 and the bridge gets eth0.102 ?

In order to understand which command doesn't work I copied in one after the other - an I was never able to get it to run as a router.

[ffainelli]

"So far so good BUT how do I now tell the switch that the WAN port is eth0.101 and the bridge gets eth0.102 ?"

Well you configure "wan" to be in VLAN 102:

bridge vlan add vid 102 pvid untagged dev wan

[R1SwitchUser]

Yes, but four vlans for lan1, ... lan4 looks like a four-port dumb switch, but can used for managed ports too.
More interesting features from switch are special tagging vs. VLAN, time stamp, access to more registers from Switch ... .

[ffainelli]

Which has nothing to do with what was originally described, so my take away from this conversion is that there was indeed one problem with the 53125's num_arl_entries, which is now fixed and will be backported, and basic VLAN/FDB functionality works as expected. If that is not the case, email me.

[R1SwitchUser]

Oh sorry, I was too slow.
in legacy I think you need only one bridge for local ports, for wan you can add eth0.102 in interfaces (DHCP).
In mainline you need two bridges, locale ports you can give same VID, possible. One bridge was not working at my r1.

[ffainelli]

OK, why would a second bridge be needed? And which commit is responsible for changing that do you think?

[AntonioTrindade]

I have been able to get router functionality using the following script for DSA:

ip link set eth0 down
ip addr flush eth0
ip link set eth0 up
ip link add link eth0 name eth0.101 type vlan id 101
ip link add link eth0 name eth0.102 type vlan id 102
ip link add name br0 type bridge
ip link add br1 type bridge
ip link set lan1 master br0
ip link set lan2 master br0
ip link set lan3 master br0
ip link set lan4 master br0
ip link set wan master br1
bridge vlan add vid 101 dev lan1 pvid untagged
bridge vlan add vid 101 dev lan2 pvid untagged
bridge vlan add vid 101 dev lan3 pvid untagged
bridge vlan add vid 101 dev lan4 pvid untagged
bridge vlan del dev lan1 vid 1 self
bridge vlan del dev lan2 vid 1 self
bridge vlan del dev lan3 vid 1 self
bridge vlan del dev lan4 vid 1 self
bridge vlan del dev lan1 vid 1 master
bridge vlan del dev lan2 vid 1 master
bridge vlan del dev lan3 vid 1 master
bridge vlan del dev lan4 vid 1 master
bridge vlan add vid 102 dev wan pvid untagged
bridge vlan del dev wan vid 1 seld
bridge vlan del dev wan vid 1 self
bridge vlan del dev wan vid 1 master
ip link set eth0.101 master br0
ip link set eth0.102 master br1
ip link set br0 up
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
ip link set lan4 up
ip link set wan up
ip link set br1 up

After this, I do:

dhclient br1

and run the following IPTable rules:

iptables -A INPUT -i br0 -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 192.168.2.0/24 -i br0 -j ACCEPT
iptables -A FORWARD -d 192.168.2.0/24 -i br1 -j ACCEPT
iptables -t nat -A POSTROUTING -o br1 -j MASQUERADE
iptables -P INPUT ACCEPT
iptables -P FORWARD DROP

(I have the policy for INPUT as ACCEPT only for testing)
My /etc/network/interfaces file is as follows:

iface lo inet loopback

auto eth0.101
iface eth0.101 inet manual

auto eth0.102
iface eth0.102 inet manual

allow-hotplug wlan0
iface wlan0 inet manual

allow-hotplug wlan1
iface wlan1 inet manual

# WAN
auto br1
iface br1 inet dhcp
bridge_ports eth0.101

# LAN
auto br0
iface br0 inet static
bridge_ports eth0.102
    address 192.168.2.254
    netmask 255.255.255.0

Now I'm trying to integrate the first script with this, so that all interfaces come up on boot.

Note: I am not using the built-in WLAN card. I use a TP-Link TP-WN722N connected to a USB hub, which is connected to the USB port, so I can plug in a keyboard as well. I blacklisted the rtl8192cu driver and I am trying to use only the external WLAN (wlan1).

Now my problem is getting hostapd working as well.

Can anyone try to help me integrate the DSA configuration into interfaces file?

[ruyrybeyro]

Hi Antonio, in Lisbon too? As a side note, blacklisting the realtek wifi is
not enough. I only had a stable R1 after disabling it physically.

On 24 July 2017 at 21:49, AntonioTrindade [e-mail] wrote:

I have been able to get router functionality using the following script
for DSA:

ip link set eth0 down
ip addr flush eth0
ip link set eth0 up
ip link add link eth0 name eth0.101 type vlan id 101
ip link add link eth0 name eth0.102 type vlan id 102
ip link add name br0 type bridge
ip link add br1 type bridge
ip link set lan1 master br0
ip link set lan2 master br0
ip link set lan3 master br0
ip link set lan4 master br0
ip link set wan master br1
bridge vlan add vid 101 dev lan1 pvid untagged
bridge vlan add vid 101 dev lan2 pvid untagged
bridge vlan add vid 101 dev lan3 pvid untagged
bridge vlan add vid 101 dev lan4 pvid untagged
bridge vlan del dev lan1 vid 1 self
bridge vlan del dev lan2 vid 1 self
bridge vlan del dev lan3 vid 1 self
bridge vlan del dev lan4 vid 1 self
bridge vlan del dev lan1 vid 1 master
bridge vlan del dev lan2 vid 1 master
bridge vlan del dev lan3 vid 1 master
bridge vlan del dev lan4 vid 1 master
bridge vlan add vid 102 dev wan pvid untagged
bridge vlan del dev wan vid 1 seld
bridge vlan del dev wan vid 1 self
bridge vlan del dev wan vid 1 master
ip link set eth0.101 master br0
ip link set eth0.102 master br1
ip link set br0 up
ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
ip link set lan4 up
ip link set wan up
ip link set br1 up

After this, I do:

dhclient br1

and run the following IPTable rules:

iptables -A INPUT -i br0 -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 192.168.2.0/24 -i br0 -j ACCEPT
iptables -A FORWARD -d 192.168.2.0/24 -i br1 -j ACCEPT
iptables -t nat -A POSTROUTING -o br1 -j MASQUERADE
iptables -P INPUT ACCEPT
iptables -P FORWARD DROP

(I have the policy for INPUT as ACCEPT only for testing)
My /etc/network/interfaces file is as follows:

iface lo inet loopback

auto eth0.101
iface eth0.101 inet manual

auto eth0.102
iface eth0.102 inet manual

allow-hotplug wlan0
iface wlan0 inet manual

allow-hotplug wlan1
iface wlan1 inet manual

WAN

auto br1
iface br1 inet dhcp
bridge_ports eth0.101

LAN

auto br0
iface br0 inet static
bridge_ports eth0.102
address 192.168.2.254
netmask 255.255.255.0

Now I'm trying to integrate the first script with this, so that all
interfaces come up on boot.

Note: I am not using the built-in WLAN card. I use a TP-Link TP-WN722N
connected to a USB hub, which is connected to the USB port, so I can plug
in a keyboard as well. I blacklisted the rtl8192cu driver and I am trying
to use only the external WLAN (wlan1).

Now my problem is getting hostapd working as well.

Can anyone try to help me integrate the DSA configuration into interfaces
file?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/armbian/build/issues/511#issuecomment-317550242, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJ4wv-1y4wh-e12nwALWgScE1lOrw0Jjks5sRQN3gaJpZM4KftkS
.

--
Regards,

--
Rui Ribeiro
Senior Linux Architect and Network Administrator
ISCTE-IUL
https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434

[AntonioTrindade]

Ok. Forget it. I don't know how, but after a reboot all came back ok. HostAPD works, IP forwarding too, and all interfaces come up OK.
I just had to copy the DSA script (the first and largest on) in the file /etc/network/if-pre-up.d/dsa, turn it executable and reboot.

@ruyrybeyro how did you disable it "physically"? Did you remove the module from the board? I do not have the tools to remove it physically, nor am willing to do so; I fear I might damage the board.

[ruyrybeyro]

I tried to desolder it, but then I noticed it rest in a small wafer of it's
own, and just used a pointed knife under that (navalha).

On 24 July 2017 at 22:52, AntonioTrindade [e-mail] wrote:

Ok. Forget it. I don't know how, but after a reboot all came back ok.
HostAPD works, IP forwarding too, and all interfaces come up OK.
I just had to copy the DSA script (the first and largest on) in the file
/etc/network/if-pre-up.d/dsa, turn it executable and reboot.

@ruyrybeyro https://github.com/ruyrybeyro how did you disable it
"physically"? Did you remove the module from the board? I do not have the
tools to remove it physically, nor am willing to do so; I fear I might
damage the board.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/armbian/build/issues/511#issuecomment-317565763, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJ4wvwAKr3wshWYRd6u0sXxnkgHzwnfyks5sRRIHgaJpZM4KftkS
.

--
Regards,

--
Rui Ribeiro
Senior Linux Architect and Network Administrator
ISCTE-IUL
https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434

[dumischbaenger]

@AntonioTrindade
Your config looks very good what os/kernel are you using?

[AntonioTrindade]

@dumischbaenger
I am using ARMBIAN 5.31 stable Debian GNU/Linux 8 (jessie) 4.9.7-sunxi.

I have routing working on WiFi and ethernet connections (all 4 "LAN" ports work!). I also tested several reboots to see if the configuration would hold. I tested with an Android tablet, an Android phone and an Ubuntu laptop. Still haven't tried Windows, but I'm sure it will work.

I've run a few SpeedTest tests and cannot get as fast as I can when using my main router, but I suspect the reason is that the Banana Pi is behind the main router as well. But I can get 95-98% of the speed I get (wired and WiFi) using the main router, so I really suspect it is because of routing overhead.

Just to complement my previous post, I put the IPTables script in /etc/network/if-pre-up.d as well as the DSA one. I could have used iptables-save and iptables-restore, but I prefer to configure the firewall as I showed it, because you can easily edit it, instead of adding rules and forget to save them... ;) .
I also tidied up the scripts and substituted some hardcoded values with variables. If anyone wants, I can paste them here. Or, you can visit my blog https://trindade.myphotos.cc/receitasinformaticas/ where I'm writing all this (in Portuguese, for the moment, but I'm expecting to translate to English in a few days/weeks).

As a side note, I'm sad this board is not officially supported, because I was able to get a stable configuration, albeit using an external WiFi interface.

[igorpecovnik]

As a side note, I'm sad this board is not officially supported, because I was able to get a stable configuration, albeit using an external WiFi interface.

If someone decide to continue support, he is welcome. Project is open and all you need is to submit changes, patches including renaming board config from .eos to .csc (community supported configuration).

[tido-]

Well you configure "wan" to be in VLAN 102:
bridge vlan add vid 102 pvid untagged dev wan

I have tried your tipp but it didn't work. I tried it in different manner, see errors:

root@lamobo:~# bridge vlan add id 101 pvid untagged dev wan
Device and VLAN ID are required arguments.

root@lamobo:~# bridge vlan add vid 101 pvid untagged dev wa
Cannot find bridge device "wa"

root@lamobo:~# bridge vlan add vid 101 pvid untagged dev wan
RTNETLINK answers: Operation not supported

#!/bin/sh
# filename: /etc/network/if-pre-up.d/dsa
#------------------------------------------#
# BPI-R1 DSA VLAN configuration            #
# Distributed Switch Architecture interface#
#------------------------------------------#
#
# eth0 is fully transparent, like not there from an IP view.
# We will create the following ethernet ports:
# - eth0.101 = WAN (single port)
# - eth0.102 = LAN (4 port switch) + WLAN
#
# what belongs here and what belongs to interfaces ?

ip link set eth0 up

# ** create the BRIDGE **
ip link add br0 type bridge

# ** create the native VLAN **
ip link add link eth0 name eth0.101 type vlan id 101
ip link add link eth0 name eth0.102 type vlan id 102

# ** ALLOCATION VLAN **
ip link set eth0.102 master br0
bridge vlan add vid 101 pvid untagged dev wan

# ** ALLOCATION Bridge **
ip link set lan1 master br0
ip link set lan2 master br0
ip link set lan3 master br0
ip link set lan4 master br0
#ip link set wlan0 master br0 does not work.

# ** ACTIVATE /Start **
ip link set dev br0 up

ip link set eth0.101 up
ip link set eth0.102 up

ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
ip link set lan4 up

#ip link set wlan0 up
ip link set up wan

[AntonioTrindade]

@tido-
Try my config. It works! :)

[dumischbaenger]

I tested today AntonioTrindade's script. It seems to work fine.

There is a typo in this script. I replaced the line

bridge vlan del dev wan vid 1 seld

with

bridge vlan del dev wan vid 1 self

My aim is a "dumb switch" setup so I added the lines

ip link set eth0.101 up
ip link set eth0.102 up
dhclient br0

and voila the switched worked. The attached devices were "pingable".

I will further adapt AntonioTrindade's script for simple switch usage and report results.

[dumischbaenger]

I played a little with the network init skript and as I entered the command

bridge vlan

I saw this vlan filtering rules

lan1     101 PVID Egress Untagged

eth0.101         1 PVID Egress Untagged

eth0.101
eth0.102         1 PVID Egress Untagged

eth0.102
br0      1 PVID Egress Untagged

br1      1 PVID Egress Untagged

I wonder why does every device have a filtering rule with vlan 1. Especially the vlan devices eth0.101 and eth0.102. I would have expected a rule with vid 101 for eth0.101 and a similar rule for eth0.102?

Does vid 1 have a special meaning?

[ffainelli]

No VID 1 is just the default VID (default_pvid) that the bridge creates by default.

[tido-]

While I was trying to get the R1 to work I had to read a lot about VLAN.
An excerpt what I found on the internet:
There is a difference between Default VLAN and Native VLAN.
Native VLAN can be of a value of the 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.

So what you are shortly express here is that I should take care about THE 1.
Is this the reason that you used 102 in your example:

• vid 102 pvid untagged dev wan ?

Which would lead me to the assumption that this was always wrong for DSA but worked with SWCONFIG:

• eth0.101 = WAN (single port)
• eth0.102 = LAN (4 port switch) + WLAN
  That I have described in this posting.

So I have tested this, but it still doesn't work:

root@lamobo:~# ip link add br0 type bridge
root@lamobo:~# ip link add link eth0 name eth0.103 type vlan id 103
root@lamobo:~# ip link add link eth0 name eth0.102 type vlan id 102

root@lamobo:~# ip link set eth0.102 master br0
root@lamobo:~# bridge vlan add vid 103 pvid untagged dev wan
RTNETLINK answers: Operation not supported

root@lamobo:~# bridge vlan add vid 203 pvid untagged dev wan
RTNETLINK answers: Operation not supported

root@lamobo:~# cat /proc/net/vlan/config
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.101       | 101  | eth0
eth0.102       | 102  | eth0
eth0.103       | 103  | eth0
eth0.203       | 203  | eth0

I restarted the R1 now and this time only this:

root@lamobo:~# ls /sys/class/net/
br0  eth0  eth0.102  eth0.103  lan1  lan2  lan3  lan4  lo  wan  wlan0


root@lamobo:~# bridge vlan show
port    vlan ids
lan2     1 PVID Egress Untagged

lan2     1 PVID Egress Untagged

lan3     1 PVID Egress Untagged

lan3     1 PVID Egress Untagged

lan4     1 PVID Egress Untagged

lan4     1 PVID Egress Untagged

lan1     1 PVID Egress Untagged

lan1     1 PVID Egress Untagged

br0      1 PVID Egress Untagged

eth0.102         1 PVID Egress Untagged

eth0.102


root@lamobo:~# cat /run/network/ifstate
lo=lo
eth0.103=eth0.103
eth0.102=eth0.102
wlan0=wlan0
br0=br0


root@lamobo:~# bridge fdb show
33:22:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
01:80:c2:00:00:21 dev eth0 self permanent
33:33:ff:02:55:93 dev eth0 self permanent
33:22:00:00:00:01 dev wlan0 self permanent
01:00:5e:00:00:01 dev wlan0 self permanent
33:22:00:00:00:01 dev br0 self permanent
01:00:5e:00:00:01 dev br0 self permanent
33:33:ff:02:55:93 dev br0 self permanent
02:cc:07:02:55:93 dev eth0.102 master br0 permanent
02:cc:07:02:55:93 dev eth0.102 vlan 1 master br0 permanent


root@lamobo:~# ifconfig -a | awk '/HWaddr/ {print "Interface: " $1 "\t MAC: " $N 
Interface: br0   MAC: 02:cc:07:02:55:93
Interface: eth0  MAC: 02:cc:07:02:55:93
Interface: eth0.102      MAC: 02:cc:07:02:55:93
Interface: eth0.103      MAC: 02:cc:07:02:55:93
Interface: lan1  MAC: 02:cc:07:02:55:93
Interface: lan2  MAC: 02:cc:07:02:55:93
Interface: lan3  MAC: 02:cc:07:02:55:93
Interface: lan4  MAC: 02:cc:07:02:55:93
Interface: wan   MAC: 02:cc:07:02:55:93
Interface: wlan0         MAC: ac:a2:13:2c:ac:7d

[ruyrybeyro]

Please be aware R1 does not support 802.1Q tags, and the VLANs are internal
to the Broadcom chipset switch.

On 28 July 2017 at 04:06, Reto [e-mail] wrote:

While I was trying to get the R1 to work I had to read a lot about VLAN.
An excerpt what I found on the internet:
There is a difference between Default VLAN and Native VLAN.
Native VLAN can be of a value of the 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.

So what you are shortly express here is that I should take care about THE
1.
Is this the reason that you used 102 in your example:

• vid 102 pvid untagged dev wan ?

Which would lead me to the assumption that this was always wrong for DSA
but worked with SWCONFIG:

• eth0.101 = WAN (single port)
• eth0.102 = LAN (4 port switch) + WLAN
  That I have described in this posting
  https://forum.armbian.com/index.php?/topic/3476-bpi-r1-with-new-b53-switch-driver-dsa/&do=findComment&comment=26470
  .

So I have tested this, but it still doesn't work:

root@lamobo:~# ip link add br0 type bridge
root@lamobo:~# ip link add link eth0 name eth0.103 type vlan id 103
root@lamobo:~# ip link add link eth0 name eth0.102 type vlan id 102

root@lamobo:~# ip link set eth0.102 master br0
root@lamobo:~# bridge vlan add vid 103 pvid untagged dev wan
RTNETLINK answers: Operation not supported

root@lamobo:~# bridge vlan add vid 203 pvid untagged dev wan
RTNETLINK answers: Operation not supported

root@lamobo:~# cat /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.101 | 101 | eth0
eth0.102 | 102 | eth0
eth0.103 | 103 | eth0
eth0.203 | 203 | eth0

I restarted the R1 now and this time only this:

root@lamobo:~# ls /sys/class/net/
br0 eth0 eth0.102 eth0.103 lan1 lan2 lan3 lan4 lo wan wlan0

root@lamobo:~# bridge vlan show
port vlan ids
lan2 1 PVID Egress Untagged

lan2 1 PVID Egress Untagged

lan3 1 PVID Egress Untagged

lan3 1 PVID Egress Untagged

lan4 1 PVID Egress Untagged

lan4 1 PVID Egress Untagged

lan1 1 PVID Egress Untagged

lan1 1 PVID Egress Untagged

br0 1 PVID Egress Untagged

eth0.102 1 PVID Egress Untagged

eth0.102

root@lamobo:~# cat /run/network/ifstate
lo=lo
eth0.103=eth0.103
eth0.102=eth0.102
wlan0=wlan0
br0=br0

root@lamobo:~# bridge fdb show
33:33:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
01:80:c2:00:00:21 dev eth0 self permanent
33:33:ff:02:66:93 dev eth0 self permanent
33:33:00:00:00:01 dev wlan0 self permanent
01:00:5e:00:00:01 dev wlan0 self permanent
33:33:00:00:00:01 dev br0 self permanent
01:00:5e:00:00:01 dev br0 self permanent
33:33:ff:02:66:93 dev br0 self permanent
02:cc:07:02:66:93 dev eth0.102 master br0 permanent
02:cc:07:02:66:93 dev eth0.102 vlan 1 master br0 permanent

root@lamobo:~# ifconfig -a | awk '/HWaddr/ {print "Interface: " $1 "\t MAC: " $N
Interface: br0 MAC: 02:cc:07:02:55:93
Interface: eth0 MAC: 02:cc:07:02:55:93
Interface: eth0.102 MAC: 02:cc:07:02:55:93
Interface: eth0.103 MAC: 02:cc:07:02:55:93
Interface: lan1 MAC: 02:cc:07:02:55:93
Interface: lan2 MAC: 02:cc:07:02:55:93
Interface: lan3 MAC: 02:cc:07:02:55:93
Interface: lan4 MAC: 02:cc:07:02:55:93
Interface: wan MAC: 02:cc:07:02:55:93
Interface: wlan0 MAC: ac:a2:13:2c:ac:7d

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/armbian/build/issues/511#issuecomment-318544240, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJ4wv6k_2dhG1vU2ZfjLNCR2PpBfLosqks5sSVAbgaJpZM4KftkS
.

--
Regards,

--
Rui Ribeiro
Senior Linux Architect and Network Administrator
ISCTE-IUL
https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434

[ffainelli]

Reto, do you have CONFIG_BRIDGE_VLAN_FILTERING enabled in your kernel?
Without it you would see this not supported error message.

[ffainelli]

Also, with DSA the bridge is only used as a controlling device for bridge
VLAN filtering but it is not necessary to enslave any eth0. interfaces
in the bridge these interfaces should remain outside of the bridge.

[tido-]

@ruyrybeyro, what does make you think so; 802.1Q

==========
The BCM53125 delivers the most comprehensive technologies required by top tier service providers for gateway applications.
Protocols such as IEEE 802.1Q-based VLAN with 4K entries, port-based VLAN, VLAN double tagging (Q-in-Q), and VLAN translation are fully supported.

Two additional Gigabit ports for glueless connection to CPU, WLAN, Cable, or DSL chipsets

* you find this here, last slide *

so only if there is no driver support..

[ffainelli]

BCM53125 supports VLANs, there is no problems about that. stmmac which is used does not AFAIR support hardware VLAN insertion/extraction, but it is easy enough to do in software anyway.

[tido-]

A good question, I don't know as I am just using the armbian Kernel 4.11.5
I searched here:
linux-sun8i-default.config

but all I found that sounds similar:
CONFIG_BRIDGE_NETFILTER=y
https://github.com/armbian/build/blob/master/config/kernel/linux-sun8i-default.config#L706
https://github.com/armbian/build/blob/master/config/kernel/linux-sun7i-default.config

So I guess it is not enabled. @zador-blood-stained, can you comment ?

[zador-blood-stained]

I searched here:
linux-sun8i-default.config

Why? :smile:

It's enabled (as module) in linux-sunxi-next.config, and you can verify it on your device like this:

➜  ~  % grep CONFIG_BRIDGE_NETFILTER /boot/config-$(uname -r)
CONFIG_BRIDGE_NETFILTER=m
➜  ~  %

Edit:
or like this:

➜  ~  % zgrep CONFIG_BRIDGE_NETFILTER /proc/config.gz
CONFIG_BRIDGE_NETFILTER=m
➜  ~  %

[zador-blood-stained]

Also we are talking about CONFIG_BRIDGE_VLAN_FILTERING

➜  ~  % zgrep CONFIG_BRIDGE_VLAN /proc/config.gz
CONFIG_BRIDGE_VLAN_FILTERING=y
➜  ~  %

[tido-]

why, because I like it the hardway - or I simply didn't know where else to search :) Thank you.
Another question the patch Florian submitted, will we get that as well ?

"If you change B53_common.c, can you please add for B53125 missing .arl_entries = 4,"

root@lamobo:~# grep CONFIG_BRIDGE_NETFILTER /boot/config-$(uname -r)
CONFIG_BRIDGE_NETFILTER=m

root@lamobo:~# zgrep CONFIG_BRIDGE_VLAN /proc/config.gz
CONFIG_BRIDGE_VLAN_FILTERING=y

root@lamobo:~# lsmod
Module                  Size  Used by
8021q                  24576  0 
garp                   16384  1 8021q
mrp                    16384  1 8021q
bridge                102400  0 
stp                    16384  2 garp,bridge
llc                    16384  3 garp,bridge,stp
rtl8192cu              57344  0 
rtl_usb                20480  1 rtl8192cu
rtl8192c_common        32768  1 rtl8192cu
rtlwifi                49152  3 rtl_usb,rtl8192c_common,rtl8192cu
mac80211              430080  3 rtl_usb,rtlwifi,rtl8192cu
sun4i_codec            32768  3 
evdev                  20480  1 
cfg80211              352256  2 mac80211,rtlwifi
rfkill                 20480  1 cfg80211
snd_soc_core          114688  1 sun4i_codec
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_pcm                69632  2 snd_pcm_dmaengine,snd_soc_core
snd_timer              24576  1 snd_pcm
snd                    45056  3 snd_timer,snd_soc_core,snd_pcm
soundcore              16384  1 snd
ir_lirc_codec          16384  0 
lirc_dev               16384  1 ir_lirc_codec
nvmem_sunxi_sid        16384  0 
nvmem_core             16384  1 nvmem_sunxi_sid
sunxi_cir              16384  0 
sun4i_ss               24576  0 
cpufreq_dt             16384  0 
uio_pdrv_genirq        16384  0 
uio                    16384  1 uio_pdrv_genirq
b53_mdio               16384  0 
b53_common             28672  1 b53_mdio
fuse                   69632  1 

[zador-blood-stained]

Another question the patch Florian submitted, will we get that as well ?
"If you change B53_common.c, can you please add for B53125 missing .arl_entries = 4,"

No (not present in current sources), it needs to be added: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/dsa/b53/b53_common.c?h=v4.11.5

[tido-]

with DSA the bridge is only used as a controlling device for bridge VLAN filtering,
but it is not necessary to enslave any eth0. interfaces in the bridge. VLAN interfaces should remain outside of the bridge.
@ffainelli, have you downloaded an image and powered your R1 yet?

Networking hardware of R1 comes with: A20, B53 and WLAN on USB-bus.
To my understanding you use a bridge to combine LAN(eth0.102) & WLAN, so dhcpserver can serve these ports. Before DSA we kept them together in 'br0' - this worked well.

Currently, I am able to build 'br0' and to attach 4 x LAN,
but it is impossible to get a VLAN to the WAN-port.

root@lamobo:~# bridge vlan add vid 103 pvid untagged dev wan
RTNETLINK answers: Operation not supported
 ```
And because of that the problem remains that R1 cannot accept  DHCPOFFER.

These are my configuration files:
nano /etc/network/if-pre-up.d/dsa

!/bin/sh

------------------------------------------

BPI-R1 DSA VLAN configuration

Distributed Switch Architecture interface

------------------------------------------

#

- eth0.101 = WAN (single port)

- eth0.102 = LAN (4 port switch) + WLAN

#

ip link set eth0 up

* create the BRIDGE *

ip link add br0 type bridge

* create the native VLAN *

ip link add link eth0 name eth0.101 type vlan id 101
ip link add link eth0 name eth0.102 type vlan id 102

* ALLOCATION VLAN *

ip link set eth0.102 master br0
bridge vlan add vid 101 pvid untagged dev wan

* ALLOCATION Bridge *

ip link set lan1 master br0
ip link set lan2 master br0
ip link set lan3 master br0
ip link set lan4 master br0

* ACTIVATE /Start *

ip link set dev br0 up

ip link set eth0.101 up
ip link set eth0.102 up

ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
ip link set lan4 up

ip link set up wan

nano /etc/network/interfaces

auto lo
iface lo inet loopback

allow-hotplug eth0
allow-hotplug wlan0

* LAN config VLAN 1, WAN port *

receive IP-Address from your Router or Cable modem

auto eth0.101
iface eth0.101 inet dhcp

* LAN config VLAN 2, for the 4 ports *

generate IP-Address for connected devices

auto eth0.102
iface eth0.102 inet manual

* WLAN config *

generate IP-Address for connected devices

auto wlan0
iface wlan0 inet manual

* Bridge config *

auto br0
iface br0 inet static
bridge_ports eth0.102 wlan0
bridge_waitport 0
address 192.168.9.2
network 192.168.9.0
netmask 255.255.255.0
```
Your testing is greatly appreciated :1st_place_medal:

[ffainelli]

Wrote it before, if you want to be able to change the "wan" interface VLAN
you need it to be part of the bridge... Otherwise it will just stay with
the default VLAN id (0) on its own.

On Jul 29, 2017 01:33, "Reto" [e-mail] wrote:

with DSA the bridge is only used as a controlling device for bridge VLAN
filtering,
but it is not necessary to enslave any eth0. interfaces in the
bridge. VLAN interfaces should remain outside of the bridge.
@ffainelli https://github.com/ffainelli, have you downloaded an image
https://github.com/armbian/build/issues/511#issuecomment-317161772 and
powered your R1 yet?

Networking hardware of R1 comes with: A20, B53
https://forum.armbian.com/index.php?/topic/3476-bpi-r1-with-new-b53-switch-driver-dsa/#comment-26470
and WLAN on USB-bus.
To my understanding you use a bridge to combine LAN(eth0.102) & WLAN, so
dhcpserver can serve these ports. Before DSA we kept them together in
'br0' - this worked well.

Currently, I am able to build 'br0' and to attach 4 x LAN,
but it is impossible to get a VLAN to the WAN-port.

root@lamobo:~# bridge vlan add vid 103 pvid untagged dev wan
RTNETLINK answers: Operation not supported

And because of that the problem remains that r1 cannot accept DHCPOFFER.

These are my configuration files:
nano /etc/network/if-pre-up.d/dsa

!/bin/sh

------------------------------------------

BPI-R1 DSA VLAN configuration

Distributed Switch Architecture interface

------------------------------------------

#

- eth0.101 = WAN (single port)

- eth0.102 = LAN (4 port switch) + WLAN

#

ip link set eth0 up

* create the BRIDGE *

ip link add br0 type bridge

* create the native VLAN *

ip link add link eth0 name eth0.101 type vlan id 101
ip link add link eth0 name eth0.102 type vlan id 102

* ALLOCATION VLAN *

ip link set eth0.102 master br0
bridge vlan add vid 101 pvid untagged dev wan

* ALLOCATION Bridge *

ip link set lan1 master br0
ip link set lan2 master br0
ip link set lan3 master br0
ip link set lan4 master br0

* ACTIVATE /Start *

ip link set dev br0 up

ip link set eth0.101 up
ip link set eth0.102 up

ip link set lan1 up
ip link set lan2 up
ip link set lan3 up
ip link set lan4 up

ip link set up wan

nano /etc/network/interfaces

auto lo
iface lo inet loopback

allow-hotplug eth0
allow-hotplug wlan0

* LAN config VLAN 1, WAN port *

receive IP-Address from your Router or Cable modem

auto eth0.101
iface eth0.101 inet dhcp

* LAN config VLAN 2, for the 4 ports *

generate IP-Address for connected devices

auto eth0.102
iface eth0.102 inet manual

* WLAN config *

generate IP-Address for connected devices

auto wlan0
iface wlan0 inet manual

* Bridge config *

auto br0
iface br0 inet static
bridge_ports eth0.102 wlan0
bridge_waitport 0
address 192.168.9.2
network 192.168.9.0
netmask 255.255.255.0

Your testing is greatly appreciated 🥇

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/armbian/build/issues/511#issuecomment-318813866, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABDwHPkzE1c8R-EZeAuxSwoa-_Yf3iz2ks5sSu5OgaJpZM4KftkS
.

[hknaack]

These are my current DSA configuration files, used in the last 5.31 build on the download server with Debian Jessie next. So far, I haven't been successful in starting hostapd, therefore I just configured the ethernet part.

/etc/network/interfaces.r1DSArouter:

```auto lo
iface lo inet loopback

auto eth0.101
iface eth0.101 inet static
pre-up ip link add br0 type bridge
pre-up ip link set wan master br0
pre-up bridge vlan add vid 101 dev wan pvid untagged
pre-up bridge vlan del vid 1 dev wan
pre-up ip link set wan up
post-down ip link set wan down
address 192.168.1.3/24
gateway 192.168.1.200
dns-nameservers 192.168.1.200

auto eth0.102
iface eth0.102 inet static
pre-up ip link set lan1 master br0
pre-up ip link set lan2 master br0
pre-up ip link set lan3 master br0
pre-up ip link set lan4 master br0
pre-up bridge vlan add vid 102 dev lan1 pvid untagged
pre-up bridge vlan del vid 1 dev lan1
pre-up ip link set lan1 up
pre-up bridge vlan add vid 102 dev lan2 pvid untagged
pre-up bridge vlan del vid 1 dev lan2
pre-up ip link set lan2 up
pre-up bridge vlan add vid 102 dev lan3 pvid untagged
pre-up bridge vlan del vid 1 dev lan3
pre-up ip link set lan3 up
pre-up bridge vlan add vid 102 dev lan4 pvid untagged
pre-up bridge vlan del vid 1 dev lan4
pre-up ip link set lan4 up
post-down ip link set lan4 down
post-down ip link set lan3 down
post-down ip link set lan2 down
post-down ip link set lan1 down
post-down ip link del dev br0
address 192.168.0.200/24

allow-hotplug wlan0
iface wlan0 inet manual

/etc/network/interfaces.r1DSAswitch:

```auto lo
iface lo inet loopback

auto eth0.101
iface eth0.101 inet static
    pre-up ip link add br0 type bridge
    pre-up ip link set wan master br0
    pre-up ip link set lan1 master br0
    pre-up ip link set lan2 master br0
    pre-up ip link set lan3 master br0
    pre-up ip link set lan4 master br0
    pre-up bridge vlan add vid 101 dev wan pvid untagged
    pre-up bridge vlan del vid 1 dev wan
    pre-up ip link set wan up
    pre-up bridge vlan add vid 101 dev lan1 pvid untagged
    pre-up bridge vlan del vid 1 dev lan1
    pre-up ip link set lan1 up
    pre-up bridge vlan add vid 101 dev lan2 pvid untagged
    pre-up bridge vlan del vid 1 dev lan2
    pre-up ip link set lan2 up
    pre-up bridge vlan add vid 101 dev lan3 pvid untagged
    pre-up bridge vlan del vid 1 dev lan3
    pre-up ip link set lan3 up
    pre-up bridge vlan add vid 101 dev lan4 pvid untagged
    pre-up bridge vlan del vid 1 dev lan4
    pre-up ip link set lan4 up
    post-down ip link set lan4 down
    post-down ip link set lan3 down
    post-down ip link set lan2 down
    post-down ip link set lan1 down
    post-down ip link set wan down
    post-down ip link del dev br0
    address 192.168.0.200/24

allow-hotplug wlan0
iface wlan0 inet manual

Just ping-tested yet, but that worked.

[tido-]

Hi hknaack,

I can see several times:

bridge vlan **del** vid 1 dev lan1

I was wondering if there is not a general 'switch' to reset the VLAN, like it was done with SWCONFIG.

(Sorry, can't get code tags to work properly at this late hour)

Just add ``` in front and at the end

By the way, journalctl -f (kind of Tail used to be).
I now receive an IP-Address, wlan0 and 4 x LAN I have not tested yet but NO MORE major error messages. So I will update my Document with the current configuration.

[R1SwitchUser]

Hello, I assume, R1308 is solder in this case to avoid forwarding between local network and wan. But forwarding is set soon, near 5 seconds after kernel is started during initialization. So possible at time your configuration is prepairing, some frames can be forwarded from local network to wan and from wan to local.
Have you checked?
I think, for future we need more access to B53125 register set over DSA. Possible in driver bcm_sf2 is some implemented. Does anyone know, how this works there? Over ethtool, ip, bridge, ... or extended function of them?

[tido-]

can't add wlan0 to bridge br0: Operation not supported

@ffainelli - Networking hardware of R1 comes with: A20, B53 and WLAN over USB-bus.
Usually, a bridge is used to connect two interfaces, but as written above it doesn't work.
What is necessary to add wlan0 to the bridge
bridge vlan add vid 102 dev wlan0 pvid untagged doesn't work either

Does wlan0 need to be attached to an additional VLAN eg. eth0.103 and then this eth0.103 is added to the bridge?
And if so, do you know the commands to get there ?

[dumischbaenger]

@ffainelli wrote

Also, with DSA the bridge is only used as a controlling device for bridge VLAN filtering but it is not necessary to enslave any eth0. interfaces in the bridge these interfaces should remain outside of the bridge.

Can't confirm that. Every time I remove lines like this

ip link set eth0.101 master br0

from my script it does not work any more.

[zador-blood-stained]

@tido-

can't add wlan0 to bridge br0: Operation not supported

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=ad4bb6f8883a13bb0f65b194dae36c62a02ac779

[tido-]

I understand one thing for sure in this commit (get the confirmation): In managed mode you cannot add a wireless interface to the bridge.

I have to admit that I do not understand the possible solution :-(

recently added a four-address mode to the AP and client side that can be used for bridging.

[AntonioTrindade]

I have a working Router/AP running with a LAN bridge on br0.
The wlan0 is added to br0 by hostapd.
NOTE: I do not use the builtin WiFi adapter. I use a TP-Link TP-WN722N plugged in to the external USB port.
Here is my hostapd.conf:

ssid=ARMBIAN
interface=wlan1
hw_mode=g
channel=11
bridge=br0
driver=nl80211
wds_sta=1
logger_syslog=-1
logger_syslog_level=0
wmm_enabled=1
ieee80211n=1
wpa=2
preamble=1
wpa_passphrase=xxx123xxx456
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
auth_algs=1
macaddr_acl=0
noscan=1
ht_capab=[HT40-][SHORT-GI-40][SHORT-GI-40][DSSS_CCK-40]
country_code=PT
ieee80211d=1

[zador-blood-stained]

I have to admit that I do not understand the possible solution :-(

I think you can let hostapd add the interface to the bridge (after it was properly configured as AP) - this way you won't be adding the unconfigured interface to the bridge.

Alternatively you can play with udev rules to enable 4addr extensions

RUN+="/sbin/iw dev $name set 4addr on"

[hknaack]

Last night I finally got hostapd working (it turned out I just had to uncomment the DAEMON_CONF entry in /etc/default/hostapd) and played around with it. In some cases, I had authentication problems, when trying to connect my cell phone. This mainly happened, when I had wlan0 as member of br0 and giving it a vid of 102. One time, I was able to ping my phone via LAN side, but for some reason eth0.101 (the WAN side) didn't get set up. I'm still thinking, how to get to a clean solution. My current questions are:

• let systemd manage hostapd (like currently happening), or move it to /etc/network/interfaces (using ifupdown)
• let hostapd create the bridge or manage it in /etc/network/interfaces
• put wlan0 into the already existing bridge with the same vid as the LAN interfaces or form another bridge with wlan0 and eth0.102 as members, not touching any vid
  Not sure if I will find enough time to test tonight. Feel free to comment.

[tido-]

@AntonioTrindade, do you still use br0 & br1? br1 is not necessary for wan port.
interface=wlan0 bridge=br0
has always been in hostapd, but it does interfere with br0 configuration in interfaces. So I deleted that reference in interfaces.

@hknaack, my current doc isn't ready, but it prevents you from some challenges. And you can add your findings it is in edit mode. Your question:

1. I leave it where it is - so it is for all the same
2. As written above I have it now in hostapd and DSA config-file only.
3. LAN & wlan0 shall be served from the isc-dhcp-server, so I try to keep that simple.
   According to ffainelli keep all interfaces in one Bridge, devide it into VLANs where needed.

[iavael]

@zador-blood-stained

Alternatively you can play with udev rules to enable 4addr extensions
RUN+="/sbin/iw` dev $name set 4addr on"

looks like 8192cu.ko in default armbian's kernel is compiled without cfg80211 support, only wext.

[zador-blood-stained]

looks like 8192cu.ko in default armbian's kernel is compiled without cfg80211 support, only wext.

we are talking about the mainline

[kgara]

https://github.com/armbian/build/issues/511#issuecomment-318868170
Confirm this works on 5.31. Thanks for config.
Now need only correct hostapd/bridging with lan and resistor soldering howto.

[hknaack]

I finally got around to test some new configuration, which is working quite satisfying. I renamed the bridge to manage the Broadcom switch to br53125 and used the original configuration to create another bridge called br0 to bind all LAN side interfaces together. Like before, eth0.101 is used as WAN side interface. So, this is what an example /etc/network/interfaces.r1router can look like:

auto lo
iface lo inet loopback

auto eth0.101
iface eth0.101 inet manual
    pre-up ip link add br53125 type bridge
    pre-up ip link set wan master br53125
    pre-up bridge vlan add vid 101 dev wan pvid untagged
    pre-up bridge vlan del vid 1 dev wan
    pre-up ip link set wan up
    post-down ip link set wan down
    post-down ip link del dev eth0.101

auto eth0.102
iface eth0.102 inet manual
    pre-up ip link set lan1 master br53125
    pre-up ip link set lan2 master br53125
    pre-up ip link set lan3 master br53125
    pre-up ip link set lan4 master br53125
    pre-up bridge vlan add vid 102 dev lan1 pvid untagged
    pre-up bridge vlan del vid 1 dev lan1
    pre-up ip link set lan1 up
    pre-up bridge vlan add vid 102 dev lan2 pvid untagged
    pre-up bridge vlan del vid 1 dev lan2
    pre-up ip link set lan2 up
    pre-up bridge vlan add vid 102 dev lan3 pvid untagged
    pre-up bridge vlan del vid 1 dev lan3
    pre-up ip link set lan3 up
    pre-up bridge vlan add vid 102 dev lan4 pvid untagged
    pre-up bridge vlan del vid 1 dev lan4
    pre-up ip link set lan4 up
    post-down ip link set lan4 down
    post-down ip link set lan3 down
    post-down ip link set lan2 down
    post-down ip link set lan1 down
    post-down ip link del dev br53125
    post-down ip link del dev eth0.102

allow-hotplug wlan0
iface wlan0 inet manual

auto eth0.101
iface eth0.101 inet static
    address 192.168.1.3/24
    gateway 192.168.1.200
    dns-nameservers 192.168.1.200

auto br0
iface br0 inet static
    bridge_ports eth0.102 wlan0
    address 192.168.0.200/24

And these should be the relevant lines in /etc/hostapd.conf:

interface=wlan0
driver=nl80211
bridge=br0

Not sure, if I need to mention this, but if problems still occur, make sure to have enabled ip-forwarding and configured iptables rules properly.

@kgara : I don't really see the point in a resistor soldering howto. The schematic shows, that a 2.2kOhms resistor with a 0402 footprint needs to be used. How to solder SMD components is largely covered in other tutorials, like on Youtube and off-topic in this place.
So far, I haven't added R1308, and am not yet sure, if I will do so.

[tido-]

br53125

So you attach all devices except wlan0 to br53125. Via interfaces you do like we did with SWCONFIG and bring eth0.102 & wlan0 together. Things I see here, that I don't understand:
Why is your eth0.101 not dhcp ?
Why is your driver=nl80211 and not rtl871xdrv

bridge_ports eth0.102 wlan0

As you already bring the wlan0 via hostapd to br0, why do you do that again in interfaces?

I am missing in your configuration these lines:

# ** create the native VLAN **
ip link add link eth0 name eth0.101 type vlan id 101
ip link add link eth0 name eth0.102 type vlan id 102

[hknaack]

So you attach all devices except wlan0 to br53125. Via interfaces you do like we did with SWCONFIG and bring eth0.102 & wlan0 together.

I tried to stay as close as possible to the pre-existing configuration with SWCONFIG. Yet, it is more like putting wan and lan1-lan4 into br53125. As a result, we have traffic from the wan port on eth0.101 and traffic from the lan ports on eth0.102. That is the same as what swconfig did in the past. So then, I bring eth0.102 and wlan0 into a bridge, to be used for all LAN-side traffic.

Why is your eth0.101 not dhcp ?

Because I know my gateway. Don't bother, it should work with DHCP or whatever you need. I tested that last week, when I posted my previous configurations (I called them /etc/network/interfaces.r1DSArouter and /etc/network/interfaces.r1DSAswitch).

Why is your driver=nl80211 and not rtl871xdrv

I always used the mainline driver rtl8192cu, which uses this interface. It works for me.

As you already bring the wlan0 via hostapd to br0, why do you do that again in interfaces?

I was also thinking about that, and the networking service also complains about it a little bit, but there is no harm. Whoever comes first will create the bridge. Yet, this part is from the old configuration, which I wanted to stick to as close as possible. But we could probably drop wlan0 here.

I am missing in your configuration these lines:

# ** create the native VLAN **
ip link add link eth0 name eth0.101 type vlan id 101
ip link add link eth0 name eth0.102 type vlan id 102

ifupdown is smart enough to do that automagically when I declared interfaces eth0.101 and eth0.102. And I also expect it to automatically clean up, when it is done.

[kgara]

https://github.com/armbian/build/issues/511#issuecomment-320473246
Works for me with routing and nat. Yet toooo shity. Wifi even worse then on 3.4 with https://github.com/pritambaral/hostapd-rtl871xdrv
Average ping is 1200 ms, packet loss might reach 50%.
Moreover (what I am most angry), this issue https://github.com/pritambaral/hostapd-rtl871xdrv/issues/20 (that I blamed rtl871xdrv) is still reproduced.
Any ideas? Maybe get some more verbose debug, because everything looks good in logs - except not traffic passes, even dhcp requests. Occasionally, occasionally it's like crappy wifi, but works :)

[AntonioTrindade]

Just tried the configuration written by @hknaack with just a small change instead of two "auto eth0.101" lines, I just use one, like so:

auto eth0.101
iface eth0.101 inet dhcp
    pre-up ip link add br53125 type bridge
    pre-up ip link set wan master br53125
    pre-up bridge vlan add vid 101 dev wan pvid untagged
    pre-up bridge vlan del vid 1 dev wan
    pre-up ip link set wan up
    post-down ip link set wan down
    post-down ip link del dev eth0.101

Works like a charm! :-)

[tido-]

it also works with only one (1) bridge.

[oangelo]

@hknaack, your configuration works great, I can configure dnsmasq and computers can get ip from the lan ports, and I can connect to them by ssh. However, I can't create a pppoe connection. The configuration tool pppoeconf fails. Any idea what must be changed?

[hknaack]

@oangelo I've never used pppoe and don't have such hardware, so no experience from my side. You should remove the second block of eth0.101 configuration (IP/DNS/gateway stuff) and try to use the pppoe tools to manually get a connection established. This way, you should get some debug information.

[oangelo]

@hknaack, I can only establish a pppoe connection on the wan port when using "iface eth0.101 inet auto", however, in this way no bridge is created and the ethernet lan does not work. However, disconecting the cable from wan and connecting in any of the lan ports, I can make a pppoe connection using eth0.102. I don't know enougth of network configuration stuff, and I wonder if It is ok (I mean, as safe as using the wan port) to have my internet conection also using one of the lan ports?

[kgara]

I wonder if It is ok (I mean, as safe as using the wan port) to have my internet conection also using one of the lan ports?

You provoke local guys to flame :) According to local conclusion (no irony, 99% sure that it is so, just lazy to check in lab myself) this etherswitch is unsafe by design at least on boot before kernel boot and ports get mapped to vlans. Anyway you may create as many vlans as you require, literally you may assign one of "lan" ports to other vlan, and create say eth0.103, eth0.104 etc.

[oangelo]

@kgara, I saw the security problem discussion, if the problem is just before kernel boots, I don't really mind because my Lamobo is stable. I am powering it through the battery conector and using some dissipators to prevent over heat, and also did a hardware mod to change the bad original wifi board and also using a very good sd card.

About the configuration, I do not understand why pppoe is not working on the wan port but does works on the lan, I tried some commands but I do not understand much of network configuration...

[kgara]

and also did a hardware mod to change the bad original wifi board

Now this becomes interesting. Can you share the details? :) Maybe we can discuss elsewhere not to flood? Skype? My skype id kvgara.

[ThomasKaiser]

Maybe we can discuss elsewhere not to flood

Why not continuing here? The comment thread is already that absurd that it really doesn't matter any more :)

But if you're interested in this specific 'lamobo r1 hardware mod' every search engine already delivers.

[oangelo]

@kgara, I bought this MT5572 WIFI module that works quite well, the board layout is exactly the same of the original, you just need to desolder and resolder. I saw this solution somewhere at the armbian forum...

[kgara]

The comment thread is already that absurd that it really doesn't matter any more

Idk, thanks to hknaack, tido and AntonioTrindade comments in this thread after you closed it I am now quite satisfied with 4.9.7-sunxi, except of that annoying wifi issue, that might be solved with controller replacement. Anyway thanks for links, will read and order it today.

[oangelo]

I've managed to make a pppoe connection through wan port. I don't know why, but creating a bridge "br1" for the eth0.101 makes pppoe works. I am posting my configuration file case someone needs to use pppoe.

auto lo
iface lo inet loopback

auto eth0.101
iface eth0.101 inet manual 
    pre-up ip link add br53125 type bridge
    pre-up ip link set wan master br53125
    pre-up bridge vlan add vid 101 dev wan pvid untagged
    pre-up bridge vlan del vid 1 dev wan
    pre-up ip link set wan up
    post-down ip link set wan down
    post-down ip link del dev eth0.101

auto eth0.102
iface eth0.102 inet manual
    pre-up ip link set lan1 master br53125
    pre-up ip link set lan2 master br53125
    pre-up ip link set lan3 master br53125
    pre-up ip link set lan4 master br53125
    pre-up bridge vlan add vid 102 dev lan1 pvid untagged
    pre-up bridge vlan del vid 1 dev lan1
    pre-up ip link set lan1 up
    pre-up bridge vlan add vid 102 dev lan2 pvid untagged
    pre-up bridge vlan del vid 1 dev lan2
    pre-up ip link set lan2 up
    pre-up bridge vlan add vid 102 dev lan3 pvid untagged
    pre-up bridge vlan del vid 1 dev lan3
    pre-up ip link set lan3 up
    pre-up bridge vlan add vid 102 dev lan4 pvid untagged
    pre-up bridge vlan del vid 1 dev lan4
    pre-up ip link set lan4 up
    post-down ip link set lan4 down
    post-down ip link set lan3 down
    post-down ip link set lan2 down
    post-down ip link set lan1 down
    post-down ip link del dev br53125
    post-down ip link del dev eth0.102

allow-hotplug wlan0
iface wlan0 inet manual

auto br0
iface br0 inet static
    bridge_ports eth0.102 wlan0
    address 10.0.0.1/24

auto br1
iface br1 inet dhcp 
    bridge_ports eth0.101

auto dsl-provider
iface dsl-provider inet ppp
provider dsl-provider

[titi38]

Hi,

I've just bought a banana BPI-R1 and installed the last image (Ubuntu 16.04) from the website http://www.banana-pi.org/r1-download.html
(2016-07-21-ubuntu-mate-16.04-desktop-armhf-raspberry-pi-bpi-m1-m1p-r1-sd-emmc.img)

It works, but all network interfaces seem to be bond... and I really need to physically separate the ethernet ports in 2 isolated networks (an interface linked to the outside network, and one to the other to my local network.

I have then try to run the armbian Lamobo R1 "Ubuntu server"... but it looks similar.

I haven't find any information. Which image are you using ? I haven't any lanX interface, just eth0, bond0, enx28f36654199e and tunl0 (and I only manage to use eth0...)

Please help ...! Thanks a lot

[ThomasKaiser]

There is the device page and here the support forum where you can discuss such stuff. Good luck!