Wireless Chat using NRF24L01+ 2.4GHz RF Transceiver on Arduino & Raspberry Pi Ubuntu Linux

After a bit of success implementing an Arduino 2.4GHz Transceiver, I was encouraged to explore a more familiar environment, something with Python and Linux in the mix.

After a short period of research I landed on the circuitpython-nrf24l01 pypi project page, and quickly began digging through their examples.

It wasn’t long after I had a working prototype that mirrored my Arduino code quite closely:

Components

import sys
import select

from circuitpython_nrf24l01 import RF24
import board
import digitalio as dio

# addresses needs to be in a buffer protocol object (bytearray)
address = b'Nessy'

# change these (digital output) pins accordingly
ce = dio.DigitalInOut(board.D4)
csn = dio.DigitalInOut(board.D5)

# using board.SPI() automatically selects the MCU's
# available SPI pins, board.SCK, board.MOSI, board.MISO
spi = board.SPI()  # init spi bus object

# initialize the nRF24L01 on the spi bus object
nrf = RF24(spi, csn, ce, ask_no_ack=False, data_rate=250)
nrf.dynamic_payloads = False # this is the default in the TMRh20 arduino library
nrf.payload_length = 32

# get username
username = input('Enter Username: ')

# set address of RX node into a TX pipe
nrf.open_tx_pipe(address)

# set address of TX node into a RX pipe
nrf.open_rx_pipe(1, address)

nrf.listen = True

print('Welcome %s' % username)
while True:

    # handle write
    if select.select([sys.stdin,],[],[],0.0)[0]:
        nrf.listen = False
        for line in sys.stdin:
            msg = b'[%b] %b' % (username.encode(), line.rstrip().encode())
            nrf.send(msg)
            break

    # handle recieve
    if not nrf.listen:
        nrf.listen = True

    if nrf.any():
        # retreive the received packet's payload
        buffer = nrf.recv()
        data = buffer.decode().replace('\x00', '')
        print(data)

Grafana 5.x Running on Raspberry Pi

Got around to upgrading my Raspberry Pi 3 Model B weather station with a newer version of Grafana, the Debian packages for ARM are hosted on Grafana’s download page under ARMv7.

Moving from a 2.x word to a 5.x has been impressive, most notably the drag, drop, and resize functionality.

I’m still using InfluxDB and Telegraf to store and populate my time data points.

Latest Raspbian’s (stretch) comes with Influx 1.0.2 and works nicely:

# dpkg -l | grep influxdb
ii  influxdb     1.0.2+dfsg1-1 armhf

While I needed to grab the Telegraf as a Linux Binary (ARM) from Influx’s download page.

Enjoy!

File not found!

I’ve seen it before, a customer deletes a file and then needs it restored.

Normally a challenging request, but under special circumstances a process may have the file opened.

While showing my son some fun and exciting Linux security scenarios, I recalled all those times I was able to recover data from the /proc (in memory) filesystem. In order to visualize this scenario I threw together a small Dockerfile and had him poke around:

Once logged in you notice a server.py script, for our scenario this is our companies server daemon. If we browse the code we notice a file named password.txt was opened, but never closed.

Ignore the sleep() function, this is just here to keep the file opened, and to simulate a daemon process.

The next things you should do it verify the server is actively running! If we hope to recover that file the server needs to have a lock on password.txt

root@4df66824ad14:~# ps aux
USER  PID %CPU %MEM VSZ   RSS  TTY    STAT START   TIME COMMAND
root   1  0.0  0.0  18504 3396 pts/0  Ss   01:37   0:00 /bin/bash
root  10  0.0  0.1  22548 6076 pts/0  S    01:37   0:00 python server.py
root  24  0.0  0.0  34396 2904 pts/0  R+   01:45   0:00 ps aux

We are in luck!

From here we can use the lsof command to verify password.txt is still opened:

root@4df66824ad14:~# lsof | grep password.txt
python 10 root 3r REG 8,1 30 15860072 /root/password.txt (deleted)

Bingo! we see the file is opened, and it is marked for deletion. Good thing our service is still running!

All that is left is to track down our service’s process id (we see above it’s process id, or PID is 10).

We now have all the pieces to track down our password file from the in memory filesystem.

The /proc filesystem has a number of useful files, it also includes a directory for every running process (named after the PID).

Within the process directory we have a slew of files; however, the directory we care about is fd (standing for file descriptor):

root@4df66824ad14:~# cd /proc/10
root@4df66824ad14:/proc/10# ls -l fd
total 0
lr-x------ 1 root root 64 Sep 28 01:43 0 -> /dev/null
lrwx------ 1 root root 64 Sep 28 01:43 1 -> /dev/pts/0
lrwx------ 1 root root 64 Sep 28 01:43 2 -> /dev/pts/0
lr-x------ 1 root root 64 Sep 28 01:43 3 -> '/root/password.txt (deleted)'

And just like that we found a file representing our in memory password.txt file!

From here we can show its contents, or even restore it using cp:

root@4df66824ad14:/proc/10# cat fd/3
the-most-secret-password-ever

Happy hacking!