Wolf2000

I ran into the same issue after updating the kernel. Florian Fainelli told me, that with newer kernels, we need to specify "vlan_filtering 1" during creation of the bridge. Otherwise all the switch ports may end up in dumb switch mode (no separation between WAN and LAN ports). The only problem, when still on Debian Jessie: the ip command doesn't accept this option. So, I ended up upgrading from Jessie to Stretch. Here are the steps starting from the bricked device via serial console:
 
Jessie with too new kernel (4.19)
remove bound IPs (LAN: 192.168.0.20, WAN: 192.168.1.3)from bridge
root@lamobo:~# bridge vlan show port vlan ids wlan0 1 PVID Egress Untagged eth0.102 1 PVID Egress Untagged br0 1 PVID Egress Untagged root@lamobo:~# ip addr show 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group defa0 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global mngtmpaddr dynamic valid_lft forever preferred_lft forever inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever 12: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group0 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.0.20/24 brd 192.168.0.255 scope global br0 valid_lft forever preferred_lft forever inet 192.168.1.3/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever root@lamobo:~# ip addr del 192.168.0.20/24 dev br0 root@lamobo:~# ip addr del 192.168.1.3/24 dev br0 assign desired IP to eth0 (since switch is in unconfigured mode)
 
root@lamobo:~# ip addr add 192.168.0.20/24 dev eth0 root@lamobo:~# ping 192.168.0.200 PING 192.168.0.200 (192.168.0.200) 56(84) bytes of data. 64 bytes from 192.168.0.200: icmp_seq=1 ttl=64 time=0.701 ms root@lamobo:~# route add default gw 192.168.0.200 root@lamobo:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=25.7 ms Follow the Debian Distribution Upgrade Guide
change in /etc/apt/preferences.d/90-backports.pref instances of "jessie" to "stretch" change in /etc/apt/sources.list.d/armbian.list and /etc/apt/sources.list instances of "jessie" to "stretch" root@lamobo:/home/mbs# apt-get update root@lamobo:/home/mbs# apt-get dist-upgrade put new DSA compatible /etc/network/interfaces in place (change "pre-up ip link add br53125 type bridge" to "pre-up ip link add br53125 type bridge vlan_filtering 1" ) reboot  
When using a fresh downloaded image, a properly configured /etc/network/interfaces file also containing "vlan_filtering 1" works as well, but I had some issues to get hostapd running. First off, the wifi interface name changed from wlan0 to wl<mac-address>. Besides, I had some problems with blocked radio. It seems, uninstalling network-manager helps (I don't see a reason to have network-manager on a router). Otherwise, the rfkill tool helps in resolving this issue.

Great job that you tried to do this.  As you can see there are still a lot of obvious problems and mainline is not yet useful on this board. Not even for simple cases since its lack of network support. Wens made progress on this, so you can try even more complex job by adding few of those patches to userpatches/kernel/sunxi-next and recompile the kernel. Monitor debug/patching, adjust patches if necessary ... Patch is downloaded from Github by adding .patch to the commit URL, for example:
https://github.com/wens/linux/commit/48f1bef6c0b43defca07edd4d6e1962f272fe9d6.patch Have fun!

@tkaiser
 
Can it be that you are really allergic to bananas? Imagine that quite a lot of people eat the bananas - even the light brown 
 
Gruß

Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
Basics:
It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

Illustration 1: AWG print on cable
Example:
If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
*this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
 
Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

Figure 2: Voltage drop of a copper cable at various thiknesses
If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
 
Case Study:
Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

Illustration 2: Setup vor measurement
FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
Table 1: Specification of the tested chargers

Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
Table 2: Tested micro USB cables

Results:
After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

Figure 3: Voltage drop at delivered current of all chargers
Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

Figure 4: Voltage without load, with load and on output and @powerbank
.
Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
Conclusion:
What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

Illustration 3: Recommended powersource
 
 

Stimme ich vollkommen zu !
 
@tkaiser
Oh come the junk with the SD card and power supply it is certainly not !!!!!
And that does not solve the problem.  It ran for over a year and now the cable or SD card is defective and in two cases at the same time? This is a no go
 

Any of you have such a beautiful problem?
They like Orange Pi's, they are hot !
 
 
 
 

Well i know some of u like to watch data .....
 
Came allong this git, and is pritty awesome 2
 
check it out here: http://netdata.firehol.org/
 
Worx fine on a bana-armbian (if moderators dont like gifs just remove it np)
 

 
 
Edit: tweaks for embedded devices
Running netdata in embedded devices
Embedded devices usually have very limited RAM resources available.
There are 2 settings for you to tweak:
update every, which controls the data collection frequency
history, which controls the size of the database in RAM
By default update every = 1 and history = 3600. This gives you an hour of data with per second updates.
If you set update every = 2 and history = 1800, you will still have an hour of data, but collected once every 2 seconds. This will cut in half both CPU and RAM resources consumed by netdata.
You can also disable plugins you don't need. Disabling the plugins will also free both CPU and RAM resources.

Hi
apt-get install tightvncserver

My little motd
░█▀▀░▄▀▄░█░█░█▀▀░█▀▀░▀▀█░█▀▀░█▀▄░█▀█░█░█ ░▀▀█░█\█░█░█░█▀▀░█▀▀░▄▀░░█▀▀░█▀▄░█░█░▄▀▄ ░▀▀▀░░▀\░▀▀▀░▀▀▀░▀▀▀░▀▀▀░▀▀▀░▀▀░░▀▀▀░▀░▀ Welcome to Debian GNU/Linux 8.2 (jessie) (Kernel Version: 4.3.3-sunxi). ï¼³ï½™ï½“ï½”ï½…ï½ ï¼©ï½Žï½†ï½ï½’ï½ï½ï½”ｉï½ï½Ž System load: 0.49 Memory usage: 97.2% Usage on root: 66% Usage on hdd: 62% S.M.A.R.T: OK Swap usage: 0.0% Processes: 108 IP: 10.0.0.53 CPU: 34.1°C HDD: 31°C ï¼³ï½™ï½“ï½”ï½…ï½ ï¼µï½ï½„ï½ï½”ｅｓ 1 updates to install. 0 are security updates. 0 npm updates to install. 0 pip updates to install. ï¼³ï½™ï½“ï½”ï½…ï½ ï¼³ï½…ï½’ï½–ï½‰ï½ƒï½…ï½“ squeezeboxserver: # syncthing: # mysql: # ï¼³ï½™ï½“ï½”ï½…ï½ ï¼¬ï½ï½‡ï½“ [Mon Jan 11 11:15:13 2016] sun7i-dwmac 1c50000.ethernet eth0: Link is Down [Mon Jan 11 11:15:36 2016] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx ï¼³ï½™ï½“ï½”ï½…ï½ ï¼µï½ï½”ｉï½ï½… Current 15 days, 10:29:54 | Linux 4.3.3-sunxi Wed Dec 30 12:01:13 2015 Total 24 days, 01:21:30 | since Sun Dec 20 00:41:11 2015 the squeezebox and syncthing are color coded so that the hashtag displays red if its down and green if its up

yes thanks!
 
from nickcharlton
sudo chmod +x /etc/update-motd.d/ seems enough to work with my config
 
 
 

Thank you Wildcat_paris - but I chat with TK already a couple of months - I know he is not perfect.

This is not RTFM this would have been: I have written many notes inside the  sunxi-temp-daemon.sh
So the information is spread somewhere between this thread and the .sh  - and you do not mention this in the first posting here.
This is the reason that I wrote a user manual - because the information in the forum is scattered and it is not useful.
 
 
For SATA HDD 
In case you receive no HDD temperature, make sure you have necessary software installed:
apt-get install hddtemp smartmontools
do a reboot not to waste time, just in case
Then perform:  sudo update-smart-drivedb if you receive an error message, update this line:

nano /usr/sbin/update-smart-drivedb SRCEXPR='http://sourceforge.net/p/smartmontools/code/HEAD/tree/$location/smartmontools/drivedb.h?format=raw'  Then try again:  sudo update-smart-drivedb
Restart the the RPi-Monitor and test it:
service rpimonitor stop pkill -f '/bin/bash /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh' nohup /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh & service rpimonitor start  
Does it work - finished,   if not:
smartctl -a /dev/sda  (look for temperature value) hddtemp --debug /dev/sda hddtemp -n /dev/sda fix it for yourself, read here this worked for me   
I hope this is of any help for you

An alternative for isc-dhcp on Page 9,
written from Ashok Aiyar, I put it here because it is not just a fix but an instruction how to replace the isc-dhcp server with dnsmasq.
 
 
I find dnsmasq to be a better option to isc-dhcp-server, because it provides both DNS and DHCP servers in a single package and configuration file.
Also, dnsmasq supports caching, so with a large cache, it provides really fast name resolution after using it for a little while.
 
Here is a dnsmasq setup consistent with the rest of the Armbian BPi R1 configuration given in this very helpful guide.
 
a) Install dnsmasq (apt-get install dnsmasq)
 
b  shutdown dnsmasq (service dnsmasq stop)
 
c) Edit "/etc/dnsmasq.d/dnsmasq.conf" with the contents shown below:
 


# interfaces
interface=br0
no-dhcp-interface=eth0.101
#
# DNS configuration
min-port=4096
cache-size=10000
local-ttl=3600
neg-ttl=3600
bogus-priv
domain-needed
expand-hosts
resolv-file=/etc/resolv.conf
#
# DHCP configuration
dhcp-authoritative
dhcp-leasefile=/var/lib/misc/dnsmasq.leases
dhcp-option=br0,1,255.255.255.0
dhcp-option=br0,3,192.168.9.2
dhcp-option=br0,6,192.168.9.2
dhcp-option=br0,28,192.168.9.255
dhcp-range=br0,192.168.9.150,192.168.9.250,255.255.255.0,72h
# explanation of options:
# option 1 = net mask
# option 3 = gateway
# option 6 = DNS
# option 28 = broadcast address
# assign address range = 150-250
# lease time = 3 day (72h)


d) shutdown isc-dhcp-server (service isc-dhcp-server stop)
 
e) start dnsmasq (service dnsmasq start)
 
f) confirm that IP assignment is working and that you are making use of the caching nameserver within dnsmasq
 
g) If it works, then remove isc-dhcp-server (apt-get remove isc-dhcp-server)
 
 
Thank you Ashok for your contribution 

I posted a git issue for the Banana Pi image that the mainline kernel wasn't working with OpenMediaVault (at the time I think it was 3.19.3 or .4). It is now working with mainline 3.19.7 so all is resolved. Will release an openmediavault image when I find the time