Difference between revisions of "Bering-uClibc 7.x - User Guide - Advanced Topics - Setting Up a Raspberry PI as a net to serial gateway"
(→You will need) |
(→Correcting some bugs...(only for the PI 1)) |
||
Line 156: | Line 156: | ||
==Correcting some bugs...(only for the PI 1) == | ==Correcting some bugs...(only for the PI 1) == | ||
− | This last section is only for the first generation PI 1. I experienced some issues that needed fixing. With the newer versions these bugs might be gone now, but I didn't check that '''yet''', as there are more important things to do, and besides it works now !!! and I've grown attached to my solutions :-) . | + | This last section is only for the first generation PI 1 with "LEAF Bering-uClibc 6.1.4 Rev 1 uClibc 1.0.25" distribution. I experienced some issues that needed fixing. With the newer versions these bugs might be gone now, but I didn't check that '''yet''', as there are more important things to do, and besides it works now !!! and I've grown attached to my solutions :-) . |
The other PIs 2 and 3, that I own, didn't show these problems. | The other PIs 2 and 3, that I own, didn't show these problems. | ||
Latest revision as of 19:48, 27 May 2022
Setting Up a Raspberry PI as a net to serial gateway | ||
---|---|---|
Prev | Bering-uClibc 7.x - User Guide | Next |
Contents
Goal
This setup shows how to use the LEAF tarball distribution for the raspberry PI, to access the serial communication port of a distant PC Engines APU2C2 using a simple SSH session. To access the serial port, we will first SSH to the Raspberry PI and then run a communication program like minicom or picocom.
This setup can be generalized to make any "device serial communication port" accessible through an SSH network session. Knowing that RS-232C communication distances are short, why not use a wired network instead that can reach a lot farther.
All of this was initially done using the standard Raspberry PI Raspbian OS distribution, but using the LEAF distribution OS instead, really transforms the somewhat flaky PI into a very stable and dependable production platform, since everything will then run in rams and no writings to the SD card will ever occur once in operation... It is a well known fact that, it is only a matter of time for the Raspberry PI to corrupt it's SD card, thus making it fail to boot or run. This is mainly caused by random power fails occurring at the same time the PI is writing to the SD card (further readings: https://hackaday.com/2016/08/03/single-board-revolution-preventing-flash-memory-corruption/).
You will need
- - one of the raspberry PIs: zero (I doubt it), zero_w, 1, 2, 3, 4 with matching power supply
- - either:
- - or more simply:
- - or the minimalist but cute PI Zero W
Setting up the SD
Prepare your SD card according to the previously given instructions...
Access your PI and do the following ajustments:
mount /dev/mmcblk0p1 /mnt cd /mnt
- find leaf.cfg file and in LRP="...
- remove shorwall and dnsmasq; ... It is important to remove "shorewall" here, it's job is to block everything and "dnsmasq" is not needed !
- add local, picocom or minicom
- you should now have something like: LRP="license root nano local dhcpcd keyboard dropbear lighttpd webconf picocom patch"##
- Run:
- lrcfg > 3) Packages configuration > 6) dropbear > 1) dropbear configuration
- change line #DB_OPTIONS=" -s " to DB_OPTIONS=" -B "
- this will allow a first root login with no password
- And save everything with:
- lrcfg > s) Save configuration > Enough freespace? (y/N) y
Booting the Raspberry PI
- - Reboot your PI
- - After ~ 30 seconds, find out the PI's Ip address, and ssh in it: ssh root@raspberry_pi_IP_address. On Android, the "fing" app does marvels ... or simply run the command: ip addr
- - Set the new passwords for the OS and webconf, as you will be asked.
- - Open webconf from a browser http://raspberry_pi_IP_address to try it out
- - While you're there, it would be a good idea to comment-out eth1 in /etc/network/interfaces, look in Networking...
- - A good time also to do your "ssh-copy-id" to write ssh keys in /.ssh/authorized_keys (see https://bering-uclibc.zetam.org/wiki/Bering-uClibc_6.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_SSH_password-less_login_and_Port_Knocking )
Using the gateway
- If you are using the older and cumbersome RS-232C to USB cable + Null modem you are good to go:
- - connect the RS-232C to USB cable with the null modem between your PI and your device serial port
- - on your external PC, open an ssh session to the PI
- - within your ssh session, start picocom on the PI: picocom -b115200 /dev/ttyUSB0
- - hit return:... you should have the prompt to login in your router or whatever !
- - exit picocom with Cntl-a Cntl-x, help is Cntl-a Cntl-h
- If you are using the simpler RS-232C to 3.3 volts ttl converter you first need to deactivate a couple of things...
- - deactivate the console ttyAMA0 by commenting it out in /etc/inittab
- - in /mnt/cmdline.txt remove console=ttyAMA0,115200 kgdboc=ttyAMA0,115200
- - lrcfg > s) save, reboot
- - connect the "RS-232C to 3.3 volts ttl converter" to your PI 3.3v(pin1) to ttl-VCC, TX(14) to ttl-TX, RX(15) to ttl-RX and ground(pin6) to ttl-GND, and plug the converter in your device serial port
- - on your external PC, open an ssh session to the PI
- - start picocom: picocom -b115200 /dev/ttyAMA0
- - hit return:... you should have the prompt to login in your router or whatever !
- - exit picocom with Cntl-a Cntl-x, help is Cntl-a Cntl-h
- Lastly, using the PI Zero W... detailed explanations for the WIFI are available here
- - deactivate the console ttyAMA0 by commenting it out in /etc/inittab
- - in /mnt/cmdline.txt remove console=ttyAMA0,115200 kgdboc=ttyAMA0,115200
- - in /mnt/leaf.cfg add the following lrp modules to LRP=" ...iw.lrp, wireless.lrp, wpasupp.lrp..."
- - lrcfg > s) save, reboot
- - in /etc/default/wpasupplicant set ENABLE=1 and INTERFACE="wlan0"
- - in /etc/wpa_supplicant.conf set ssid="your_ssid" and psk="your_psk"
- - in /etc/network/interfaces add at the end:
auto wlan0 iface wlan0 inet dhcp wpa_supplicant_control 1
6.-lrcfg > s) save, reboot
After this last reboot, the PI Zero W might still refuse to connect to your WIFI because it complains about missing some firmware or regulatory.db files. These files are not part of the Distribution yet, but can be copied from the Raspberry PI Zero OS or from here. If you are tempted by this last case, simply click the Download button in the web page and configdb.lrp will be copied to your Download directory.
Let's unpack this configdb.lrp:
cd ~/Downloads sudo mkdir configdb cd configdb sudo tar xzvf ../configdb.lrp
So now all your missing files are in ~/Downloads/configdb/
There are different ways of copying these files to your PI Zero W, but right now, you are connected to it with only the HDMI display and USB keyboard, and there are no direct way to copy these files... Let's look at some options:
- We will use a USB key to transfer the files to your PI Zero W... and I assume you don't have a USB hub; too simple then !
- we have to free the USB port where your keyboard is now attached, and replace it's function with the serial console on /dev/ttyAMA0
- Using the console implies you have some soldered pins on gpio 14 and 15, and ground and a USB converter (cheaper than a HUB )
- re-enable the console on /dev/ttyAMA0 by un-commenting it in /etc/inittab
- lrcfg > s) save
- poweroff the PI and connect a ttl to USB converter from your PI's GPIO pins 14, 15 and ground, to an external PC USB port
- on your external PC, mount a USB key on /mnt
- put the missing files on the USB key: sudo cp -r ~/Downloads/configdb/lib/firmware/ /mnt/firmware/
- unplug your USB keyboard from the PI Zero W, and plugin the USB key in it's place
- start a picocom session on your PC: picocom -b115200 /dev/ttyUSB0
- powerup the PI, patiently wait until you get a login prompt... well login !
- mount the USB key to /mnt and copy the files to /lib/firmware : cp -r /mnt/firmware/* /lib/firmware/
- disable the console by commenting it out in /etc/inittab
- a final lrcfg > s) save before reboot
Phew !!! that's a lot of steps ...
- We can also use the special file configdb.lrp, no need to solder pins here and no additional hardware is required
- mount your PI's SD card on your external PC like:
sudo mount /dev/sdb1 /mnt cd /mnt sudo mkdir configdb cd configdb sudo tar xzvf ../configdb.lrp
- this unpacks your existing PI's configdb.lrp to /mnt/configdb/
- Now you can copy the missing files to /mnt/configdb/lib/firmware/
sudo cp -r ~/Downloads/configdb/lib/firmware/* /mnt/configdb/lib/firmware/ cd /mnt/configdb ...just in case ... sudo tar -c * | gzip -9 > configdb.lrp sudo cp configdb.lrp ../
- and this repacks and replaces your original PI's configdb.lrp, yeap .lrp is just a renamed .tgz !
- Put back the SD card in your PI and reboot and test if you have WIFI connectivity:
ip addr
should give you wlan0: ip address... after a few seconds.
You just learned how to use configdb.lrp to preset some package parameters directly on your media. This file is special as it does not have to be signed like all the other packages, and if present will be loaded without complaints. The LEAF system generates configdb.lrp after you made changes when hitting lrcfg > s) save. On a fresh distribution it does not exist yet, but you can always create one manually, but thread carefully as it will supersede any existing one, or you can always do what we just did, only copy the changes to the existing one.
Additionnal Raspberry PI Zero W ack
Here is a clean setup for the PI Zero W, everything fits in a 3D printed box, and the wiring to the flashy red hot APU2C2 serial port is a neat flat cable.
Correcting some bugs...(only for the PI 1)
This last section is only for the first generation PI 1 with "LEAF Bering-uClibc 6.1.4 Rev 1 uClibc 1.0.25" distribution. I experienced some issues that needed fixing. With the newer versions these bugs might be gone now, but I didn't check that yet, as there are more important things to do, and besides it works now !!! and I've grown attached to my solutions :-) . The other PIs 2 and 3, that I own, didn't show these problems.
From an already opened ssh session:
- - fix xterm: go to /etc/terminfo/x and "cp xterm xterm-256color" ... # the "lrcfg" menu needs xterm-256color so we make one up in B&W !
- - fix reboot: The busybox reboot command does not work, here is a hardware alternative done by connecting GPIO4 to the PI reset pin on P6 pin 1 (the square one). Solder a 2 pin header on P6 (https://i.imgur.com/jR8hmwG.jpg?1) and place a jumper wire between P6 pin 1 and GPIO4 on P1 pin 7 (https://i.imgur.com/R9dx5TH.jpg?1).
- - create a new "reboot" command: first, make the script /root/GPIO4reboot.sh and second, change the old reboot command in /sbin...
the script /root/GPIO4reboot.sh will set gpio4 to low (0) which will reset the PI, a hard reboot !
cd /root nano GPIOreboot.sh
fill with this content:
#!/bin/sh # # reset avec gpio4 connecte sur reset du PI, P6 pin 1 square. # echo "4" > /sys/class/gpio/export # we will talk to gpio4 echo "out" > /sys/class/gpio/gpio4/direction # gpio4 on boot is an high-z input, but defaults to low (0) as an output
don't forget to make the script executable with:
chmod 0755 GPIO4reboot.sh
Let's replace the non-working "reboot" command with our own hardware reboot command ...
cd /sbin mv reboot old_reboot # keep old command in case someone repairs/fixes busybox... ln -s /root/GPIO4reboot.sh reboot # the "reboot" command link now points to /root/GPIO4reboot.sh
- - set the local.local: everything we just did which is not part of the LEAF distribution has to be saved in /var/lib/lrpkg/local.local ...
lrcfg > 3) Packages configuration > 3) local > 1) list of files that should be saved >
fill with this content:
var/lib/lrpkg/local.local etc/terminfo/x/xterm-256color root/.ssh/authorized_keys root/GPIO4reboot.sh sbin/reboot sbin/old_reboot
***and a very important final save:
lrcfg > s) save configuration
Final thoughts
- It would be a good idea to configure eth0 with a static IP address in /etc/network/interface. This would allow a network communication between your workstation and the PI Serial gateway even if your firewall and consequently DHCP server are down.
- In the previous case, you might also probably loose WIFI connectivity, so using a PI Zero W might not be as reliable... ymmv !
- You can also remove or comment out DB_OPTIONS=" -B " in /etc/default/dropbear, to bring the security level back.
- Using the PI as a full blown firewall has not been tested here, the feeling is that it would be too slow... volunteers are welcome ...
Have fun
by: jrb with kapeka's idea to use leaf !
Prev | Up | Next |