It’s been a while since I’ve posted here on the good old blog, I’ve been busy with life and work, however, that may change soon as the big 5 banks in Canada are now forcing everyone to a mandated RTO back in to downtown Toronto. I had to move out of the city some years back due to the cost of living crisis here so I may be out of a job come September.
Anyway, I started a new MacOS app in Swift called TurnTable which is written from scratch to try and copy the old spirit and simplicity of the original iTunes application. It doesn’t have anything fancy yet implemented but I just wrote it all today and am posting the source code of course up on my github. I will try to add more features to it over time when I get a free chance to do so!
With this network-wide layer-4 forward-proxy service running a bit better now, I had originally implemented a highly-modified version of the ARC4 symmetric stream cipher with a keyed checksum hashing method to work together. The one part I was missing was an EC asymmetric cipher to help protect a Diffie–Hellman based ephemeral key exchange. It’s been a number of years since I’ve experimented with this but I started an implementation using the C OpenSSL library to use a pre-generated EC key pair to protect a DH key exchange which can be used at the start of the proxy tunnel connection. You can use the openssl command to generate the EC key pair and then use this framework to load them in and perform an encrypted ECDH key exchange. As you can see below, there are a few steps needed to complete this transaction:
The client generates an ephemeral EC key pair and encrypts the ephemeral public key with the generated public key and sends this to the server
The server decrypts the ephemeral public key with the generated private key
The client creates a secret number to multiply with a generated curve point and encrypts this with the generated public key and sends this to the server
The server decrypts the clients key exchange with the generated private key and multiplies it with the server secret number to get a shared secret
The server creates a secret number to multiply with a generated curve point and encrypts this with the ephemeral public key and sends this to the client
The client decrypts the servers key exchange with the ephemeral private key and multiplies it with the client secret number to get a shared secret
You can see near the end there are two lines labelled “rx …. dhkx:” which contain the same shared X & Y points on the EC curve which were encrypted using the basic scheme above!
Over the years I’ve been trying to run a custom-made layer-4 transparent-proxy service for most of my entire network to use automatically (zero client configuration). It first started because I did not like the general idea of a VPN server using a sub-1500 MTU setting while all of the clients on a network auto-assume a 1500 MTU themselves. In addition, instead of reading 1500 bytes at a time off of a TUN interface, you can instead read 8192 bytes off of a TCP socket at a time which you can then feed to a fast stream cipher without the need for packet fragmentation. However, it took me quite a while to reach some stability with tracking all of the connection state types and to iron out all the issues that could arise from transparently proxying both UDP and TCP connections. Some of the lessons I learnt that might help others trying a similar approach include the following:
Make sure to increase the number of file descriptors to handle all of the sockets and pipes per each process/thread running
Ex: ulimit -n 65536
Make sure to check for any remapped duplicated source port entries in the connection state tracking table based on dport after checking sport first
Make sure to pay attention to the finer details of properly managing connection states and process/thread states throughout the entire code base
Ex: Create a separate thread that is dedicated to managing the file descriptors and processing states
I will try to post more tips as time goes on and I learn more but these small issues can cause a lot of headaches when you’re trying to translate and redirect thousands of network wide connections down into separated processes for load balancing purposes! 🙂
This is a newly modified setup I’m testing out instead of the Linksys OpenWRT I am using the Lenovo M920Q with Debian. I also installed the StarTech 4-Port 2.5Gbps PCIe Card (Intel I225-V) and the PCIe 16x Riser Card. The M4 Mini has 2 attachments including the Sonnet Solo10G and the OWC 1M2.
I’ve been trying to get things in order before the end of last year and into this new year of 2025 so I can try to lessen any worries that might come up. I was doing a complete re-write of the core network-wide proxy-service and this time I have also tried to write it in both Python and C so the code bases so mostly match and line up with each other. The main problem I think is that I tried to generalize and condense the code base too much and I think this can cause problems as the packet tracking for UDP and connection state for TCP is a bit different from each other. This time I have separated out each component into its own dedicated section, the downside is that it’s a much larger code base with potentially duplicated code snippets. It’s a strange kind of project and hard to describe it but the best way I can think of it as is a Transparent Layer 4 MITM/Proxy service 😀
The core components now have the following layouts:
Protocol
Mode
Operation
UDP
Client
Send
UDP
Client
Read
UDP
Server
Send
UDP
Server
Read
TCP
Client
Send
TCP
Client
Read
TCP
Server
Send
TCP
Server
Read
Edit: Note to my future self, always remember to ulimit -n 65536 before launching!
I’m still fine tuning & adjusting it but the source code links can be found here:
M2 Max Multi Score: 14678
M2 Ultra Multi Score: 21352 (~46% increase between max & ultra)
M4 Max Multi Score: 26675
M4 Ultra Multi Prediction: 38945 (using roughly the same 46% increase from M4 Max)
M4 Extreme Multi Prediction: 77891 (multiplying the M4 Ultra prediction by 2?)
Apple just introduced Thunderbolt 5 which with its higher bandwidth will finally allow for the true and properly designed displays that I think Apple was waiting for. I predict possibly a 27/32/36 inch line up with 5/6/8K resolutions with 120Hz refresh rate. The only remaining question is, will it be Mini-LED for multiple dimming zones or possibly OLED?
The latest version of iOS brought some nice updates to allow you to customize the look and feel even further than before. It has allowed me to set 2 shortcuts on the home screen (one for my switch bot app and one for my custom MacBook controller web app). I also like the larger dark mode icons without the text labels below them. Here are my current screenshots and setup:
~
When Steve Jobs came back to Apple, he drew a 2×2 grid to reorganize the Mac product line up and offerings. I believe the iPhone needs a similar grid in 2×3 form, for example:
I am using this page as the officially documented support page for a new iOS app called “Widgets Factory”
It has been recently initially approved and released to the iOS App Store!
~
Here are some example screenshots:
~
Known Issues
The background task and refresh processing capabilities on iOS are severely limited and hampered due to some of the more hostile protection mechanisms built in. I will also say that these protection mechanisms do serve a good purpose as to try and protect the battery life and foreground processing requests to give the user a better mobile experience. It would still be nice if Apple could improve the background system to guarantee some additional service capabilities:
Don’t sleep or stop the apps non-main thread if it is registered and expecting a background refresh, instead provide a minimum/minimal percentage of dedicated processing time overall
Ensure that the requested caller gets a background refresh process time after waiting a maximum of 5-15 minutes
Provide a specific API method call that is background approved to perform the basic needed tasks on behalf of the calling application with a minimal guaranteed processing time:
Location Coordinates
Map Snapshots
Web Fetches
Widget Views
Push Notifications
Future Wishes
It would also be nice for apps that are free without ads to be able to have a one-time (or even re-occurring) tip jar that user’s could donate whatever amount they feel comfortable with to the developer.
It’s been a busy year for me again, trying to focus on my self and my health. Mapping out dietary and seasonal allergies, still on the mission of No Dairy, Eggs, Caffeine, High-Fructose-Gluctose-Corn-Syrup, etc. I am able to breathe better and sleep better which is much needed as I get older.
Anyway, I was still running the experiment of tunneling my entire home traffic (network wide) and all connections through a VPN. I first ran into MTU packet size and fragmentation issues related to the fact that the clients on my network default to a 1500 MTU whereas the VPN tunnel interface drops that size by at least 40-60 bytes worth. This can result in packet fragmentation and performance issues which OpenVPN has support for but WireGuard does not.
I then switched to a proxy setup where I redirect and pipe all connection data at the protocol level to a server-side service which forwards it to the VPN endpoint and then out to the internet. This setup had much better performance but I then ran into some connection issues as the firewall states and the timeouts may not exactly be honoured correctly by the serving application.
I rewrote my Python made framework to start fresh again and go back to basics in a lower level language like C and this seems to be working better at the moment. I will continue to run this and test it out as the final replacement hopefully. The list of features this includes is:
Transparent Dynamic Forwarding Proxy Service (load balancing capable with ip/nftables)
This is the magic part of the code which sits in front of the proxy service and shares the UDP connection states and pre-routes them to the already established VPN tunnel related for that specific load balanced connection.
So as I’ve gotten deeper and deeper into the keebort hobby, I’ve been able to build and modify and tune a few different designs and layouts (except for the Kohaku which has the nice gasket-cushioned leaf-spring two-piece mounting system but I cannot afford that GB). My favorite layout seems to be the 65 as it offers the dedicated arrow keys and basic navigation keys which I need for light coding tasks (second fav is the compact 75 layout like the Mode Sonnet offers).
I recently bought into the new Mode 65R2 pre-order (like I did with the Envoy) due to its two-piece mounting system and overall design which should allow for more options in modifying and tuning the keyboard after build. I selected the aluminum case and plate, brass weight, wood accent and the foam kit. I built the board with Boba U4Ts and used the plate foam only with the top mount configuration.
I then performed some modifications to try and lower the tone and clack of the board. I swapped out the top mount blocks and modified the full lattice blocks by cutting the tops off of them and poking holes through them so that they could be used in a top mount configuration and cushion the longer M2x8 replacement screws (force break top mount). I then taped up the bottom case to reduce the harsh metallic sounds and soften and lower the tones as well (force break bottom case).
~
~
Result: It’s like a Clunky and Thunky type of deeper lower end Clack and Chalk kind of sound profile. After similar mods were done to my OG Mode Sonnet, it sounds very similar, in addition to my old original Drop Alt but in a better and more elegant case and frame. It reminds me of an old school analogue mechanical typewriter sort of sound and it made me realize that that type of sound is what I prefer as it reminds me of something real from back in the day (nostalgia?) versus aiming for thock which doesn’t really remind me of anything other than a more artificial type of muted and foamed up sound profile (although still pleasant to my ear). This is def my fav keeb so far! 🙂
Jon's FOSS Blog 