New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RfE] Drop support for Lamobo R1 #511

Closed
ThomasKaiser opened this Issue Oct 25, 2016 · 220 comments

Comments

Projects
None yet
@ThomasKaiser
Member

ThomasKaiser commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@golfromeo-fr

golfromeo-fr Oct 25, 2016

Contributor

@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

Contributor

golfromeo-fr commented Oct 25, 2016

@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 comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Oct 25, 2016

Member

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.

Member

zador-blood-stained commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Oct 25, 2016

Member

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.

Member

zador-blood-stained commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Oct 25, 2016

Member

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.

Member

ThomasKaiser commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@golfromeo-fr

golfromeo-fr Oct 25, 2016

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.

Contributor

golfromeo-fr commented Oct 25, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@igorpecovnik

igorpecovnik Oct 26, 2016

Member

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

Member

igorpecovnik commented Oct 26, 2016

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

@ThomasKaiser

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Oct 26, 2016

Member

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.

Member

ThomasKaiser commented Oct 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hknaack

hknaack 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).

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

This comment has been minimized.

Show comment
Hide comment
@igorpecovnik

igorpecovnik Oct 26, 2016

Member

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.

Member

igorpecovnik commented Oct 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Oct 26, 2016

Member

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)

Member

ThomasKaiser commented Oct 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hknaack

hknaack Nov 1, 2016

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.

hknaack commented Nov 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Nov 1, 2016

Member

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

Member

ThomasKaiser commented Nov 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@golfromeo-fr

golfromeo-fr Nov 2, 2016

Contributor

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

Contributor

golfromeo-fr commented Nov 2, 2016

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

@kotc

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc Nov 2, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc Nov 2, 2016

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

kotc commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Nov 2, 2016

Member

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

Member

ThomasKaiser commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc Nov 2, 2016

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

kotc commented Nov 2, 2016

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

@kotc

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc Nov 2, 2016

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)

kotc commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Nov 2, 2016

Member

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.

Member

zador-blood-stained commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc 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 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

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc 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]

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Nov 2, 2016

Member

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)

Member

ThomasKaiser commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc 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

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Nov 2, 2016

Member

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

Member

zador-blood-stained commented Nov 2, 2016

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

@kotc

This comment has been minimized.

Show comment
Hide comment
@kotc

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

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Nov 2, 2016

Member

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

Member

zador-blood-stained commented Nov 2, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@igorpecovnik

igorpecovnik Nov 2, 2016

Member

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.

Member

igorpecovnik commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Nov 2, 2016

Member

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.

Member

ThomasKaiser commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@igorpecovnik

igorpecovnik Nov 2, 2016

Member

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?

Member

igorpecovnik commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Nov 2, 2016

Member

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.

Member

ThomasKaiser commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc 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

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Nov 2, 2016

Member

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

Done: 077a3dd. At least compilation still works.

Member

zador-blood-stained commented Nov 2, 2016

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

Done: 077a3dd. At least compilation still works.

@zador-blood-stained

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Nov 2, 2016

Member

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.

Member

zador-blood-stained commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@igorpecovnik

igorpecovnik Nov 2, 2016

Member

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

Member

igorpecovnik commented Nov 2, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Nov 2, 2016

Member

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.

Member

zador-blood-stained commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc 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

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Nov 2, 2016

Member

@kotc

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

Member

zador-blood-stained commented Nov 2, 2016

@kotc

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

@kotc

This comment has been minimized.

Show comment
Hide comment
@kotc

kotc Nov 2, 2016

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

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

@tido-

This comment has been minimized.

Show comment
Hide comment
@tido-

tido- Jul 28, 2017

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 ?

tido- commented Jul 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Jul 28, 2017

Member

I searched here:
linux-sun8i-default.config

Why? 😄

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
➜  ~  %
Member

zador-blood-stained commented Jul 28, 2017

I searched here:
linux-sun8i-default.config

Why? 😄

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Jul 28, 2017

Member

Also we are talking about CONFIG_BRIDGE_VLAN_FILTERING

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

zador-blood-stained commented Jul 28, 2017

Also we are talking about CONFIG_BRIDGE_VLAN_FILTERING

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

This comment has been minimized.

Show comment
Hide comment
@tido-

tido- Jul 28, 2017

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 

tido- commented Jul 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Jul 28, 2017

Member

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

Member

zador-blood-stained commented Jul 28, 2017

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-

This comment has been minimized.

Show comment
Hide comment
@tido-

tido- Jul 29, 2017

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 🥇

tido- commented Jul 29, 2017

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 🥇

@ffainelli

This comment has been minimized.

Show comment
Hide comment
@ffainelli

ffainelli Jul 29, 2017

ffainelli commented Jul 29, 2017

@hknaack

This comment has been minimized.

Show comment
Hide comment
@hknaack

hknaack Jul 30, 2017

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:

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:

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.

hknaack commented Jul 30, 2017

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:

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:

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-

This comment has been minimized.

Show comment
Hide comment
@tido-

tido- Jul 30, 2017

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.

tido- commented Jul 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@R1SwitchUser

R1SwitchUser Jul 30, 2017

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?

R1SwitchUser commented Jul 30, 2017

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-

This comment has been minimized.

Show comment
Hide comment
@tido-

tido- Jul 31, 2017

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 ?

tido- commented Jul 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dumischbaenger

dumischbaenger Aug 1, 2017

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

dumischbaenger commented Aug 1, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@tido-

This comment has been minimized.

Show comment
Hide comment
@tido-

tido- Aug 1, 2017

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.

tido- commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@AntonioTrindade

AntonioTrindade Aug 1, 2017

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

AntonioTrindade commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Aug 1, 2017

Member

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"
Member

zador-blood-stained commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@hknaack

hknaack Aug 1, 2017

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.

hknaack commented Aug 1, 2017

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-

This comment has been minimized.

Show comment
Hide comment
@tido-

tido- Aug 1, 2017

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

tido- commented Aug 1, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@iavael

iavael Aug 1, 2017

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

iavael commented Aug 1, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@zador-blood-stained

zador-blood-stained Aug 1, 2017

Member

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

we are talking about the mainline

Member

zador-blood-stained commented Aug 1, 2017

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

we are talking about the mainline

@kgara

This comment has been minimized.

Show comment
Hide comment
@kgara

kgara Aug 2, 2017

#511 (comment)
Confirm this works on 5.31. Thanks for config.
Now need only correct hostapd/bridging with lan and resistor soldering howto.

kgara commented Aug 2, 2017

#511 (comment)
Confirm this works on 5.31. Thanks for config.
Now need only correct hostapd/bridging with lan and resistor soldering howto.

@hknaack

This comment has been minimized.

Show comment
Hide comment
@hknaack

hknaack Aug 5, 2017

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.

hknaack commented Aug 5, 2017

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-

This comment has been minimized.

Show comment
Hide comment
@tido-

tido- Aug 6, 2017

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

tido- commented Aug 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@hknaack

hknaack Aug 6, 2017

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.

hknaack commented Aug 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kgara

kgara Aug 7, 2017

#511 (comment)
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 pritambaral/hostapd-rtl871xdrv#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 :)

kgara commented Aug 7, 2017

#511 (comment)
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 pritambaral/hostapd-rtl871xdrv#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

This comment has been minimized.

Show comment
Hide comment
@AntonioTrindade

AntonioTrindade Aug 7, 2017

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! :-)

AntonioTrindade commented Aug 7, 2017

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-

This comment has been minimized.

Show comment
Hide comment

tido- commented Aug 7, 2017

@oangelo

This comment has been minimized.

Show comment
Hide comment
@oangelo

oangelo Sep 11, 2017

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

oangelo commented Sep 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@hknaack

hknaack Sep 11, 2017

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

hknaack commented Sep 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@oangelo

oangelo Sep 12, 2017

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

oangelo commented Sep 12, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kgara

kgara Sep 13, 2017

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.

kgara commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@oangelo

oangelo Sep 13, 2017

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

oangelo commented Sep 13, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kgara

kgara Sep 13, 2017

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.

kgara commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Sep 13, 2017

Member

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.

Member

ThomasKaiser commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@oangelo

oangelo Sep 13, 2017

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

oangelo commented Sep 13, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kgara

kgara Sep 13, 2017

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.

kgara commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@oangelo

oangelo Sep 15, 2017

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

oangelo commented Sep 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@titi38

titi38 Dec 7, 2017

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

titi38 commented Dec 7, 2017

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

@armbian armbian locked and limited conversation to collaborators Dec 7, 2017

@ThomasKaiser

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Dec 7, 2017

Member

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

Member

ThomasKaiser commented Dec 7, 2017

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

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