[RfE] Drop support for Lamobo R1 #511

Open
ThomasKaiser opened this Issue Oct 25, 2016 · 109 comments

Projects

None yet
@ThomasKaiser
Collaborator

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
Contributor
golfromeo-fr commented Oct 25, 2016 edited

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

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
Collaborator
zador-blood-stained commented Oct 25, 2016 edited

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
Collaborator
ThomasKaiser commented Oct 25, 2016 edited

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
Contributor

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

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

@ThomasKaiser
Collaborator
ThomasKaiser commented Oct 26, 2016 edited

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 #514 for example) but IMO it's necessary to improve testing/release cycles and get them on board.

@hknaack
hknaack commented Oct 26, 2016

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
Owner
igorpecovnik commented Oct 26, 2016 edited

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
Collaborator
ThomasKaiser commented Oct 26, 2016 edited

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
hknaack commented Nov 1, 2016 edited

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](mii_bus:phy_addr=dsa-0.0:00, irq=-1)
[ 411.366953] Generic PHY dsa-0.0:01: attached PHY driver [Generic PHY](mii_bus:phy_addr=dsa-0.0:01, irq=-1)
[ 411.466962] Generic PHY dsa-0.0:02: attached PHY driver [Generic PHY](mii_bus:phy_addr=dsa-0.0:02, irq=-1)
[ 411.567005] Generic PHY dsa-0.0:03: attached PHY driver [Generic PHY](mii_bus:phy_addr=dsa-0.0:03, irq=-1)
[ 411.667091] Generic PHY dsa-0.0:04: attached PHY driver [Generic PHY](mii_bus:phy_addr=dsa-0.0:04, irq=-1)
[ 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
Collaborator
ThomasKaiser commented Nov 1, 2016 edited

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
Contributor
golfromeo-fr commented Nov 2, 2016 edited

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

@kotc
kotc commented Nov 2, 2016 edited

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
kotc commented Nov 2, 2016 edited

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
Collaborator
ThomasKaiser commented Nov 2, 2016 edited

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
kotc commented Nov 2, 2016

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

@kotc
kotc commented Nov 2, 2016 edited

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](receiver is bpi-m1)

@zador-blood-stained
Collaborator
zador-blood-stained commented Nov 2, 2016 edited

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
kotc commented Nov 2, 2016

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
kotc commented Nov 2, 2016

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
Collaborator
ThomasKaiser commented Nov 2, 2016 edited

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
kotc commented Nov 2, 2016

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

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

@kotc
kotc commented Nov 2, 2016

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

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

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
Collaborator

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
Owner

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
Collaborator

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
kotc commented Nov 2, 2016

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
Collaborator

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

Done: 077a3dd. At least compilation still works.

@zador-blood-stained
Collaborator

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
Owner
igorpecovnik commented Nov 2, 2016 edited

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

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
kotc commented Nov 2, 2016

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

@kotc

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

@kotc
kotc commented Nov 2, 2016

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

@zador-blood-stained
Collaborator

@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
kotc commented Nov 2, 2016

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

@kotc
kotc commented Nov 2, 2016

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

@kotc
kotc commented Nov 2, 2016

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
Collaborator

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
hknaack commented Nov 3, 2016

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
kotc commented Nov 3, 2016

@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
kotc commented Nov 3, 2016

@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
kotc commented Nov 3, 2016

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

@zador-blood-stained
Collaborator

@kotc
Thanks for testing 😄

@hknaack
hknaack commented Nov 5, 2016 edited

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

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
kotc commented Nov 5, 2016

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

@igorpecovnik
Owner
igorpecovnik commented Nov 5, 2016 edited

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
hknaack commented Nov 5, 2016

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
typingArtist commented Nov 5, 2016 edited

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
Contributor
golfromeo-fr commented Nov 6, 2016 edited

@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
Owner
igorpecovnik commented Nov 6, 2016 edited

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
Collaborator
zador-blood-stained commented Nov 6, 2016 edited

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
hknaack commented Nov 6, 2016

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
kotc commented Nov 8, 2016

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

@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
hknaack commented Nov 9, 2016

@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
kotc commented Nov 9, 2016

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
Owner

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
Collaborator

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
hknaack commented Nov 9, 2016

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
kotc commented Nov 10, 2016

@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
Contributor
faddat commented Nov 20, 2016

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

@hknaack
hknaack commented Nov 23, 2016 edited

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
Collaborator

@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
Contributor
faddat commented Nov 24, 2016

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

@faddat
Contributor
faddat commented Nov 24, 2016

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
Collaborator

@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
Contributor
faddat commented Nov 24, 2016
@oleg-krv
oleg-krv commented Dec 5, 2016 edited

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
oleg-krv commented Dec 5, 2016

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
hknaack commented Dec 5, 2016

@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
oleg-krv commented Dec 6, 2016

Build image Lamobo dev with #255 (comment) - 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
oleg-krv commented Dec 6, 2016 edited

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

@oleg-krv
oleg-krv commented Dec 6, 2016 edited

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

@hknaack
hknaack commented Dec 9, 2016

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
Collaborator
zador-blood-stained commented Dec 12, 2016 edited

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
hknaack commented Dec 12, 2016

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
wiesl commented Dec 24, 2016

@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
wiesl commented Dec 24, 2016 edited

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](mii_bus:phy_addr=dsa-0.0:00, irq=-1)
Generic PHY dsa-0.0:01: attached PHY driver [Generic PHY](mii_bus:phy_addr=dsa-0.0:01, irq=-1)
Generic PHY dsa-0.0:02: attached PHY driver [Generic PHY](mii_bus:phy_addr=dsa-0.0:02, irq=-1)
Generic PHY dsa-0.0:03: attached PHY driver [Generic PHY](mii_bus:phy_addr=dsa-0.0:03, irq=-1)
Generic PHY dsa-0.0:04: attached PHY driver [Generic PHY](mii_bus:phy_addr=dsa-0.0:04, irq=-1)
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
wiesl commented Dec 24, 2016

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
wiesl commented Dec 29, 2016 edited

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
wiesl commented Dec 29, 2016 edited
# ================================================================================================================================================================
# 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
ruyrybeyro commented Jan 2, 2017 edited

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

@zador-blood-stained
Collaborator
zador-blood-stained commented Jan 8, 2017 edited

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
Collaborator

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

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
Collaborator

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment