The (Tech) Life of (a) Brian

Useful tshark Commands

Posted on June 12, 2022 by Brian

A few useful tshark commands I’ve used;

sudo apt install tshark
sudo tshark -Y http.request -T fields -e http.request.full_uri
sudo tshark -Y http.response -T fields -e http.request.full_uri
sudo tshark -Y http.request || http.response -T fields
sudo tshark -Y http.request || http.response -T fields -e http.request.full_uri
sudo tshark -Y http.request.method==POST -T fields -e http.file_data
sudo tshark -Y ip.addr==X.X.X.X -T fields -e frame.number -e frame.time -e ip.src -e ip.dst -e http.file_data
sudo tshark -Y ip.addr==X.X.X.X -T fields -e frame.number -e frame.time -e ip.src -e ip.dst -e _ws.col.Protocol -e ip.len -e _ws.col.Info -e http.file_data

sudo apt install tshark

sudo tshark -Y http.request -T fields -e http.request.full_uri

sudo tshark -Y http.response -T fields -e http.request.full_uri

sudo tshark -Y http.request || http.response -T fields

sudo tshark -Y http.request || http.response -T fields -e http.request.full_uri

sudo tshark -Y http.request.method==POST -T fields -e http.file_data

sudo tshark -Y ip.addr==X.X.X.X -T fields -e frame.number -e frame.time -e ip.src -e ip.dst -e http.file_data

sudo tshark -Y ip.addr==X.X.X.X -T fields -e frame.number -e frame.time -e ip.src -e ip.dst -e _ws.col.Protocol -e ip.len -e _ws.col.Info -e http.file_data

Posted in Technical - General | Leave a comment

I’ve been away but “Now I’m Back”

Posted on June 12, 2022 by Brian

Yes been away from my site for a while but everything is now updated and hunky-dory!

I have a few drafts that have been sitting for a while, so once reviewed, I’ll get posting!

Posted in Technical - General | Leave a comment

DietPi – Move Boot partition to smaller SD Card

Posted on January 8, 2020 by Brian

Original Topic

DietPi is just a great distribution. If you haven’t tried it, do.

There is a function within the system called dietpi-drivemanager and it does what it says on the tin, manages drives. For me I wanted to move the rootfs to an SSD. Easily done with DietPi.

Once I had done that, I wanted to reclaim the 16GB SD Card for other things and reuse an old 2GB card. This turned out to be quite easy as well.

From the top – I inserted the smaller SDCard into a USB adapter and plugged it into the Pi.

The smaller card shows up as sdb with lsblk command. First, format the smaller card and create a new partition (taken from this item).

root@DietPi:~# fdisk /dev/sdb
Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1,3,4, default 1): 1
First sector (2048-15407103, default 2048): 8192
Last sector, +sectors or +size{K,M,G,T,P} (8192-122879, default nnnnnnnn): 122879

Created a new partition 1 of type 'Linux' and of size 56 MiB.

Command (m for help): w

root@DietPi:~# fdisk /dev/sdb

Command (m for help): n

Partition type

p primary (1 primary, 0 extended, 3 free)

e extended (container for logical partitions)

Select (default p): p

Partition number (1,3,4, default 1): 1

First sector (2048-15407103, default 2048): 8192

Last sector, +sectors or +size{K,M,G,T,P} (8192-122879, default nnnnnnnn): 122879

Created a new partition 1 of type 'Linux' and of size 56 MiB.

Command (m for help): w

Remember the last command to actually make the changes.

Format the partition as fat

root@DietPi:~# mkfs.fat /dev/sda1

1	root@DietPi:~# mkfs.fat /dev/sda1

Once the filesystem is made you’re ready to copy – I used dd

root@DietPi:~# dd if=/dev/mmcblk0p1 of=/dev/sdb1

1	root@DietPi:~# dd if=/dev/mmcblk0p1 of=/dev/sdb1

Next, you need to edit the /etc/fstab file.

You need to edit this line and insert the right PARTUUID for the new boot partition. Use the blkid command to get the value. Remember, it will still be shown as the PARTUUID for /dev/sdb1

PARTUUID=cb7b86f7-01 /boot vfat noatime,lazytime 0 1

1	PARTUUID=cb7b86f7-01 /boot vfat noatime,lazytime 0 1

I then un-mounted the /boot partition, removed the card and inserted the smaller card before rebooting.

As the boot partition is not mentioned in the cmdline.txt file, I did not find a need to edit it.

Bingo! I now have the boot on an otherwise redundant 2GB card and free up a 16GB card for other things. Reduce, reuse recycle.by

Posted in DietPi, Linux, RaspberryPi, Technical - General | Leave a comment

Get data from WH1080 Maplin Weatherstation sensors directly

Posted on December 17, 2019 by Brian

I have been using pywws to extract the weather station data from my Maplin WH1080 for 6 years now but have now suffered from the dreaded (in pywws circles) USB Lockup – basically the weather station stops talking to the Raspberry Pi.

Via a strange set of circumstances on the OpenEnergyMonitor community, I discovered the package rtl_433 and wondered if I could read the data directly from the sensors which were clearly still working as the base station continued to show updates.

The short answer was “Yes I can”.

First step was to identify a suitable USB DVB stick that uses the Realtek RTL2832U chip. I chose this one from Amazon.

While I waited the day for delivery (oh woe is me), I got to installing the rtl_433 package.

The rtl_433 GitHub page links you to a list of repositories. As I wanted to run it on a Raspberry Pi, I noted it was available in the ‘testing’ repository. Never having installed anything from a different repo this took me on a different track as explained here.

Once installed, and once the stick arrived (today), I simply plugged the stick in at typed

rtl_433 -R 32

1	rtl_433 -R 32

That was it. My data appeared.

I did want it passed into MQTT so I ended up (having asked a stupid question and been pointed to the wiki) with;

rtl_433 -R 32 -F "mqtt://X.X.X.X:1883,user=user1,pass=pass,retain=0,events=rtl_433_weather"

1	rtl_433 -R 32 -F "mqtt://X.X.X.X:1883,user=user1,pass=pass,retain=0,events=rtl_433_weather"

I now get a single JSON payload message on my MQTT broker!

HTH by

Posted in Linux, Technical - General | Tagged MQTT, rtl_433, weatherstation, WH1080 | Leave a comment

Install a Package from the Testing Repository

Posted on December 17, 2019 by Brian

I wanted to install the rtl_443 package onto my Raspberry Pi, running Buster edition of Raspbian, so I could read the data from my WH1080. The GitHub page pointed me to the Raspbian testing repository.

To install this package from testing, the first task was to edit /etc/apt/sources.list and add the repository;

deb http://raspbian.raspberrypi.org/raspbian/ testing main

1	deb http://raspbian.raspberrypi.org/raspbian/ testing main

Then sudo apt update . At this point I then just did sudo apt-get install rtl-433 but I suggest you don’t if you don’t want everything updated from the testing repository (I didn’t).

Instead create file /etc/apt/preferences and include;

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release o=Raspberry Pi Foundation,a=testing,n=buster,l=Raspberry Pi Foundation,c=main,b=armhf
Pin-Priority: 675

Package: *
Pin: release a=testing
Pin-Priority: 650

Package: *
Pin: release a=unstable
Pin-Priority: 600

Package: *

Pin: release a=stable

Pin-Priority: 700

Package: *

Pin: release o=Raspberry Pi Foundation,a=testing,n=buster,l=Raspberry Pi Foundation,c=main,b=armhf

Pin-Priority: 675

Package: *

Pin: release a=testing

Pin-Priority: 650

Package: *

Pin: release a=unstable

Pin-Priority: 600

and sudo apt update

This will put the raspbian testing repository as a lower priority than the main and standard repositories. You can check this by using apt-cache policy to list the repositories.

Note, by default, Raspbian is picking up a Debian repository – no idea why, but it is a bit confusing if you do a apt list --upgradable

All that is needed to install the package is a sudo apt install rtl_433

HTH by

Posted in Linux, Technical - General | Tagged Raspbian, rtl_433 | Leave a comment

ReadyNasDuo V1 Rsync

Posted on October 3, 2019 by Brian

This is a quick – “so that’s how I did it”

Connecting to an rsync share on the NasDuo;

rsync -v <filename> <user>@192.168.x.x::<share>

1	rsync -v <filename> <user>@192.168.x.x::<share>

Where the user is listed under the ‘Advanced Options’ of the share. I used a user without a password, nogroup and all the rights disabled.

For me it was the double colon. Before that I got an error

ssh: connect to host 192.168.7.11 port 22: Connection refused
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [sender=3.1.2]

ssh: connect to host 192.168.7.11 port 22: Connection refused

rsync: connection unexpectedly closed (0 bytes received so far) [sender]

rsync error: error in rsync protocol data stream (code 12) at io.c(235) [sender=3.1.2]

Posted in Linux, Technical - General | Tagged rsync | Leave a comment

Miscrosoft Teams – stop it auto starting

Posted on August 23, 2019 by Brian

The fact Microsoft is forcing Teams onto every computer is extremely annoying and it seems they have made it deliberately difficult to prevent it from auto starting.

I’ve found 3 different fixes;

From the main Windows interface,

Select the Start Windows logo Start button button, then select Settings Gear-shaped Settings icon > Apps > Startup. Select Off for Teams.
If you don’t see the Startup option in Settings, right-click the Start Windows logo Start button button, select Task Manager, then select the Startup tab. (If you don’t see the Startup tab, select More details.) Select the app you want to change, then select Enable to run it at startup or Disable so it doesn’t run.

Finally, edit the setup.json file found here

%userprofile%\AppData\Local\Microsoft\Teams

1	%userprofile%\AppData\Local\Microsoft\Teams

Set

"noAutoStart":true

1	"noAutoStart":true

HTH by

Posted in Technical - General | Tagged autostart, microsoft, teams | Leave a comment

Letsencrypt SSL Certificates by DNS Challenge with Lighttpd

Posted on March 22, 2019 by Brian

LAN HTTPS Everywhere

The aim of this investigation was to find a way to deploy HTTPS certificates on my LAN. This might seem over the top, but a) Troy Hunt thinks it is a good idea and b) I was getting fed up of the ‘insecure’ messages.

After much fiddling and experimenting I have settled on this process.

Things to note:

You do not need any web server on the internet. You just need to be able to edit your domain DNS record.
Use a subdomain for each certificate/server – these do not need to actually exist on the DNS.
I’m not going to go into detail about things that are easily found with Google search.

Prerequisites

Domian – you need to have one available – I bought mine for $10 from Google Domains.
Host the DNS for the domain where you can edit the records – I was going to use Google Domains (hence the purchase) but ended up with the domain on CloudFlare DNS servers.

For me I am using Lighttpd so some of this is that server specific and my OS is DietPi.

Set Up DNS Access

Assuming you have got your CloudFlare account all setup, go to your profile page, scroll down and click on ‘View’ next to Global API Key. You will need it in the next step.

Install & Configure certbot

You may need sudo for these commands if not on DietPi as root. Also remember that any scripts need to be made executable chmod +x .

First thing is to install certbot with the right plugin.

If like me you use DietPi, then dietpi-software install 92 else apt-get install certbot . Then:

apt-get install python3-certbot-dns-cloudflare

Create a folder called .secrets and create /edit a file called cloudflare.ini . Include the following lines from setting up access to CloudFlare DNS above. Treat this like a password so chmod 600

dns_cloudflare_email = xyz@nowhere.com
dns_cloudflare_api_key = 11111111111111111111111111

1 2	dns_cloudflare_email = xyz@nowhere.com dns_cloudflare_api_key = 11111111111111111111111111

Now create a small script to generate the certificate (you will need to change the domain and the path to match your ini file) – you will only need this once (hopefully):

#!/bin/sh

MY_DOMAIN="yourdomain.net"

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /user/.secrets/certbot/cloudflare.ini \
  -d $MY_DOMAIN

cat /etc/letsencrypt/live/$MY_DOMAIN/cert.pem /etc/letsencrypt/live/$MY_DOMAIN/privkey.pem > \
  /etc/letsencrypt/live/$MY_DOMAIN/web.pem

systemctl restart lighttpd.service

#!/bin/sh

MY_DOMAIN="yourdomain.net"

certbot certonly \

--dns-cloudflare \

--dns-cloudflare-credentials /user/.secrets/certbot/cloudflare.ini \

-d $MY_DOMAIN

cat /etc/letsencrypt/live/$MY_DOMAIN/cert.pem /etc/letsencrypt/live/$MY_DOMAIN/privkey.pem > \

/etc/letsencrypt/live/$MY_DOMAIN/web.pem

systemctl restart lighttpd.service

You can run this script, answer the questions and the certificate should be generated.

Note the cat command in the script. certbot does not generate the right combined certificate for lighttpd so this needs to be done manually. That is a bit of a pain and requires a little more setting up to get renewal to work automatically.

Setting Up Renewal

To get a new combined certificate on renewal a small script is needed that will execute once the certificate has been renewed and deployed.

nano /etc/letsencrypt/renewal-hooks/deploy/combine.sh

1	nano /etc/letsencrypt/renewal-hooks/deploy/combine.sh

and in the file place the following code (no modification necessary):

#!/bin/sh

for domain in $RENEWED_DOMAINS
do
   # Combine the certificate and private key file
    cat /etc/letsencrypt/live/$domain/cert.pem /etc/letsencrypt/live/$domain/privkey.pem > \
      /etc/letsencrypt/live/$domain/web.pem
done

systemctl restart lighttpd.service

#!/bin/sh

for domain in $RENEWED_DOMAINS

# Combine the certificate and private key file

cat /etc/letsencrypt/live/$domain/cert.pem /etc/letsencrypt/live/$domain/privkey.pem > \

/etc/letsencrypt/live/$domain/web.pem

done

systemctl restart lighttpd.service

The only way to test this is to force the renewal

certbot renew --force-renewal

1	certbot renew --force-renewal

A modern install of certbot will install systemd timer for you so it should just renew. To check the timer

systemctl list-timers --all

1	systemctl list-timers --all

Lighttpd Configuration

This is included for me more than anything, as it can easily be found, but this is the addition to the standard /etc/lighttpd/lighttpd.conf file that I find works.

$SERVER["socket"] == ":443" {
  ssl.engine = "enable"
  ssl.pemfile = "/etc/letsencrypt/live/your.domain.net/web.pem" # Combined Certificate
  ssl.ca-file = "/etc/letsencrypt/live/your.domain.net/chain.pem" # Root CA
  server.name = "your.domain.net" # Domain Name OR Virtual Host Name
  accesslog.filename = "/var/log/lighttpd/domain_access.log"
}

$HTTP["scheme"] == "http" {
  # This should be always true for insecure incomming connections:
  $HTTP["host"] =~ ".*" {
    # redirect to https, port 443:
    url.redirect = (".*" => "https://%0$0")
  }
}

$SERVER["socket"] == ":443" {

ssl.engine = "enable"

ssl.pemfile = "/etc/letsencrypt/live/your.domain.net/web.pem" # Combined Certificate

ssl.ca-file = "/etc/letsencrypt/live/your.domain.net/chain.pem" # Root CA

server.name = "your.domain.net" # Domain Name OR Virtual Host Name

accesslog.filename = "/var/log/lighttpd/domain_access.log"

}

$HTTP["scheme"] == "http" {

# This should be always true for insecure incomming connections:

$HTTP["host"] =~ ".*" {

# redirect to https, port 443:

url.redirect = (".*" => "https://%0$0")

}

Restart lighttpd (and clear cache).

Setting up an internal FQDN

Outside the scope of this but, if you have PiHole installed simply add the domain and IP to the /etc/hosts file on the PiHole, restart PiHole and you should be able to just type in the domain name and be directed to a secure https address.

HTH by

Posted in DietPi, Technical - General | Tagged DNS, Internal HTTPS, LAN, letsencrypt, Lighttpd, SSL | Leave a comment

BT Broadband – Faster Speeds – Yes Really

Posted on March 9, 2019 by Brian

Well BT have done what they said. I’ve even noticed a slight up tick today so it is obviously still training to the fastest possible stable rate.

Posted in Technical - General | Leave a comment

Ubiquiti USG Home Setup

Posted on March 9, 2019 by Brian

I treated myself to an Ubiquiti UniFi Security Gateway (USG) this week, bought off Netxl but Via Amazon (as it was cheaper). The setup was not quite as straightforward as the AP I installed a couple of months ago. In doing that I had played with installing the Controller software on a DietPi VM (what a surprise) and hit a couple of issues around Java.

Although that setup worked, I was never comfortable with it and I have subsequently discovered this amazing script to install the UniFi Controller – thanks Glenn. Being on a VM, I just rolled it back to the base snapshot and started afresh having first exported the configuration and then just loaded the backup in to the new instance – easy. He also has an update script which will also update the client firmware if you like – awesome. They both just work! The Controller software was asking to be updated so I did that first.

I didn’t write up anything about setting up the AP; it just worked. I created WLANs with an SSID/Password combo to match the existing networks so there was no need to go round reconnecting everything. The AP is so much better – I used to have major issues with my work VPN as it kept dropping out when on WiFi (fine on a wired connection). It is now rock solid.

I’d hoped that the USG, like the AP, would just plug into the network and off it would go – but it didn’t. This was partly a lack of understanding on my part and a little more info required in the Quick Start. To cut a long story short, this is what you need to understand:

The factory firmware is probably way behind and the UI is much improved and expanded so you need to log in by SSH locally to do that.
The USG wants the WAN network and LAN network to be on different subnets (assuming you are behind a home router). You therefore end up with 2 DHCP servers one on the Home Router for the WAN port on the USG, and the other on the USG for the rest of your network.
The USG takes a while to boot – be patient.
This also assumes you have disabled all the WiFi connections to the Home Router.

I have got quite a lot of hard-coded IPs on my network and they often expect a specific default gateway so I needed it to slot in where the Home Router left off.

To get it up and running:

Make sure only one thing is plugged in directly to the Home Router so you can insert the USG between your network and the Home Router (your WAN).
Connect the LAN1 port on the USG to a standalone computer (need a cable and turn off the wireless so forcing it onto the wired connection), and the WAN port of the USG to your normal network (or the Home Router).
The USG will boot with the WAN connected to a DHCP IP from your network, and the LAN1 IP (and the computer) on a different subnet.
Get the IP of the USG from the computer (it will be the gateway) and SSH into it using the default credentials ubnt:ubnt.
Upgrade the firmware as per these instructions (just type ‘upgrade and the URL of the firmware).
Once it has rebooted, go to https://setup.ubunt.com and use the UI to do some initial configuration.
For me this consisted of
1. Setting the USG LAN IP to the current IP address of the Home Router and configure the DHCP range again to match the Home Router setup (don’t save yet).
2. Changing the IP address of my Home Router to a different subnet (e.g. from 192.168.1.1 to 192.168.10.1) and the DHCP range appropriately (don’t save yet).
3. Changing the USG WAN settings to work with the new subnet of the Home Router (you could just leave it to get a DHCP address).
First then, save the configuration on the USG – it will reboot. You will need to unplug the network cable from the computer to force the computer to pick up a new IP – be patient at this point. You will not have any internet on the computer (as the WAN cannot connect – yet).
Save the Home Router configuration – you might need to force a reboot. Unplug your network from the Home Router and plug it into LAN1 port of the USG. Now the Home Router is connected to the USG WAN port, and the rest of your network to the LAN1 port.
You should now be able to adopt the USG in your UniFi Controller and everything still works. The one fly for me was that the Network had not been configured correctly and it moved from my specified IP to a X.X.X.1 IP. Manually changing that in the controller was easy enough.

I just now need to work out how to harness the power! My next task is use it for DDNS and a VPN connection.

References:

Follow the steps on this KB to update the USG offline or SSH if have the internet access on USG https://help.ubnt.com/hc/en-us/articles/204910064-UniFi-Changing-the-Firmware-of-a-UniFi-Device#USG2
Then follow this steps to change the LAN IP of the USG https://help.ubnt.com/hc/en-us/articles/236281367-UniFi-How-to-Adopt-a-USG-into-an-Existing-Network

Posted in Hardware, Network, Technical - General | Tagged Ubiquti, USG | Leave a comment

Useful tshark Commands

I’ve been away but “Now I’m Back”

DietPi – Move Boot partition to smaller SD Card

Get data from WH1080 Maplin Weatherstation sensors directly

Install a Package from the Testing Repository

ReadyNasDuo V1 Rsync

Miscrosoft Teams – stop it auto starting

Letsencrypt SSL Certificates by DNS Challenge with Lighttpd

LAN HTTPS Everywhere

Prerequisites

Set Up DNS Access

Install & Configure certbot

Setting Up Renewal

Lighttpd Configuration

Setting up an internal FQDN

BT Broadband – Faster Speeds – Yes Really

Ubiquiti USG Home Setup

About This Site

Meta

Recent Posts

Recent Comments

Archives

Categories

Be Sociable

LAN HTTPS Everywhere

Prerequisites

Set Up DNS Access

Install & Configure certbot

Setting Up Renewal

Lighttpd Configuration

Setting up an internal FQDN

About This Site

Meta

Recent Posts

Recent Comments

Archives

Categories

Tags