• Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location

pschasch's Achievements

  1. Hello, I was looking for Kali on BPi and tried the "Kali Linux BananaPi offensive-securityDOTcom-2020.04"-image without success. Unfortunately the image does not boot and no support from there (Domain-contact nor forum[...][...]). Some message about "mount: mounting /dev/mmcblk0p1 on /root failed: No such device", even if kernel was started from this 'No such device"'-SD-card. So Igor wrote me about katoolin which I tested on BPi with Armbian 20.11.3 Busterarmbian. For anyone who is interested here is my way: install "Armbian 20.11.3 Buster \l" install "katoolin see" sudo python2.7 katoolin/ -> Add Kali repositories & Update by the menu adds "deb kali-rolling main contrib non-free" to /etc/apt-sources apt-get install armitage to get msfconsole, first test with vsftpd_234_backdoor-exploit on testdevice was successfull, meterpreter not tested yet. apt-get install burpsuite did not work, I had to add "deb sana main non-free contrib" manually. after this burpsuite could be started. For all who will look for this one day :-D
  2. Ok, here my result from weekend for those who are interested: armbianio needs patch for Lamobo(armbianio.patch): ------------------------------------------ ...armbianio.patch diff --git a/armbianio.c b/armbianio.c +static int iLamobor1Pins[] = {-1,-1,-1,53,-1,52,-1,259,224,-1, + 225,275,226,274,-1,273,244,-1,245,268, + -1,269,272,267,266,-1 + ,270}; ... ------------------------------------------ Sending 433-Mhz-codes now also work with WiringBPi on kernel >=4... with WiringPi it does not work. Only thing I do still not unterstand is why on PI19(275) worked with 17 on 3.4.x But, now my gpio's work like it should, if I change addresses like in io-3.x-vs-4-x.png
  3. wiringpi does not see those changes: /home/Funksteckdosen/433Utils/RPi_utils# cat /sys/class/gpio/gpio224/direction out /home/Funksteckdosen/433Utils/RPi_utils# gpio readall +-----+-----+---------+------+---+-Model A-+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 2 | 8 | SDA.1 | IN | 0 | 3 || 4 | | | 5v | | | | 3 | 9 | SCL.1 | IN | 0 | 5 || 6 | | | 0v | | | | 4 | 7 | GPIO. 7 | IN | 0 | 7 || 8 | 0 | IN | TxD | 15 | 14=in-kernel-3.x ,NOW in-4.xkernel 224 | | | | 0v | | | 9 || 10 | 0 | IN | RxD | 16 | 15 | ... +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+---------+------+---+-Model A-+---+------+---------+-----+-----+ Has someone an idea to fix/convert this? maybe in wiringpi? I need this wiringpi-adresses for example /home/Funksteckdosen/433Utils/RPi_utils/codesend 123...023 nano codesend.cpp int PIN = 15; //wiringpi-definition, this shoud be gpio224 fprintf(stderr, "\n PIN=%i",PIN); 433Utils/RPi_utils needs WiringPi...
  4. OK...I am smarter now... CON3-P01 VCC-3.3V CON3-P02 VCC-5V CON3-P03 TWI2-SDA PB21 CON3-P04 VCC-5V CON3-P05 TWI2-SCK PB20 CON3-P06 GND CON3-P07 GPCLK PI3 CON3-P08 UART3-TX PH0 (8-1)*32+0=224 [3.4.113 old-gpio-number-> 14 RxD ] old-WiringPi-number 15 CON3-P09 GND CON3-P10 UART3-RX PH1 CON3-P11 IO-0(UART2-RX) PI19 (9-1)*32+19=275 [3.4.113 -> 17 ALT4 ] CON3-P12 IO-1 PH2 CON3-P13 IO-2(UART2-TX) PI18 CON3-P14 GND CON3-P15 IO-3(UART2-CTS) PI17 CON3-P16 IO-4(CAN_TX) PH20 works now by sysfs for physical-pin-8: echo "224" > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio224/direction cat /sys/class/gpio/gpio224/value echo "1" > /sys/class/gpio/gpio224/value Now I have to test it 433mhz-transmitter also works with new adress... Are those new adresses because of kernel change? From 3 to 4 or 5 ? Why?
  5. Hi Tido, thanks for fast answer. R1 is AP and switch. - Additional I control 4 LED's to check stuff/States - 4 Inputs to controll my (smart)homeserver FHEM - set some relais... - get IR codes from remote control - PIR to react on movements near to R1 I also need to use gpio for send 433MHz codes, now based on 3.4.113 and wiringpi and rc-switch My first test with armbianIO failed: root@lamobo:~/io/ArmbianIO# ./demo 0=Le potato (Lamobo R1) 1=Banana Pi M2 Zero (not 'Lamobo R1') 2=Raspberry Pi (not 'Lamobo R1') ... 15=Tinkerboard (not 'Lamobo R1') Unrecognized board type, aborting... Problem initializing ArmbianIO library "Banana Pi" no "R1", this would be compatible... I do not know if it is compatible to raspi??? But why is sysfs NOT working? echo "17" > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio17/direction cat /sys/class/gpio/gpio17/value echo "1" > /sys/class/gpio/gpio17/value and why does 17 crash the switch? Why is sysfs activated in this lamobo kernel if does not work? other adresses/gpionumbers? I do not understand the problem with sysfs...
  6. Hello, I just fresh installed Armbian_5.31_Lamobo-r1_Debian_jessie_next_4.9.7.img on my R1(which is for me a fantastic device). I tried to use GPIO by sysfs like I used to do on 3.4.113-kernel. on 3.4.113: echo "17" > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio17/direction cat /sys/class/gpio/gpio17/value echo "1" > /sys/class/gpio/gpio17/value gpio -g read 17 ...this is working fine ls -l /sys/class/gpio/ --w------- 1 root root 4096 Nov 4 19:17 export lrwxrwxrwx 1 root root 0 Nov 4 19:17 gpio14 -> ../../devices/platform/gpio-sunxi/gpio/gpio14 lrwxrwxrwx 1 root root 0 Nov 4 19:17 gpio15 -> ../../devices/platform/gpio-sunxi/gpio/gpio15 lrwxrwxrwx 1 root root 0 Nov 4 19:17 gpio2 -> ../../devices/platform/gpio-sunxi/gpio/gpio2 lrwxrwxrwx 1 root root 0 Nov 4 19:17 gpio22 -> ../../devices/platform/gpio-sunxi/gpio/gpio22 lrwxrwxrwx 1 root root 0 Nov 4 19:17 gpio27 -> ../../devices/platform/gpio-sunxi/gpio/gpio27 lrwxrwxrwx 1 root root 0 Nov 4 19:17 gpio3 -> ../../devices/platform/gpio-sunxi/gpio/gpio3 lrwxrwxrwx 1 root root 0 Nov 4 19:17 gpio17 -> ../../devices/platform/gpio-sunxi/gpio/gpio17 lrwxrwxrwx 1 root root 0 Nov 8 08:02 gpiochip1 -> ../../devices/platform/gpio-sunxi/gpio/gpiochip1 --w------- 1 root root 4096 Nov 8 08:02 unexport on 'Linux lamobo 4.9.7-sunxi #1 SMP Thu Feb 2 01:52:06 CET 2017 armv7l GNU/Linux' it is NOT working root@lamobo:~# echo "17" > /sys/class/gpio/export root@lamobo:~# ls -l /sys/class/gpio/ --w------- 1 root root 4096 Nov 8 08:13 export lrwxrwxrwx 1 root root 0 Nov 8 08:13 gpio17 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpiochip0/gpio/gpio17 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 -> ../../devices/platform/soc@01c00000/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip413 -> ../../devices/platform/soc@01c00000/1c2ac00.i2c/i2c-0/0-0034/axp20x-gpio/gpio/gpiochip413 --w------- 1 root root 4096 Jan 1 1970 unexport ...till here it is fine, but when I do echo "out" > /sys/class/gpio/gpio17/direction (or 'echo out > /sys/class/gpio/gpio17/direction' ) no function of this command / something is crashing and even the "Network/swich" is crashing, the network does not work anymore and the lights of all ethx's go on in 'dimmed'-modus on. With other gpio's I are also not working: ->22 does no switch-crash, but shows error on 'out'-command root@lamobo:~# echo "22" > /sys/class/gpio/export root@lamobo:~# echo "out" > /sys/class/gpio/gpio22/direction -bash: echo: write error: Unknown error 517 ->14 no error on 'out'-command, but no PIN-function on hardware root@lamobo:~# echo "14" > /sys/class/gpio/export root@lamobo:~# echo out > /sys/class/gpio/gpio14/direction root@lamobo:~# echo "0" > /sys/class/gpio/gpio14/value root@lamobo:~# echo "1" > /sys/class/gpio/gpio14/value How Do I get the/those(14,15,2,22,27,3) gpio's to work? regards
  7. Hello Igor, thanks for answering! OK, I am not R1-ubuntu , I hoped I could clone a git and test it without your graet tooltchain. regards
  8. Hello Ikrk, thanks for info! The backported driver I compiled on my R1, but before I compiled the 3.4.108-git-kernel version too on my R1. My backported driver works good (19 day uptime R1 as only AP) , but I got a lot of driver-messages in my logs. I will try/test the shaun2029-driver too, Did you compile on R1 or crosscompile by igors-toolchain? @igor can I somehow compile your 3.4.110-R1-kernel-version with all you patches on R1? Does it support csi-cam? regards
  9. good morning @tkaiser, more good pictures of the module itself can be seen at:,searchweb201644_0,searchweb201560_9 There you can see the new ra5572 from all sides. I have no further pictures from replacement, but like badrianiulian wrote, he has some more but has to look for them and post them But the mod is very simple. On one side there are 6 solderpoints next to each other, the other side are 3 and 3 next to each other. Important is to heat all 12 solderpoints at one time to 'simply' pull the old 8192cu-wifi-mod off the board in one move. I took a special solder-heater to do that, but it may work using 2(both sides) or 1 solder irons too. After removing the old, I soldered all 12 new solder-pins again (see my picture), but like badrianiulian wrote he only took the 6 usb-solderpoints. If you want more pictures of the soldered look, PM me to tell me what pics you you need. regards
  10. @wildcat_paris I put the antenna-cables directly on the mini-rt5572-board. (joke) You or anyone in this forum could buy my 8192cu, i sell it for 10 Euro :-) @badrianiulian If you are happy with mainline-kernel there is no need to do the backports-stuff for 3.4.10x. But I need CSI-camera support which is not working on mainline. Thanks again for your idea and your configs!
  11. Hi, >Somewhere I also read, that only one (1) Antenna is active - can't remember if there is a fix for that Yes, at my R1-8192cu also only 1 antenna gets better signal. is it because of MIMO? one antenna OUT, the other IN? But this Doesn't matter for me anymore... >And if you want to use 40 MHz bandwidth you need to hack the hostapd file I tested everything, also this patches. with/without-Debug-patched and with/without-40Mhz-patches ( ) Nothing was stable with 8192cu. >Thank you for your detailed information. I consider to embed this into the manual. >Did you document on a website or such your modification with some more pictures /text ? No, Unfortunately not. But it's the same and you can test with every ra5572-USB-device for ex. : wildcat_paris his good "Dlink 160B1"-USB-Wifi. (thanks for config-help wildcat!!! :-) ) or the "CSL 300Mbit USB WLAN"-USB-ra5572 from Amazon which I used to test/prepare software before receiving the solder-solution from china. After I received I send the CSL back to Amazon! Test and Configure for those, after testing simply unsolder the 8192cu and solder the MT5572 like on my picture. After soldering replace wlan1 to wlan0 in your configs. I could help you with some more pictures from my mod, but you won't see more as in the published one from the mod-thread I guess. >I just wonder which WiFi chip is in my old: FON2201 (now in my closet for 2 years) >this bloody device also lost connection all the time - it made me sooo angry ...R1 Lamobo made me also very often very angry while testing 8192cu and also if it was in my closet and can't be used as AP. No hardware acceleration makes me still very angry... :-) regards
  12. Hi Tido, thanks for your work and your manual! I had this problem on bananian and on a past version of armbian too,. I was also writing with an other user here in a personal conversation who tested this for me too on his R1 using armbian. Till this point he also thought that he had a stable wifi...but he got the same behaviour on distance to 8192cu and big-data-streams. :-) ...crash...only reboot fixed it... There may be a lot of good feedbacks for usb-8192cu, but for me those bad feedbacks are no coincidence. That's what I found for example on german Amazon: --------------------------------------------------------------------------------------------------------------------------------------------- TP-Link TL-WN822N (8192cu-version) =============================== "Vorsicht: Neue Version mit schlechtem Chipsatz" ..... "Die Realtek-Chipsätze (inkl. 8192CU) sind für deutlichen Leistungsabbruch mit zunehmender Distanz zum Router bekannt. Mein PC ist etwa 4 Meter vom Router entfernt. Das ist bereits genug für deutliche Leistungseinbrüche und Verbindungsverlust." ..... " In V3 nicht zu empfehlen" ..... Sofern ich keine größeren Downloads vornehme funktioniert das Gerät einwandfrei. Die Geschinwidkeit liegt bei ca. 144mbit/s. Sobald ich jedoch einen schnellen Download durchführe (z.B. Game-Download in Steam) verliert er ständig die Verbindung. Kabel ziehen und wieder einstecken hilft nur bedingt - nach 30 Sekunden reist die Verbindung meist direkt wieder ab. Die aktuellsten Treiber helfen da leider auch nicht. ..... Asus USB-N13 N300 Wi-Fi USB Stick ============================== "ASUS hat einen besseren Namen als dieses Produkt zeig" "Verliert ständig die Verbindung zum Router" "UNBRAUCHBAR" " Internetverbindung bricht zwischendurch kurz ab" "kommt dazu das ab und zu keine Verbindung aufgebaut wird" --------------------------------------------------------------------------------------------------------------------------------------------- After "ONLY" testing (no real/productive use) the R1 as "Stable"-AP for more then 1 year after I bought it, those amazon-comments made me stop testing on 8192cu-R1. I hope that someone has a stable 8192cu-R1 now or in the future, in that case he should test the distance/big-datastream-problem and on success he has to post all used software-versions (OS,hostapd,kernel,8192cu-driver) and configs for those in this forum. For me the R1-Lamobo-MT5572-hardware-mod is the best solution for now, With this "15+5 Euro"-mod I have a Lamobo-R1 with a stable WIFI-chip, a free USB-host-port and a WIFI-chip which supports more modes (ex. monitor-mode which is interesting to me). regards
  13. good morning, @shawn wood if you think you have a stable 8192cu-wifi, please test wifi (ex. after about 2-3 days running R1) if your client is not directly next to the R1, so thake a bit distance and then start ex. a youtube-HD-videostream or some big OS-Updates on your client(s). In all my tests with all kind of software-variations (OS,8192cu-drivers,hostapd) my 8192cu-Wifi on R1 was hanging after some days. After this hanging WIFI, restarting any hostapd-versions nor reloading any tested drivers did help! Only reboot the system did fix the problem. On Amazon people with 8192-devices also write those "distance/stream"-PROBLEM-comments, even with windows drivers for 8192. Because of this chip-problem I gave up too on R1-8192cu and did a ra5572-hardware mod. see : My R1-Wifi is stable for 8 days now. Further testing in progress... regards
  14. Hi, my "Mt5572 wifi-modul wl- um01ebs- 5572- v 1. 0 27*17.7mm usb 2. 0" arrived from china. The ra5572-chip is working on R1-lamobo with 3.4.108-kernel and backports-3.12.8-1-drivers. Mainline kernel works out-of-the-box , but I need CSI-cam-support in 3.4. (see During my x-mas vacation I tested the driver with an "CSL 300Mbit USB WLAN"-USB-ra5572 from Amazon and my wifi worked very stable for 14 days till I ended the duration test to solder the new onboard-module. So anyone who wants to test his software/drivers for the ra5572-mod could test the ra5572 with this Amazon-usb-wlan-Stick :-) I think the The orig/old 8192cu-Module on the R1 lamobo will never be stable using it with a client loading big datastreams if a wifi-client has some distance to the R1-8192cu-chip. Thanks again to badrianiulian for this great idea! New durationtest with the soldered-onboard-ra5572 is running STABLE for 8 days now, never did with 8192cu. regards