malvcr

Members
  • Content Count

    106
  • Joined

  • Last visited

About malvcr

  • Rank
    Elite member

Recent Profile Visitors

652 profile views
  1. I am not sure for current versions, but the R2 has a very annoying problem without a clear solution (just some dangerous hacks that I am not very happy to apply). Could be possible to have a different method to power up/power down and to reset the machine? I don't know, maybe some pin headers where be able to add some buttons or something like that. And to have the possibility for power up by default when needed instead of having it off when providing electricity (this last convenient when creating routers or similar networking stuff where the R2 looks promising). In the RACK case from above, I was forced to let the side with buttons near the back border and later I added a plaque with a hole to be able to power up the machine with my fingers ... I am working the machine by myself, but it is complicated to assemble a customer's solution with the current behavior ( press 7 seconds on so small button and to wait for the green light to be continuously on for two seconds ). In fact ... I think that this type of hardware extensions could be useful for any other future SBC. Just think ... some pins for power, reset, power led and hard disk led ...
  2. About the g_ether / g_serial issue. The g_ether it is a very nice option. No networking infrastructure, just a good quality USB data cable ... and you obtain more than fast ethernet throughput. When using g_serial it is very slow (obviously they have different purposes). As you can see in my machine, there are several SBC making a tiny private network. Having g_ether working correctly it is very useful in such scenarios. Anyway, I already have the standard networking equipment there. Maybe in another setup I could try g_ether again, but with latest kernels.
  3. Hi Martin I really prefer the clear and simple things. The GUI tools hide many things and this makes me to be worried about the final results. You know, a tiny detail and then I let a hacker to play with my stuff. I used the Armbian TUI just to check where the things were located, but then I modified the configuration files directly to understand them better. Maybe the big problem with all this (just a comment for not to be far from the R2 context) is that there is no "network framework" to justify any of the tools. They are just incomplete. For example, if I like to create a NAT fortified Router/Firewall, I can't depend on NetworkManager alone and I need to tweak here and there with some iptables rules, some systemctl modifications and to cross my fingers expecting that everything be OK. And when you check on the Internet, there is a big salad of options, many of them "mixing" incompatible things to have a result. Would be wonderful to have a tool where I just describe in almost plain english what I expect. Something like this (light idea, being tired at 11:23 p.m.). eth0 = iface( --ipaddress/netmask:gateway-- ) eth1 = iface( --ipaddress/netmask:gateway-- ) eth2 = iface( --ipaddress/netmask:gateway-- ) public = alias(eth0) dmz = alias(eth1) lan = alias(eth2) webserver = address(10.x.x.x) database = address(192.168.y.z) forward port 80 from public to dmz(webserver) open port 3610 from dmz(webserver) to lan(database) route lan to public(any port) close any other port from public to dmz close any port from public to lan close any other port from dmz to lan Everything together, without surprises. All details covered by the tool. Who knows, maybe I work that some day :-)
  4. Hi Guidol ... I have been doing a loooot of things as the ones you are describing for years by now. However, things are becoming more complex and the solutions are not so crystal clear anymore. When working them with the OPI-Zero, latest Armbian version (no problem in legacy ones), to remove the network managers resulted in so unstable environment that I was forced to reinstall the OS. And ... as Armbian is oriented to NetworkManager, I preferred to learn how to work it. About the R2, what happens is that it is a "work in progress" unsupported device. So you have no guarantees about what could happen if you break something. Also, it is more complex that other machines because it has an exotic networking equipment... in those cases, when it works it is better not to try strange things on it unless it is laboratory hardware (I have other machines for that). The specified instructions work for standard Ubuntu on a very regular machine, but not necessarily will work perfectly in a constrained SBC computer where the OS has been fine-tuned to perform well. --- I would prefer if Armbian let me "choose" what networking method I like to use, and in an orderly way disables all other ones. However, I understand that such thing would involve a lot of work and it is not a priority.
  5. This is a picture with an R2 located in a RACK assembly. The set has an Orange Pi Zero as a "communication/firewall device", together with a Banana Pi M2+ as the Application Server and the Banana Pi R2 (v1) as a Database/NFS/ClamAV server. I am configuring a Moodle on the machine. As a recommendation from TKaiser in a previous post, the R2 it is managing two 2TB hard disks with BTRFS and not RAID1 (really it is smoother and easier to configure than a software RAID). The disks power it is provided directly by the 430W power supply (not the R2 power connectors) ... I know this is as a 12 cylinder engine in a Beetle :-) ... The enclosure has 3 fan, so no machine arrive to 50C degrees. It can be improved. There are details, but in the future things will be better. In this moment only the power led it is attached to something, and the Power Supply has a wire in the CPU connector to "simulate" something there (if not, the Power Supply will not work). The machines are located in a presentation cardboard piece painted with temperature resistance silver paint, as no screw post in the enclosure match the SBC machines holes. They are suspended on the board with metal posts. One if my "nightmares" with this machine has been the internal networking. Basically the old style ifup-ifdown doesn't work. Armbian it is a complex thing because it keeps the ifup-ifdown together with the NetworkManager and the SystemD.NetworkD, all at the same time. So, sometimes you do something but it doesn't work because "the other guy" works against you and you really have no idea what it is happening, and things go wild when working three machines at the same time. At the end, The M2+ and the Zero were configured with NetworkManager and the R2 with SystemD.NetworkD ... in this respect, they are not compatible in the Armbian setup methodology. -- The Zero and the M2+ take their power from the R2 (later I will use the Power Supply directly). I remember when having the legacy 3 kernels and the zero was possible to use the USB cables for networking with the g_ether module. But I never was able to do this to work well with the 4 series kernels. In fact, now Armbian comes loaded with the g_serial instead. Could be interesting to recover that functionality, as this could reduce the complexity with this type of machine combinations. By now, I am relying in the old friend RG45.
  6. There are many changes between 4.14 and 4.19 ... in particular with the mt7530 driver. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/net/dsa/mt7530.h?id2=v4.14.81&id=v4.19.2 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/net/dsa/mt7530.c?id2=v4.14.81&id=v4.19.2 And I saw the tread about the "trick" to make the second interface go up http://forum.banana-pi.org/t/missing-nics-eth2-eth4/4571/15 These days (a little each time, as I am a little busy), let me check how the patch can live with the other changes, to see if it can be applied. Also, as I understand on the BPI forum, that patch can't go to mainline because it is not an official change from the main DSA maintainers that are looking for that type of functionality in the DSA future improvements.
  7. Understood ... then we must make everything to work ... ... When I have a chance, let me check the differences between DSA in 4.14 and 4.19. I have been reading the code but it is not so easy to catch what is not working.
  8. About the mt7623 I know that the DSA requires some extra work. However, this could be done in stages. 1) As it is now, no secondary networking element (this is just a 4 core machine with 2 gb RAM) 2) As the original 4.4.70 BPI kernel. WAN in one side and everybody else in the OTHER one (as a switch) 3) Full DSA with the capacity to separate all 4 ports in the CPU interface and full routing capacity in all 5 ports. 4) Everything and WIFI. 5) USB-OTG networking 6) Whatever the user connect in the PCI port.
  9. Hi ... I must be sincere. Network Manager have been extremely unstable for me when dealing with complex networking configurations. The problems appear because it seems wrong to configure "by hand" things while the NM it is working. Basically, NM doesn't pay attention to your manual definitions (/etc/network/interfaces file) and decides to change things dynamically, breaking your own definitions in any moment. And for that there are only two solutions: Don't do anything by hand (use everything as NM dictates it) ... "this is something I need to learn carefully how to do well". Purge NM, as it can't be 100% disabled (why? ... I really don't know ... you disable it and one or two reboots later it is alive again). NM was designed to deal with complex networking scenarios where things can change. However, it depends how you design your routers and what is their purpose. In a big quantity of opportunities for servers or IoT, you live in a 100% static scenario where NM it is just an extremely complex piece of software for a very easy task. Maybe ... and this is just an opinion ... when installing, could be better to let the user to choose what option to use and not to include the other options in the running environment.
  10. Hi people ... I was trying the nand-sata-install in one of my R2 1.1 ... It seems to work, but I lost my serial console. I was figuring what could be the problem, if the R2 was bricked or something. But just the serial doesn't work anymore (could be an unrelated issue, but it is important to indicate it). So, I supposed it really didn't work ... then I attached an ethernet cable to one of the bridged ports and located the DHCP assigned address to connect there using SSH. It is working from the emmc so the process really it is writing the OS there and the R2 boots without the SD. However, there are differences between 1.1 and 1.2 that must be taken into consideration. In the 1.1 version, there is no switch to choose between emmc or sd; instead there is a connector for a battery. As this is not a very supported bring-up effort, my recommendation it is to forget the 1.1 version. I have it because I was an early adopter, but the second time I purchased cards I received already 1.2 version cards. I am not really aware of what other hidden differences could be between 1.1 and 1.2. My feeling is that will have more headaches in the trip. I will use my 1.1 cards for laboratory and mechanical construction (design and test cases), not for production. And I can do crazy things on the configuration if needed for my specific cases; just that I won't use that version for production or to provide systems to my customers. It is a little risky. -- Frank has a nice 4.14 kernel. It works well and can be used for routing needs. I fully understand about applying minimum things on the Armbian case, as the distribution it is used by a lot of people with many different hardware options. I think that both efforts are important because they will help to understand more machines based on this particular type of SoC. I am still grasping my head with the DSA thing, to see how I can help there, and checking about a modular installation method. And this is Linux, a lot of people helping here and there :-)
  11. There is something strange with the R2 1.1 version (tomorrow I will check with more care, even with a 1.2 one). For checking this I updated the source code and produced a fresh image. Just boot the image and when checking I noticed that the MAC addresses are someway mixed. wan, eth0, lan0, lan1, lan2, lan3 ... all them share the same address. Then, the br0 (bridge?) has the other address. For this type of machines, it is supposed that the "wan" port it is the one is isolated, while the lan ones are the ones sharing the MAC address (this is some type of router machine). So, the wan port must have a different address than the lanX ports.
  12. Let me try ... I have 1.1 and 1.2 version boards. I will check both.
  13. Let me see ... 1) New way ... no NAND support. 2) Priorities ... SD first (if available) others, on demand. Maybe calling "sub-scripts" if extra/different functionality it is required. 3) Normal ... same file system, just raw copy to final storage. As option, and for special cases, new file system rsync or similar. 4) boot partition must work always, although, the particular model can change (now u-boot, later other methods) ... this means, boot must be also a sub-script that can be easily replaced or updated as required. About "extra", "exotic" things as hardware cryptography, as them must be worked in a detailed particular (non generic) way, a chapter for each configuration and customization in the online documentation seems to be enough. The normal method will not use that capacity but a well tested methodology must be available (and the forum it is just a light unstructured reference). To bring-up a new machine, that work it is not required and could be available "later" if it is possible to do so. In the menu case, the interactive method must be the "default", but also some type of "batch" must be available. Could be possible to install from an image but also to re-create the image from an existing installation. Sometimes it is necessary to install many similar machines as pre-configured images.
  14. Thinking on a layered configuration. What could be an Armbian core? ... Maybe basic kernel with file systems and networking? How difficult is to bring only this up on all known machines? How to do it with unknown machines? Is mainline safe enough to play on new devices? The store systems (SATA, SD, EMMC ... etc ... ) must be here, together with the capacity of moving the OS to these types of store. I need hardware cryptography support, but not everybody needs that. The most of the people can have a happy life with software based cryptography. The same goes on with GPIO and some specialized ports. HDMI it is not needed everywhere. Although the R2 has an HDMI port, seldom people will use that machine with a monitor. Several Zero - Level devices lack of a video port because their focus it is not to have a desktop. The same happens with LCD, even with cameras. A NAS and many headless systems don't need many of these elements and can work with a web based setup (as openmediavault, mediawiki or openkm do). And, of course, there is the "desktop", although with the small machines seems to be a specialized desktop because they are not powerful enough to do "everything" a current standard PC usually do. My point is that maybe it is better to figure how the machines could be used instead of trying to resolve 100% problems at once. The comment about HDMI in the R2 Armbian unsupported page it is right; maybe the HDMI never will work well, because really, almost nobody needs an HDMI port in a router, bridge or these types of machines.
  15. This thread seems important on this theme ...