As someone who sets up secure settings for web server and similar up once in a while, this is nice: https://cipherl.ist
While I ordered a replacement joystick potentiometer slider (see my post from last week), I thought that you could also simply move one slider from a less used joystick axis to the one used most (left joystick, up-down direction). Much less used is the right joystick up-down). So I open the joystick again, bent off the housing of the those and swapped the up-down potentiometer sliders of the 2 joysticks. And while it was a bit fiddly with moderate amount of force needed to open and close those plastic housings of the slider, it worked fine and it completely fixed the intermittent failures to move forward via the left joystick!
Without re-calibration there was a tiny drift up (sometimes I walked very slowly forward). After re-calibration it’s rock-solid and works perfectly.
Reminded me of Tire Rotation in a car. In 2020 you rotate potentiometer sliders instead.
I forgot I bought one of those a while ago! To flash Espruino software on it:
esptool.py --port /dev/ttyUSB1 --baud 115200 write_flash \ --flash_freq 80m --flash_mode dout --flash_size 1MB --verify \ 0x0000 "boot_v1.6.bin" 0x1000 espruino_esp8266_user1.bin \ 0xFC000 esp_init_data_default.bin 0xFE000 blank.bin
Files from https://www.espruino.com/binaries/espruino_2v05_esp8266/. Source: http://forum.espruino.com/conversations/319660/ although that speaks of 40MHz. I have not seen any issues with 80MHz.
Needless to say, it works fine:
The main information is in those pictures. The sliders are actually replaceable without having to de-solder the joystick. Get replacement sliders from a replacement joystick. Then simply replace the slider. Far more detailed instructions in above thread.
I got 6 Mikrotik RouterOS devices in active use now. 4 more which are not used. Time to make backups of their configs…
Setting up ssh keys
scp id_rsa.pub admin@ROUTER: ssh admin@ROUTER # Then enter those commands /user ssh-keys import file=id_rsa.pub user=admin /file remove id_rsa.pub /quit
Making a config dump
ssh admin@ROUTER "/export compact terse file=configdump.rsc" scp admin@ROUTER configdump.rsc ROUTER-config.rsc
Enabling Japanese Input Method is always something which takes me more time that it should. Here the short version:
- Install ibus-mozc: apt install ibus-mozc
- Run im-config (it’s interactive)
Log out and back in (all this is only active after re-login). For good measure re-start your X server (Ctrl-Alt-Backspace if enabled).
You should now have the IBus Panel in the lower right corner:
Right-click on it, select Preference, then go to the Input Method tab and add Japanese Mozc. English too if that’s not there already.
Possibly log out and in again. Now you have Japanese Input Method working as expected. Switch between English and Japanese with Meta-Space (usually the left Windows key is the Meta key).
Once you use Japanese, you have to select the correct Japanese input mode (Hiragana in most cases):
Now Konsole as well as Firefox or Chrome can handle Japanese input fine.
systemd is nice in principle, but it does not always improve things. E.g. why does it need a DNS resolver?
This will get rid of the initial DNS name not resolvable error I see sometimes: Change /etc/nsswitch.conf and remove in the hosts line the “[NOTFOUND=return]”
This removes the local DNS proxy/cache: Edit /etc/systemd/resolved.conf and include your DNS server here.
Also fix your resolv.conf symbolic link:
❯ ls -la /etc/resolv.conf lrwxrwxrwx 1 root root 34 May 4 20:55 /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf
I used to create self-signed certificates, but they have the problem that I have to accept them the first time when using a browser, and when openssl library connects, I have to disable the certificate verification in curl, Node.js etc.
The proper fix is to create your own CA which your computers trust. Then signing certificates with this CA makes your computer trust those certificates. Luckily creating a CA is simple.
Note that all this is very insecure and should only be used for home use. For the real Internet, use Let’s Encrypt . I wish I could use the same for local certificates, alas this is not supported as Let’s Encrypt verifies DNS ownership.
Here the steps. See the original instructions by mrkiril which this is based on. And OpenSSL’s ca command (check the Warning section!). Also this includes plenty examples including something about the Java keytool.
1. Create your CA
You need 3 config files. First one: config_ssl_ca.cnf is for the CA.
[ req ] default_bits = 2048 prompt = no distinguished_name=req_distinguished_name req_extensions = v3_req [ req_distinguished_name ] countryName=JP stateOrProvinceName=Tokyo localityName=Tama organizationName=root organisation organizationalUnitName=root department commonName=Harald Kubota emailAddressemail@example.com [ alternate_names ] DNS.1 = t620.lan [ v3_req ] keyUsage=digitalSignature basicConstraints=CA:true subjectKeyIdentifier = hash subjectAltName = @alternate_names
And this is how to create your CA certificate (self-signed):
mkdir CA openssl genrsa -out ./CA/CA.key 4096 openssl req -new -x509 -key ./CA/CA.key -out ./CA/CA.crt -days 3650 -config config_ssl_ca.cnf
2. Create a CSR
Next one config_ssl.cnf is for generating a certificate sign request. The alternate_names should match the URL you use:
[ req ] default_bits = 2048 prompt = no distinguished_name=req_distinguished_name req_extensions = v3_req [ req_distinguished_name ] countryName=JP stateOrProvinceName=Tokyo localityName=Home organizationName=MyOrg organizationalUnitName=Tech Department commonName=Harald Kubota emailAddressfirstname.lastname@example.org [ alternate_names ] DNS.1 = web.lan DNS.2 = web.net IP.1 = 192.168.2.84 [ v3_req ] keyUsage=digitalSignature basicConstraints=CA:false subjectAltName = @alternate_names subjectKeyIdentifier = hash
Below is how to create a CSR. Note that “$x” is just a filename. The DNS name is in the previously mentioned config_ssl.cnf.
export x=web.lan openssl genrsa -out "$x.key" 2048 openssl req -new -sha256 -key "$x.key" -config ./config_ssl.cnf -out "$x.csr"
3. Sign the CSR
And the last one config_ca.cnf to sign the CSR:
# we use 'ca' as the default section because we're using the ca command [ ca ] default_ca = my_ca [ my_ca ] # a text file containing the next serial number to use in hex. Mandatory. # This file must be present and contain a valid serial number. serial = ./CA/CA.srl # the text database file to use. Mandatory. This file must be present though # initially it will be empty. database = ./CA/index.txt # specifies the directory where new certificates will be placed. Mandatory. new_certs_dir = ./ # the file containing the CA certificate. Mandatory certificate = ./CA/CA.crt # the file contaning the CA private key. Mandatory private_key = ./CA/CA.key # the message digest algorithm. Remember to not use MD5 default_md = sha256 # for how many days will the signed certificate be valid default_days = 365 # a section with a set of variables corresponding to DN fields policy = my_policy # MOST IMPORTANT PART OF THIS CONFIG copy_extensions = copy [ my_policy ] # if the value is "match" then the field value must match the same field in the # CA certificate. If the value is "supplied" then it must be present. # Optional means it may be present. Any fields not mentioned are silently # deleted. countryName = match stateOrProvinceName = supplied organizationName = supplied commonName = supplied organizationalUnitName = optional commonName = supplied
This is how to sign:
openssl ca -config ./config_ca.cnf -out "$x.crt" -in "$x.csr" -batch
Should you try to sign 2 certificates with the same DN, you’ll get this error:
ERROR:There is already a certificate for /C=JP/ST=Tokyo/O=MyOrg/OU=Tech Department/CN=Harald Kubota
The fix is to change ./CA/index.txt.attr to be
unique subject = no
4. Import CA to Ubuntu
Your machine should not yet trust your new CA certificate. Use above created certificate and present a web page or similar. Confirm via
openssl s_client -connect HOST:PORT
to connect to that process using your previously created host certificate. You should see something along those lines. Note line 4 and 7 with a “verify error” part.
❯ openssl s_client -connect web.lan:8443 CONNECTED(00000003) depth=0 C = JP, ST = Tokyo, O = MyOrg, OU = Tech Department, CN = Harald Kubota verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = JP, ST = Tokyo, O = MyOrg, OU = Tech Department, CN = Harald Kubota verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain [...]
To make OpenSSL trust the certificate, you have to make it trust your CA. This is how:
if [[ ! -d /usr/share/ca-certificates/extras ]] ; then mkdir /usr/share/ca-certificates/extras fi cp CA.crt /usr/share/ca-certificates/extras/HaraldCA.crt echo "extras/HaraldCA.crt" >>/etc/ca-certificates.conf update-ca-certificates -v
and after updating the root certificates on your computer:
❯ openssl s_client -connect web.lan:8443 CONNECTED(00000003) depth=1 C = JP, ST = Tokyo, L = Tama, O = root organisation, OU = root department, CN = Harald Kubota, emailAddress = email@example.com verify return:1 depth=0 C = JP, ST = Tokyo, O = MyOrg, OU = Tech Department, CN = Harald Kubota verify return:1 --- Certificate chain [...]
5. Import CA into your Browser
Browsers bring their own CA store, so you have to update those. Copy CA.crt into a directory you can access from the browser, and import it.
Firefox: Preferences → Privacy & Security → Certificates View Certificates → In the Authorities pane click on Import… and import your CA.crt
Chrome: Settings → Privacy and security → Click on More → Manage certificates → Authorities → Import and import your CA.crt
From now on if you go to any web page which is signed with your CA, you browser will not show a warning anymore.
This has no password/passphrase on any private key. Also the CA should be on a secured server.
My routers do DFS really well. So well, that they detect radar once in a while (about once per week) where I am pretty sure there is nothing to detect. I found a map of weather radar stations in my area (100km around me) and their frequencies. I should not be able to detect weather radar. I am not anywhere close to their frequencies.
Anyway, I thought changing to channels which do not require DFS might be helpful. But look at this:
So on 4th at about 20:00 I changed from channel 52 which needs DFS, to channel 44 which does not need DFS. I expected nothing to happen minus no false weather radar detection. But what I found was a severe increase of latency. Changing to channel 60 on 5th at about 10:00 made a huge difference.
While I’m at risk of DFS hitting me again,I’d say it’s worth it.
Channels 44, 52 and 60 showed no activity from neighbors. Only channel 36-40 are used as well as some more channels above 100 (see here for lists of available channels and frequencies).
- Not all channels are equal.
- To find the best channels, run a proper real-world test.
- Be aware of weather radar. Or DFS. Or both.
It’s simpler than it used to be:
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout example.key -out example.crt \ -subj /CN=example.com \ -addext subjectAltName=DNS:example.com,DNS:example.net,IP:10.0.0.1 # To create a PEM file: cat example.crt example.key >example.pem