[RfE] Drop support for Lamobo R1 #511
Comments
|
@ThomasKaiser
Idea: |
|
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. |
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. |
@golfromeo-fr I think it's not about you or your plans with R1 or any successor. It's about
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. |
|
@ThomasKaiser @zador-blood-stained |
|
I would not change the current schema because of last events. |
|
IMO we need at least one person 'feeling' responsible for devices like R1 that are
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. |
|
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). |
|
I was referring to not dropping the board.
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. |
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:
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 In case 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 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) |
|
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:
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.
However, I assigned the wan and lan aliases a valid IP, but every ping to my devices on the corresponding port failed. |
|
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). |
|
probably swconfig is no longer needed anymore, maybe "bridge" instead |
|
i've tried to tackle this issue too, but without much success. theoretically it should 'just work', practically it doesnt. script i've used:
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. |
|
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 |
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)? |
|
@ThomasKaiser otoh, would be interesting if adding this eeprom could make it remember the setting |
|
as for the speed, serving file from /tmp: |
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. |
|
previous result was with bpi-m1 as a receiver, this one is using thinkpad t500: |
|
and this one is when serving the file from bpi-m1 to thinkpad t500: |
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 |
|
@ThomasKaiser but remember, this config is somehwat hacky/invalid, also, why not 4.9? also, it's proxy_arp_pvlan, not proxy_arp |
|
@kotc |
|
@zador-blood-stained just wanted to know why sticking to 4.8 when 4.9 is almost baked. |
|
@kotc |
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. |
Why should people look at the download page if they do an |
|
@ffainelli - Networking hardware of R1 comes with: A20, B53 and WLAN over USB-bus. Does wlan0 need to be attached to an additional VLAN eg. eth0.103 and then this eth0.103 is added to the bridge? |
|
@ffainelli wrote
Can't confirm that. Every time I remove lines like this
from my script it does not work any more. |
|
|
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 :-(
|
|
I have a working Router/AP running with a LAN bridge on br0. |
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 |
|
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:
|
|
@AntonioTrindade, do you still use br0 & br1? br1 is not necessary for wan port. has always been in @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:
|
looks like 8192cu.ko in default armbian's kernel is compiled without cfg80211 support, only wext. |
we are talking about the mainline |
|
#511 (comment) |
|
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: And these should be the relevant lines in /etc/hostapd.conf: 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 you attach all devices except wlan0 to br53125. Via
As you already bring the wlan0 via I am missing in your configuration these lines: |
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.
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).
I always used the mainline driver rtl8192cu, which uses this interface. It works for me.
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.
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. |
|
#511 (comment) |
|
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: Works like a charm! :-) |
|
@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 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, 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? |
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, 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... |
Now this becomes interesting. Can you share the details? :) Maybe we can discuss elsewhere not to flood? Skype? My skype id kvgara. |
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. |
|
@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... |
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. |
|
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. |
|
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 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 |
|
There is the device page and here the support forum where you can discuss such stuff. Good luck! |
and others
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
swconfigworks 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-nextbranch as part of the 5.22 update to fix Dirty COW caused again an incompatibility with thisswconfigtool, 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.
The text was updated successfully, but these errors were encountered: