malvcr

Members
  • Content count

    64
  • Joined

  • Last visited

About malvcr

  • Rank
    Advanced Member

Recent Profile Visitors

338 profile views
  1. malvcr

    Orange Pi PC 1-Wire

    I will be sincere ... after weeks trying to make the DS1961S to work on an SBC and having partial results, I gave up with this. Now I have an almost completely functional prototype working with an Arduino that it is connected to the SBC. What I think is that the logic behind a security device, as the DS1961S it is not a good candidate to work as a driver, neither to use through the OneWire basic Linux interface. It seems that the Linux basic driver it is very unstable for that. As the Arduino it is an almost "naked" device, it is easier to control that OneWire device in a more precise way, having the opportunity to create more complex usages with less effort than trying to do everything directly with the SBC. Maybe, in the future, I could try again to use directly an SBC, as the Orange. Let's see how this thing evolve --- and --- although everything can be done directly with an SBC with Linux, sometimes there are better methods to achieve the expected goals.
  2. malvcr

    Orange Pi PC 1-Wire

    My mistake .... the ds1961s it is completely different to the standard eeprom iButton devices because the way the memory it is used, restricted by "secrets". This happens because it is a security enhanced device. What I am doing now it is to have it "naked" and to work with the "rw" raw data access facility and no particular kernel module. Something else it is important. I can't use 4.7K resistors but 2.2K ones, because the device has different electricity needs than the temperature sensors. So, before trying to apply any other 1-Wire device, check carefully the particular information before becoming crazy :-) ... My only definitions, by now are in the /boot/armbEnv.txt file: overlays=w1-gpio param_w1_pin=PA20 : this is not for an Orange but for a Banana Pi, but the idea is the same (just the GPIO are not 100% compatible as described by TKaiser):
  3. malvcr

    Orange Pi PC 1-Wire

    Just, in case somebody have the same problem I am working with. This thread name is "Orange Pi PC 1-Wire" ... but really it must be "Temperature sensors on Armbian using 1-Wire". I have been working with Bananas, Oranges, Raspberry and even Arduino devices using 1-Wire iButton devices for authentication procedures. In the Arduino world that part is "almost" ready, but in the Linux world (including Armbian) it is not a complete story. Trying to have a complete scenario to work with, I have been checking the 18b20 case, being a well documented one in Linux. However, in real life, this is very different than the ds1961s iButton I am working with now. For example, the thread indicates that the w1_therm must be loaded, but that driver "only" recognizes the temperature 1-wire devices. For the others, a different driver must be loaded. These are the currently included 1-Wire drivers in the 4.4.18 Kernel: ( w1_ds2405 - "Driver for 1-wire Dallas DS2405 PIO." w1_ds2406 - "w1 family 12 driver for DS2406 2 Pin IO" w1_ds2408 - "w1 family 29 driver for DS2408 8 Pin IO" w1_ds2413 - "w1 family 3a driver for DS2413 2 Pin IO" w1_ds2423 - "w1 family 1d driver for DS2423, 4 counters and 4kb ram" w1_ds2431 - "w1 family 2d driver for DS2431, 1kb EEPROM" w1_ds2433 - "w1 family 23 driver for DS2433, 4kb EEPROM" w1_ds2438 - "1-wire driver for Maxim/Dallas DS2438 Smart Battery Monitor" w1_ds2760 - "1-wire Driver Dallas 2760 battery monitor chip" w1_ds2780 - "1-wire Driver for Maxim/Dallas DS2780 Stand-Alone Fuel Gauge IC" w1_ds2781 - "1-wire Driver for Maxim/Dallas DS2781 Stand-Alone Fuel Gauge IC" w1_ds2805 - "w1 family 0d driver for DS2805, 1kb EEPROM" w1_ds28e04 - "w1 family 1C driver for DS28E04, 4kb EEPROM and PIO" w1_smem - "Driver for 1-wire Dallas network protocol, 64bit memory family." w1_therm - "Driver for 1-wire Dallas network protocol, temperature family." ) On 4.16.rc1 only the w1_ds28e17.c ("w1 family 19 driver for DS28E17, 1-wire to I2C master bridge") is extra included. So ... in my case, no family 33 ( ds2432 - ds1961s) is ready to use, so I would need to choose the most similar one and derive my own kernel driver from that. The ds1961s is an iButton with 1Kb EEPROM and SHA-1 Engine, "maybe" similar to the ds2431 (family 2d in the storage part). For extra information about 1-Wire families, check this : http://owfs.sourceforge.net/family.html And ... why ds1961s? ... Well, it has "advanced" characteristics that help me to develop very difficult to copy hardware key devices, that can't be worked with temperature devices or with the simple ds1990a iButton (family 1 ... neither supported natively in Linux).
  4. malvcr

    Orange Pi 2G-IOT

    mm ... I made another installation ... it is working now. Forget the "wireless-power off" in the wpa_supplicant.conf file. That made the problem. Also, I included some Debian repositories and now I am able to install software (although it is better not to abuse because of the lack of space and the own NAND nature of it). root@DietPi:/etc/apt# cat sources.list deb http://ftp.us.debian.org/debian jessie main contrib non-free deb-src http://ftp.us.debian.org/debian jessie main contrib non-free And now, I am trying to convert this in an Access Point. It is totally configured and it says that it is working, but nobody can see the machine outside (so, obviously it is not working). I will try this for a while to provide my impressions about this possible usage for the machine.
  5. malvcr

    Orange Pi 2G-IOT

    This is the article Link with references (this includes the link for the download) ... https://surfero.blogspot.com.es/2017/09/orange-pi-iot-2g-flashear-memoria-nand.html just in case, the download it is in https://mega.nz/#!BFcmiTpL!29AQt7E1odjNUaFV4JNXN8KnVM2dPSocf77EP8uFnPo I was nuts trying to make this to work and then I checked the boot setup ... oh .. 921600 ... my minicom was 115200. Then I was trying to change the boot to 115200, but as that image it is not "common", was a little risky to do that. Then, I changed the minicom to 921600 pressing the next button in the configuration. Now ... login perfect in the console :-) ... and ... WIFI was working around 10 times faster. But then, I did something and now it is impossible for the WIFI to complete the authentication phase with the Access Point (I have been fighting with this for a while with mixed, but all bad results). Then, I connected an ethernet dongle to the USB port and it works very well with an eth0 static address. In general, what I think is that the serial console overruns (in the thousands) with the only core the machine has caused a terrible side effect in the networking stack. It seems that also it is necessary to add "wireless-power off" as the last like in the wlan0 configuration (interfaces file) ... but right now I can't ensure this is a key factor because my WIFI it is not working well. A possible reason for the failure is that the machine always produce a different MAC address, and to declare a manual one with the "hwaddress ether" command in the interfaces definition makes some type of noise when the machine makes the handshaking with the access point ... again, something to be checked. An extra detail. When flashing the machine it is necessary to press and to "keep pressed" the button until the flash has been finished. And in all the process no SD card it is needed, eliminating the original requirement of having strange and difficult to find 8GB SD cards with low consumption requirements. After the machine it is operational, regular SD cards can be used; I even added a 2GB swap file in a 16GB SanDisk card with no problems (of course this won't be fast, but it will permit to me to run more programs on the little 256MB space). -- OK ... my next test, one of these days, will be to use something more complete than DietPi on the NAND, at least the booting component. It is OK to have the remaining in an SD card if the card it is recognized after booting it. :-)
  6. malvcr

    Orange Pi 2G-IOT

    Hi Surfero75 ... I made another attempt with the machine. With your image (based on DietPi that it is based on Armbian), it is possible to boot from the machine internal storage and then to add a 16GB SD card, and the machine will read it. That it is nice :-) ... However, WIFI continues being an issue. I changed the WPA_Supplicant from GB to US and reduced problemas a little, but continue freezing and restarting. Also, it is difficult to login in a TTL console. I can write the user but after writing the password nothing happens ... although this could be a software more than a hardware problem. And your image it is incomplete (I understand was necessary to erase things to write it in the machine space, but some things are not there even when having references ... maybe DietPi was not a good option to work with; it is better a plain Armbian). But good work ... this brings some hopes on the machine :-)
  7. malvcr

    BPI-R2 Board Bring-up

    It is good to know that the R2 it is being taken seriously. This machine has important things and, although there are very good alternatives, it has a market place. I have been sending maybe 100 times by now an 825 megabytes ubuntu iso file from one R2 to another and between an R2 and a Mac Mini machine, testing different types of configurations (in the while I am creating the system I will use the R2 for). Here there have some numbers that could be useful: (AES 256 bit): without /dev/crypto 100% CPU max - real 0m53.189s - user 0m44.210s - sys 0m8.030s with /dev/crypto 75% CPU max - real 0m27.015s - user 0m2.290s - sys 0m17.750s Checking at this test alone, it is clear that with the cryptodev driver active (and with the right openssl compiled for it), the machine it is faster processing. And then it is the top 100% capacity when using only the CPU ... I was trying to figure how to test that remaining 25% ... so, I made a multithread program that received the data (running in a R2), and executed 4 parallel sets of openssl+sending data from the other R2. The "general "throughput" for all the "bundle" gives around 45.8 MB/s. This is much higher than the around 17 MB/s I can have with only one similar session. The issue here is that the final speed can't be calculated only taking into consideration the crypto engine. A final test would need software designed for this, because when I cypher with openssl and then send the file on ethernet, I need to "write" the file to disk and to re-read it, and the DISK is a key factor on the overall transmission speed. An extra write is really heavy here. So, if I like to see a wonderful speed without sacrificing the machine, the disk must speed up. The final numbers for secure transmission of data must involve all the key factors : CRYPTO+DISK+NET+CPU. But ... in general, I think it is good enough for my purposes. When I have a better software platform to test all together (without punishing any of the factors), I will come to show my numbers.
  8. malvcr

    BPI-R2 Board Bring-up

    Making some tests ... rsync uses ssh or rsh (that for some reason it is worse) ... openssl with cryptodev it is fast on big files. There is no rcp (was replaced by scp that is part of ssh set). Then ssh it is in many important places in a regular distribution. I still must make more precise tests, but sending a file with ssh was around 3 minutes ... but encrypting it with openssl (aes - 256) took around 37 seconds and transmitting it with a simple perl script around 12 seconds. I know I can do better by saving one disk reading in the processing phase by moving to C or C++. But this shows that it is possible to obtain more from this machine without using the "normal" options.
  9. malvcr

    BPI-R2 Board Bring-up

    I have been thinking in some combination as OpenVPN (recompiled for cryptodev) with rsync or a type of simple plain data transmission. What I don't know is how will be the overhead ... if it is very high then I will need to process big chunks of data by myself. But, in general, it is a good thing to test :-)
  10. malvcr

    BPI-R2 Board Bring-up

    Not so easy to do ... Latest ssh version (cloned with git from official site): checking OpenSSL library version... configure: error: OpenSSL >= 1.1.0 is not yet supported (have "10101000 (OpenSSL 1.1.1-dev xx XXX xxxx)"). And, of course, when I replace the OpenSSL many things are broken. I will need to figure a different approach. There is a Fedora patch for 1.0, but I think that to make that to work involves more work than to do something from scratch (and will be over when openssh be updated to openssl 1.1.0).
  11. malvcr

    BPI-R2 Board Bring-up

    I checked interrupts, by Rider.Lee in BPI forum recommendation ... and when using the extensions there is a big quantity of them ( openssl speed -evp aes-128-cbc ). First run (with cryptodev) Total change for mtk-aes: 394682 Total change CPU : 2260 + 14616 + 14895 + 22625 = 54396 Second run (without cryptodev) Total change for mtk-aes: 0 Total change CPU : 1710 + 4332 + 4860 + 4357 = 15259 Right now I repeated the test checking the CPU. In the first case the CPU arrived at most to 50% - with cryptodev In the second case went to 100% (one core) - without cryptodev Would be interesting to go directly to the kernel interface. I don't know if openssl or even cryptodev way to do things could be wasting some CPU. My next test would be to replace the basic infrastructure to see how is the behavior with sftp. Previously I only was able to obtain 14 MB/s but this was limited by the CPU.
  12. malvcr

    BPI-R2 Board Bring-up

    Detail .... that hardware engine seems to work better with more than 1024 bytes. Something to take into consideration (although I need to check openssl compiling parameters with more care).
  13. malvcr

    BPI-R2 Board Bring-up

    I am writing to Gary ... but in the while, I built everything and the crypto driver really works. These are the numbers: Without the driver (standard openssl): for i in 128 192 256; do openssl speed -elapsed -evp aes-${i}-cbc ; done You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 4140500 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 1196387 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 312026 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 78846 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 9886 aes-128-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 22082.67k 25522.92k 26626.22k 26912.77k 26995.37k You have chosen to measure elapsed time instead of user CPU time. Doing aes-192-cbc for 3s on 16 size blocks: 3626398 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 1028081 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: ^[[A266479 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 67186 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 8426 aes-192-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-192-cbc 19340.79k 21932.39k 22739.54k 22932.82k 23008.60k You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 3258679 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 910552 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 235055 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 59249 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 7422 aes-256-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 17379.62k 19425.11k 20058.03k 20223.66k 20267.01k With the driver ( to do this I had to compile kernel, cryptodrv and openssl ... with some quirks here and there ): for i in 128 192 256; do ./openssl speed -elapsed -evp aes-${i}-cbc ; done You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 97341 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 83631 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 74013 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 73826 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 45441 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 16384 size blocks: 31972 aes-128-cbc's in 3.00s OpenSSL 1.1.1-dev xx XXX xxxx built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -march=armv7-a -Wa,--noexecstack The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 519.15k 1784.13k 6315.78k 25199.27k 124499.22k 174609.75k You have chosen to measure elapsed time instead of user CPU time. Doing aes-192-cbc for 3s on 16 size blocks: 96073 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 84094 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: 74714 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 74362 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 43467 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 16384 size blocks: 29992 aes-192-cbc's in 3.00s OpenSSL 1.1.1-dev xx XXX xxxx built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -march=armv7-a -Wa,--noexecstack The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-192-cbc 512.39k 1794.01k 6375.59k 25382.23k 118693.89k 163796.31k You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 95306 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 84143 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 74296 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 73367 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 41361 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 28101 aes-256-cbc's in 3.00s OpenSSL 1.1.1-dev xx XXX xxxx built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -march=armv7-a -Wa,--noexecstack The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 508.30k 1795.05k 6339.93k 25042.60k 112943.10k 153468.93k So ... with the R2 I "must" use the hardware help. I will check AF_ALG ... but today hours were not enough ;-)
  14. malvcr

    BPI-R2 Board Bring-up

    I will give a try to what Gary Wang described here (http://forum.banana-pi.org/t/is-it-possible-to-have-the-crypto-extensions-working/4034). ... could be possible that thing is ready? In case I have good news I will share them :-)
  15. malvcr

    BPI-R2 Board Bring-up

    You are right ... priorities. In fact, I would prefer to have the cpufreq type of things ready than the 'special' stuff. So ... today. 1) It is not possible to have high throughput on sequential cryptography networking involving only the CPU. 2) Plain networking (no linear CPU processing involved) is OK. 3) It is not possible to play with the CPU frequency. 4) Disk it is not tuned, and has the PCIe-line bandwidth limitation. USB3 speed it is not good at all. Then ... por specialized programming "today" 1) To increase "protected" networking speed, some sort of multithreading/multiprocessing must be used (at least there are 4 cores), or playing around with the cryptography algorithms to let the CPU to breath. 2) JIT processing it is not a good idea when dealing with lots of data. Better prepare what you can in advance when the CPU it is idle. 3) As the machine hast 2 GB RAM, it is important to use that 'asset' to reduce I/O latency. 4) Don't use USB for disks. Keep SATA and, "maybe", an extra adapter in the PCIe slot.